MVP aplikacji w rekordowym czasie z Bubble: Blokowanie dostępu do treści
Logika
17 godz. 49 min · Biznes i Automatyzacje
Krzysiek PiekarzAutomation Specialist / No-code DeveloperCzego się nauczysz
- Pracy z edytorem Bubble na bardziej zaawansowanym poziomie
- Tego jak wyszukiwać, filtrować i edytować rekordy z bazy danych wbudowanej w Bubble
- Czym są privacy rules - czyli jak zabezpieczyć dostęp do naszych danych przed nieuprawnionym dostępem
- Praktycznej pracy z frontend i backend workflows
- Dodatkowo wdrożymy do naszej aplikacji system płatności Stripe oraz powiadomienia mailowe z wykorzystaniem np. SendGrid i innych
- Pokażę Ci jak łączyć się z zewnętrznymi API poprzez dostępny w Bubble plugin API Connector
- A także jak rozszerzyć funkcjonalność naszej aplikacji poprzez proste automatyzacje z serwisem Make
- Na koniec zajmiemy się również podpięciem naszej customowej domeny oraz publikacją aplikacji
Czy w Twojej głowie pojawił się pomysł na aplikację, która zrewolucjonizuje świat na miarę Facebook'a, Instagrama albo Airbnb? A może zgłosił się do Ciebie klient, który chce przetestować i wdrożyć swój projekt w jak najszybszym czasie?Jeśli tak było to na pewno zadajesz sobie teraz kolejne pytanie - od czego zacząć? Czy muszę posiadać odpowiednią wiedzę programistyczną? Na jaki język programowania się zdecydować lub z jakiego gotowego framework'u skorzystać? A może zatrudnić profesjonalnego designera i software house, który pozwoli mi zrealizować ten projekt?Niezależnie od tego czy czy zdecydujesz się działać sam/a, czy też przekażesz projekt do zewnętrznej agencji i tak staniesz przed kolejnym dylematem jakim jest nauka programowania lub konieczność przepalenia nawet setek tysięcy złoty na coś, co może okazać się niewypałem.Na szczęście szybki rozwój narzędzi no-code sprawia, że możesz wybrać jeszcze trzecie wyjście. Zaprojektować, zbudować i wypuścić w świat swoją wymarzoną aplikację tylko za pomocą własnych sił i to bez konieczności posiadania specjalistycznej wiedzy programistycznej, a nawet posiadając jedynie podstawową znajomość narzędzi do design'u.Pamiętaj również o tym, że projekt ten podzieliłem na dwie części. Ten kurs to druga część, w której zapoznamy się z bardziej zaawansowanymi opcjami, jakie zapewnia nam edytor Bubble. Zdobytą w ten sposób wiedzę teoretyczną wykorzystamy od razu w praktyce dodając do naszego statycznego designu odpowiednią logikę, dzięki czemu nasz finalny projekt będzie już w pełni działającą aplikacją.Jeśli tylko potrafisz w podstawowym zakresie pracować z edytorem Bubble, budować w nim design aplikacji i rozumiesz czym są option sets oraz workflows to posiadanie wiedzy z poprzedniego kursu nie jest koniecznie wymagane. Natomiast szczerze zachęcam Cię przynajmniej do przejrzenia materiałów z pierwszej części, gdzie skupiamy się właśnie na podstawach, ponieważ teraz będziemy efektywnie przechodzić do bardziej zaawansowanych tematów i rozbudowywać naszą aplikację.
Czego nauczysz się w ramach tego Kursu?
W tym kursie „MVP aplikacji w rekordowym czasie z Bubble (Logika)” nauczę Cię jak zamienić statyczny layout na pełnoprawną aplikację. Poruszymy takie tematy jak praca z bazą danych, privacy rules oraz bardziej zaawansowane workflows, które dodamy zarówno na froncie jak i backendzie naszej aplikacji. Dzięki zdobytej wiedzy dodamy logikę wszędzie tam, gdzie tego wymaga nasz projekt, a dodatkowo wzbogacimy go o możliwość płatności poprzez najbardziej popularny na świecie system jakim jest Stripe. To jednak nie koniec ponieważ przygotowałem dla Ciebie również szereg innych ważnych zagadnień, które omówimy i wykorzystamy w praktyce.W ramach nauki skupimy się na jak najbardziej praktycznym podejściu. Zapomnij o długich i nudnych lekcjach pełnych teorii, które zapomnisz zaraz po obejrzeniu. Będziemy budować a nie debatować! W ten sposób nauczysz się pracować z edytorem Bubble na poziomie zaawansowanym. Zrozumiesz jak zabezpieczyć swoje dane przed nieuprawnionym dostępem, w jaki sposób pobierać i dynamicznie filtrować rekordy z bazy danych. A także jak wykorzystać auto-binding by móc je aktualizować bez wykorzystania skomplikowanych workflows.Dodamy do naszej aplikacji prosty komunikator, który pozwoli na wymianę wiadomości pomiędzy użytkownikami. Zadbamy również o możliwość wysyłania powiadomień mailowych poprzez zewnętrzne serwisy by ich wygląd był zgodny z naszym brandem. Nie zabraknie również takich tematów jak SSO z Google czy też proste automatyzacje z wykorzystaniem serwisu Make.
Dla kogo jest ten kurs?
Materiał szkoleniowy został zaprojektowany tak, aby mogło z niego skorzystać jak najszersze grono odbiorców. Nieważne czy jesteś totalnym laikiem, czy też posiadasz już wiedzę z zakresu programowania lub designu, na pewno znajdziesz tu coś dla siebie. A więc kto jeszcze może skorzystać z wiedzy zawartej w tym kursie?
W tej lekcji porozmawiamy o tym, jak w Babel możemy zablokować dostęp do treści.
Może to być jakiś element na stronie, cała sekcja oraz oczywiście
również i cała strona.
Z pierwszym przypadkiem mieliśmy już doczynienia, gdy pracowaliśmy na przykład
ze stroną Dashboard, na której obecnie jesteśmy.
Jak pamiętasz z pierwszego Sprintu zadbaliśmy tutaj o to, by wyświetlać dane
sekcje tylko wtedy, gdy zostaną spełnione określone warunki.
Możemy to teraz sobie tutaj sprawdzić. Mamy np.
sekcję Guest NT.
Przechodza sobie tutaj w pierwszej kolejności w zakładce Layout
ukrywaliśmy taką sekcję na załadowanie się strony.
Kolejno zaznaczyliśmy collapse hidden, żeby ten element nie zajmował miejsca po
tym jak zostanie ukryty, a kolejno przechodziliśmy do zakładki Conditions.
I tutaj dodawaliśmy odpowiedni warunek, dzięki któremu właśnie mogliśmy
pokazywać całą tą sekcję.
Jak pamiętasz, w tym przypadku dla wszystkich tych elementów odnosiliśmy się
do tutaj danych wyciąganych właśnie z paska adresu URL,
a kolejno sprawdzaliśmy, czy właśnie ta wartość tutaj booking number
ona jest tutaj z tym właśnie przedrostkiem deep jest równa 0.
W ten sposób mogliśmy odpowiednio pokazywać i ukrywać dane elementy.
Niemal takie same tutaj warunki, aby dla tych pozostałych sekcji właśnie po to były
nam potrzebne te dodatkowe właśnie wartości w bazie danych,
czyli booking, number, reviews, number itd.
Podobne zresztą operacje wykonywaliśmy również w naszym na w barze, gdzie
pokazywaliśmy odpowiednie menu w zależności od tego, czy użytkownik
jest zalogowany czy też nie.
Ostatni przykład to oczywiście strona profilowana, gdzie ikonkę do edycji
danych użytkownika oraz całą tą sekcję z opcją usunięcia profilu pokazywaliśmy
tylko wtedy, gdy użytkownik wyświetlał swój własny profil.
Jak więc widzisz, do ukrywania elementów na stronie właśnie w Babel?
Najczęściej wykorzystujemy tutaj tę zakładkę Conditions.
Ale Natomiast co zrobić w sytuacji, kiedy chcemy zablokować użytkownikowi dostęp do
całej strony, czyli tak, żeby nie mógł jej w ogóle wyświetlić?
Znów Babel.
Jest to niesamowicie proste, ale tym razem będziemy musieli skorzystać
z nakładki workflow.
Zacznijmy więc może od początku, czyli od głównej strony naszego serwisu.
Przejdźmy do strony index owej i zastanówmy się, czy taka strona ma się
wyświetlać dla każdego, czyli zarówno zalogowanych, jak i
zalogowanych użytkowników.
Dla niezalogowanych oczywiście.
Ponieważ właśnie na tym polega nasz serwis.
Użytkownik musi tutaj wejść, posprawdzać co mu oferujemy
i na tej podstawie oczywiście utworzyć bądź też nie konto w naszym serwisie.
Natomiast czy chcesz ją wyświetlać również dla zalogowanych użytkowników
zależy już od Ciebie.
Ja w takim przypadku najczęściej jeżeli użytkownik jest zalogowany to blokuję mu
dostęp do strony index owej i przekierowuje go od razu
na stronę Dashboard. Jak to zrobić?
Przechodzę tutaj do zakładki Workflow.
Tym razem klikam sobie tutaj.
Jak widzisz mam tutaj zakładkę General i te opcje, z których
najczęściej będziesz korzystał.
Możemy się tutaj odnieść właśnie do User i Getin.
Jest to dokładnie taki warunek jak tutaj jest napisane.
Czyli jeżeli użytkownik jest zalogowany to co chcemy zrobić chcemy go przekierować
tutaj Navigation Go to Page Dashboard.
I to w zasadzie wszystko.
Natomiast jeżeli użytkownik nie będzie zalogowany, to normalnie będzie mógł
korzystać tutaj z naszej strony linuksowej.
Sprawdźmy też pozostałe strony i zastanówmy się, gdzie jeszcze musimy dodać
takie warunki, aby zablokować mu właśnie ten dostęp.
Mamy tutaj stronę.
Bookingu jeszcze nie zajmowaliśmy, ale do tego wrócimy później.
Mamy natomiast Dashboard.
Tutaj, jak się domyślasz, musimy ustawić odpowiedni warunek.
Mamy teraz tutaj dodane User is locked out.
Czyli kiedy użytkownik jest zalogowany to kierujemy go na stronę Sign
in, czyli na stronę logowania.
Jeśli nie masz jeszcze takiego warunku dodanego u siebie w aplikacji, dodaj go
teraz właśnie tutaj jako prosty workflow i przekieruj użytkownika na stronę
logowania tak jak ja to zrobiłem.
Sprawdzamy następne strony.
Mamy stronę listingu.
Oczywiście moim zdaniem tutaj nie powinniśmy nic dodawać.
Na taką stronę powinien móc wejść zarówno zalogowany, jak i nie
zalogowany użytkownik.
Strona nowego listingu Tutaj zdecydowanie dostęp powinien
mieć tylko zalogowany użytkownik.
A więc oczywiście przechodzimy tutaj.
Mamy tutaj jak widzisz całą masę różnych workflow już wcześniej dodanych, natomiast
dodajmy sobie tutaj odpowiedni folder.
Podzielmy to sobie jako z reguły nazywam po prostu general.
I tutaj kiedy użytkownik jest zalogowany, czyli user is get out
chce go przekierować.
Oczywiście tutaj na stronę logowania, czyli z timeline.
Sprawdzamy kolejne strony.
Mamy tutaj stronę on buildingu.
Oczywiście ta sama zasada.
Czyli też musielibyśmy przekierować tam użytkownika, który jest zalogowany.
Ja już teraz nie będę robił, nie będę tego ustawiał dla wszystkich pozostałych stron.
Mam nadzieję, że rozumiesz, jak to działa.
Pamiętaj, że bubel jest zablokowany na tej zasadzie, że użytkownik tu wejdzie.
Babel sprawdza ten warunek i natychmiast go przekierowuje gdzieś na tą stronę lub
robi jakąkolwiek inną akcję jako ustawisz tutaj.
Dlatego właśnie triggera.
Natomiast im więcej warunków tutaj dodasz.
Jeżeli byłby to jakiś skomplikowany warunek, to bardzo często sprawdzanie
go może zająć dłuższą chwilę, np. sekundę lub dwie.
Dlatego też, jeżeli nie chcesz na pewno pokazywać użytkownikowi jakichś treści na
swojej stronie, dobrze jest zastosować loader, który najpierw pokazujesz.
Jeżeli użytkownik spełnia warunki, żeby przejść na taką stronę, to go ukrywasz i
on sobie tam działa, a jeżeli nie to zostaje przekierowany.
Więc taki użytkownik, który nie ma dostępu do takiej strony zobaczy
tylko i wyłącznie loader.
Jest to niesamowicie przydatny trik, Ja zawsze z niego korzystam i
Tobie również polecam to robić.
Natomiast wróćmy może na stronę Dashboard, ponieważ chciałbym Ci pokazać jeszcze
jedną bardzo ważną rzecz, a będzie mi to dużo łatwiej zobrazować właśnie
na podstawie tej strony.
Przejdźmy do podglądu, czyli po prostu zaloguj się do naszego dashboard.
OK, jestem zalogowany, jestem tutaj na stronie booking i to co
chcę zrobić to teraz przede wszystkim to aplikować sobie taką stronę.
Chociaż może nie, zaraz to zrobimy.
W pierwszej kolejności wracamy jeszcze tutaj do edytora, ponieważ
tak, mamy tutaj warunek user is get out.
Podobnie mamy tutaj oczywiście user is located in.
Natomiast bardzo często spotkasz się z takim zapisem, którego ja
też kiedyś korzystałem.
Kiedy wybieramy tutaj Page Load, następnie Navigation Page Saiyanin
I tutaj dopiero warunek, że Karen User.
I locked out. Czyli musimy to namierzyć.
O właśnie.
A więc czym się różni ten warunek?
Gdzie trigger jest page load od tego drugiego?
Gdzie trigger jest user self get out?
Teoretycznie oba te warunki zadziałają tak samo.
Czyli jeżeli użytkownik będzie wylogowanie, no to kierujemy
go na stronę sesji.
Natomiast chciałbym, abyś z tej lekcji zapamiętał przynajmniej to, ponieważ ta
różnica, mimo że jest drobna, jest niesamowicie ważna.
Jeśli dobrze nie zrozumiesz, to może przysporzyć Ci całą masę kłopotów.
Aby Ci to zobrazować zróbmy to w ten sposób.
Na razie usuńmy tan.
Zostawmy tylko ten warunek user i get out jako trigger
i wtedy przekierowanie do strony side.
Teraz dopiero przejdźmy do podglądu. Odświeżamy.
I publikujemy sobie właśnie tą stronę.
Teraz w obu przypadkach jestem zalogowany i jestem w naszym kodzie.
Zobacz co się stanie jeżeli przejdę tutaj do tej pierwszej strony i się wyloguj.
Tutaj jestem wylogowanie.
Tutaj teoretycznie nadal jeszcze mogę pracować, nadal mogę coś zrobić.
Natomiast jeżeli kliknę tutaj, czyli wykonam jakąkolwiek akcję, która coś
tam uruchamia, to zobacz, co się stanie.
Teoretycznie się pokazało, ale w praktyce Babel od razu wyłapał, że jesteśmy
zalogowani i oczywiście nas tutaj logował.
Przeniósł nas na stronę sign in i dokładnie na takim
działaniu powinno Ci zależeć.
Czyli jeżeli użytkownik ma otwartą aplikację w kilku różnych
zakładkach i w którejkolwiek z nich albo sam się loguje, albo zostanie wylosowany,
ponieważ upłynie mu ten czas sesji jaki mu udzielisz, to chcesz, żeby właśnie
automatycznie przy jakimkolwiek działaniu został zalogowany z pozostałych stron.
Natomiast co się stanie, jeżeli tak po pierwsze się zaloguje znowu
jako demo guest.
Zamknijmy sobie ten duplikat jeszcze raz.
100 Aplikuj tutaj tę stronę.
Czyli znowu jestem zalogowany w obu tych zakładkach i wróćmy do edytora.
I tym razem pozbądźmy się tego warunku.
Możemy go sobie wyłączyć poprzez Disable Workflow.
Właśnie za pomocą tego check boxa i dodajmy teraz Pages Loaded
Navigation Goto Page Sign in.
Oczywiście wtedy, kiedy Current User.
Account.
Sprawdźmy, co się teraz stanie. Odświeżamy.
Tu i tutaj.
Wracam do pierwszej zakładki i robię dokładnie to samo
operacje, czyli się wylogowuje.
Wracam do drugiej, gdzie nadal teoretycznie jestem zalogowany.
Klikam sobie znów na PW.
No jak widzisz, wszystko nam tutaj zniknęło.
Natomiast nie przestałem przekierowany na stronę Timeline.
sejmiku. Dlaczego nam to tutaj zniknęło?
Oczywiście dlatego, że się po pierwsze wylosowaliśmy,
a więc bubel nie jest w stanie teraz sprawdzić tych warunków
i wyświetlić tam odpowiednich sekcji, ponieważ klient user nie istnieje.
Na ten moment jesteśmy zalogowani, natomiast dalej jestem na tej stronie.
Nie do końca Właśnie na takim działaniu Ci zależy.
Co więc musiałoby się stać, abyś został przekierowany na stronę Seen?
Saiyan?
Oczywiście musiałby się wykonać ten trigger, czyli musielibyśmy na
nowo załadować naszą stronę.
Spróbujmy sobie tutaj ją odświeżyć i zobacz, co się stanie.
Odpali się Page is loaded i dopiero teraz właśnie odpaliła się nasza akcja.
Mam nadzieję, że dostrzegasz tą różnicę i widzisz jak niebezpieczne jest
działanie tego page loaded.
Ponieważ użytkownik gdzieś tam dalej może się poruszać po stronie i kolokwialnie
mówiąc, może po prostu zgłupieć, kiedy gdzieś zostanie zalogowany,
a nadal będzie widział np.
część strony, a zniknie mu część elementów, to nie powinno zależeć na tym,
aby oczywiście jak najszybciej odpaliła się ta akcja i trafił na właściwą stronę,
na którą go właśnie chciałeś przekierować.
Tak więc w ramach pracy domowej pozostawiam Ci dodanie odpowiednich
workflow do wszystkich stron.
Zastanów się, kiedy użytkownik powinien mieć dostęp do danych treści,
czyli do danej całej strony.
Czy chcesz dać tam dostęp tylko zalogowanym użytkownikom,
czy nie zalogowanym również.
Na razie mamy oczywiście tylko te dwa proste warunki, czyli kiedy użytkownik
jest zalogowany czy też nie.
A w przyszłości będziemy je oczywiście rozbudowywać.
I nieraz właśnie te condition dane, które będziesz tam dodawał,
będą bardzo skomplikowane.
Ale do tego jeszcze z pewnością wrócimy.
A ja dziękuję Ci już za uwagę i widzimy się już kolejnej lekcji.