MVP aplikacji w rekordowym czasie z Bubble: Wdrażamy Backend Workflows
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 poprzedniej lekcji wspomniałem o back end workflow, więc teraz warto wyjaśnić
sobie, czym one tak naprawdę są.
Dlatego też proszę Cię o maksymalne skupienie w tej lekcji, ponieważ
jest to niesamowicie ważny temat.
Jego dokładne zrozumienie jest kluczowe, byś potrafił tworzyć nowoczesne aplikacje.
Otóż Back and Workflow w Babel to sekwencja zadań lub akcji, które są
wykonywane na serwerze w odpowiedzi na zdarzenia takie jak akcja użytkownika,
zmiana danych w bazie danych czy harmonogram czasowy.
Umożliwiają one zarządzanie logiką aplikacji, która nie wymaga bezpośredniej
interakcji z interfejsem użytkownika, czyli przeciwieństwie do front end
workflow nie są wykonywane w przeglądarce użytkownika.
Główne funkcje back end workflow to.
Automatyzacja zadań może zaprogramować automatyczne działania,
takie jak wysyłanie e-maili, aktualizacja danych w bazie czy też generowanie
raportów Przetwarzanie w tle, czyli zadania, które mogą trwać dłużej lub
wymagają dużej mocy obliczeniowej, mogą być wykonywane w tle, nie wpływając
na doświadczenie użytkownika.
Możesz tworzyć workflow, które są wywoływane przez konkretne zdarzenia,
takie jak zapisanie nowego rekordu, zmiana wartości w bazie danych czy też
kliknięcie przycisku przez użytkownika.
Kolejno zadania cykliczne, czyli możliwość tworzenia harmonogramów zadań, które
będą uruchamiane regularnie np.
codziennie, co tydzień itd.
Integracje zewnętrzne, czyli back end workflow mogą być używane do integracji
zewnętrznymi API, co pozwala na synchronizację danych z innymi systemami.
Ale o tym porozmawiamy sobie nieco później.
Jak widzisz, mają one cały szereg zastosowań, a dodatkowo posiadają jeszcze
tą najważniejszą zaletę, że są niejako odporne na to, co się dzieje
w przeglądarce użytkownika.
Bardzo często bowiem userzy mogą zamknąć okno przeglądarki, myśląc, że dana
operacja się już zakończyła i tym samym przerwał wykonywanie akcji,
które ustawiłeś sobie na froncie.
Analogicznie wystarczy też krótka przerwa w dostępie do Internetu po stronie
użytkownika, by efekt był dokładnie ten sam.
Dlatego też, jeśli chcemy mieć pewność, że dany workflow się na pewno wykona, możemy
ich przekierować właśnie na back end.
W naszym przypadku musimy się zastanowić, co z systemu brandingu
powinniśmy tam przerzucić.
Obecnie mamy tu dwie operacje, czyli tworzenie wishlisty oraz wysyłkę maila.
I o ile obie wydają się być dobrymi kandydatami, to ja jednak
skupiłbym się tylko na tej drugiej.
Wynika to z prostego faktu, że back end workflow jak się zaraz
przekonasz są kolejkowanie.
I pomimo tego, że samo Babel stara się je wykonywać niemal jednocześnie,
jeśli mają się uruchomić w tym samym czasie, to przy dużej ilości może to
czasem zająć odrobinę więcej czasu.
Dlatego też chciałbym, by nasza lista została najpierw utworzona,
a dopiero potem user powinien zostać przekierowany do dashboard.
W ten sposób unikniemy sytuacji, gdy niecierpliwy użytkownik przeklikać swoje
zakładki w Dashboard i w sekcji Wish list trafi na pustą
stronę zamiast na domyślną listę.
Oczywiście jest to tylko moje podejście.
Jeśli się z nim nie zgadzasz i uważasz, że lista powinna jednak być tworzona na
backend, to nic nie stoi na przeszkodzie, abyś to odpowiednio sobie obsłużył.
Natomiast w jaki sposób w ogóle dodać takie bucket workflow?
A więc przede wszystkim musimy posiadać plan płatny.
Uczestnicy sprintu, którzy korzystają z mojego planu agencyjne,
nie muszą się o to martwić.
Natomiast użytkownicy planu darmowego nie będą w stanie takich workflow
uruchomić bez przejścia na plan płatny.
Taki jest niestety wymóg Pabla.
Teraz to co musimy zrobić to przejść do zakładki Settings
kolejno do zakładki API i zaznaczyć ten checkbox, czyli po
prostu włączyć nasze Back and Workflow.
Jak widzisz pojawił się tutaj taki specjalny adres, z którego jeszcze
będziemy w przyszłości korzystać.
Dodatkowo chciałbym abyś zaznaczył jeszcze ten checkbox.
Tutaj możesz sobie dokładnie w dokumentacji sprawdzić do czego on służy,
ale w skrócie nie chcemy tu udostępniać dokumentacji z naszymi workflow, które
będą dostępne dla użytkowników spoza aplikacji.
Do tego przejdziemy w kolejnych lekcjach.
Jeszcze dokładnie to omówimy, ale na chwilę obecną po prostu mi zaufaj i
zaznacz te dwa checkbox, czyli ten włączający back and workflow oraz ten
ukrywający tutaj dokumentację z lagera.
Jak widzisz, mamy tutaj jeszcze całkiem sporo różnych innych opcji.
Natomiast najważniejsza będzie dla nas ta sekcja, ale do niej wrócimy sobie nieco
później, kiedy porozmawiamy właśnie o Reg Yourself Workflow.
A więc skoro takie workflow zostało już dla nas włączone, to może teraz
po prostu dodajmy pierwsze z nich.
W tym celu klikamy tutaj na Page.
I tu na dole pojawiła się nowa funkcja, czyli Backend Workflow.
Jak widzisz wygląda to niemal dokładnie tak samo jak przy zwykłych workflow.
Nawet tutaj w odpowiedniej sekcji możemy tworzyć nowe foldery i
oczywiście dodawać tutaj nowe workflow.
Natomiast jeżeli kliknę tutaj, to jak widzisz lista
designerów się dosyć mocno zmieniła.
Mamy tutaj API Workflow, Recording Event oraz New Database Trigger.
Zacznijmy od tego najprostszego, czyli utwórzmy najpierw jeden API Workflow.
Musimy nadać mu nazwę.
Niech to u nas będzie Send welcome email.
Teraz tak musimy się zastanowić, czy chcemy udostępnić workflow
ludziom z zewnątrz.
W naszym przypadku nie jest to workflow, które ma działać wewnątrz aplikacji.
Ma być uruchamiane właśnie tylko z jej poziomu, a więc odznaczamy tę opcję.
Jeśli uruchamiamy to wewnątrz aplikacji, czyli nie dajemy
dostępu innym użytkownikom, to ja zawsze zaznaczam te dwa parametry,
czyli ten i ten.
Czyli workflow może zostać uruchomiony bez autentykacji.
O tym też jeszcze sobie porozmawiamy i dodatkowo możemy tutaj
ignorować Privacy rules.
Kiedy uruchamiamy taki workflow, jest to jego dodatkowa zaleta, ponieważ bardzo
często jeśli będziesz chciał coś wykonać na froncie, to dość mocno zablokują Cię
właśnie privacy rules, które tam ustawiłeś.
I czasem zamiast się męczyć i próbować to obejść, lepiej właśnie
przerzucić się na back end.
I tutaj po prostu właśnie możemy je zignorować i taki workflow się
tutaj odpowiednio wykona.
Oczywiście możemy nadać mu tutaj kolor, przypisać do folderu itd.
Zresztą podobnie jak zwykłe workflow.
I teraz zastanówmy się co tutaj chcemy zrobić.
Oczywiście chcemy wysłać maila set grida, tego z powitaniem, a więc możemy
sobie wrócić do on boarding go.
Przejść.
Tutaj wciąć sobie tą akcję, czyli Cat i wkleić ją tutaj w Backend end workflow,
czyli w to miejsce. No i teraz sprawdźmy co tutaj się dzieje.
Przede wszystkim to nam pozostaje bez zmian.
Subject Mamy ustawiony już w samym serwisie.
To nam pozostaje bez zmian.
Ale właśnie tutaj pojawia się pierwszy problem.
Mamy Current user email i o ile na froncie mamy oczywiście dostęp do takiego obiektu
parent user, tak na backend nic to nie znaczy.
Backend nie wie jaki użytkownik jest parent userem w tej chwili.
Dlatego musimy tutaj odpowiednio to przekazać.
A więc wycięliśmy sobie najpierw to zerknijmy niżej, co tutaj jeszcze mamy.
No i mamy tutaj jeszcze parent user first name.
To też musimy wyczyścić.
Reszta pozostaje już tutaj bez zmian.
Możemy sobie tym przypadku pozostawić np.
wysłanie tego za 3 minuty.
Reszta pozostaje taka sama.
A więc teraz pojawia się jeden zasadniczy problem jak tutaj przekazać użytkownika,
aby wyciągnąć sobie z niego maila oraz oczywiście jego imię?
Okazuje się to bardzo prostą operacją.
W tym celu musimy dodać po prostu parametr do naszego workflow.
Klikamy tutaj.
Klikamy Add New Parameter.
Z parametrami też już mieliśmy do czynienia, pamiętasz?
Zastosowaliśmy je na przykład Label Element.
I tutaj działają bardzo podobnie.
Podajesz po prostu nazwę parametru.
Niech to będzie po prostu user i dla ułatwienia przekażemy sobie cały
obiekt usera, czyli po prostu user.
Moglibyśmy oczywiście odpowiednio przekazać sam email, samo imię, nazwisko
czy cokolwiek będziesz potrzebował.
Ale po co, skoro tutaj możemy wykorzystać cały ten obiekt?
A więc teraz tutaj możemy się odnieść do takiego parametru, czyli.
Jak widzisz mam tutaj dostęp do tego usera.
I teraz wyciągnąć sobie z niego email.
Kopiujemy.
Tutaj i tutaj jego imię czyli First name.
OK, czyli mamy pierwsze back end workflow, które będzie
nam wysyłało maila, które będzie tutaj przyjmowało usera.
A więc teraz musimy tutaj odpowiednio taką wartość przekazać.
Tu jeszcze możemy zaznaczyć czy jest to lista użytkowników czy tylko jeden user
oraz czy to jest opcjonalny parametr czy też wymagany.
Jeśli zaznaczysz to, to nie będziesz musiał podawać właśnie tego parametru.
Natomiast u nas oczywiście jest to wymagane, żeby to zadziałało.
Dlatego ja odznaczamy Optional i pozostawiamy to w tej formie.
Teraz musimy po stronie frontendu wywołać sobie takie back and workflow,
a więc wracamy do on buildingu. brandingu.
Tutaj i teraz.
Tak jak mówiłem, tworzenie nowej wishlisty pozostawiam
jednak na froncie, a tutaj będę chciał uruchomić właśnie takie back end workflow.
Czyli wybieram opcję Schedule a Workflow.
Na razie mamy tylko jedno, więc nie ma tutaj zbyt rozbudowanej listy.
Jak widzisz, teraz mamy tutaj dwa wymagane pola User, czyli jakiego
użytkownika chcemy przekazać.
Oczywiście w naszym przypadku będzie to Client user.
Teraz z jaką datą chcemy uruchomić takie workflow?
Chcemy, żeby to się uruchomiło jak najszybciej, ponieważ pod spodem
w samym tym kroku gdzie wysyłamy maila dodaliśmy to opóźnienie 3 minutowe, więc
tutaj spokojnie może to być current date.
Tu dodatkowo jeszcze zaznaczamy Ignore Privacy Rules.
is Kiedy będziemy uruchamiać taki workflow?
I teraz tak naprawdę pierwsze back end Workflow zostało utworzone
zostało tutaj zaplanowane i oczywiście tutaj się ono wykona.
Spróbujmy może właśnie przejść do Data.
Mamy tutaj tego użytkownika, który jeszcze nie przeszedł od buildingu, więc jeśli
uruchomię sobie stronę jako on, powinienem trafić na drugi krok.
Czyli zaznaczmy sobie tutaj, że jest to konto gościa.
Obrazka nie musimy wgrywać.
Podajmy tutaj jakieś podstawowe informacje.
William Smith.
Low.
Wybierzmy tutaj jakiś jeden język.
Dodajmy jeszcze jakiś fan number.
Czy mamy tutaj jeszcze coś?
Tak, chyba mamy wymagany również obrazek.
Spróbujmy tutaj coś grać.
OK, teraz tam się ten przycisk odblokował.
OK, fotka nie do końca pasuje do Williama, ale nas to już nie interesuje.
Klikamy Save and profit, więc nasze workflow powinno się uruchomić.
OK, zostałem przekierowany do Dashboard.
Jeśli przejdę do use listy to mam tutaj default
a dodatkowo powinienem jeszcze otrzymać maila na swoją skrzynkę odbiorczą.
A więc sprawdźmy, czy tak rzeczywiście się stało.
Czy to workflow nam się tam odpowiednio wykonało?
Zerknijmy tu.
Mam Office Takes OK, więc powinno nam to trafić tu.
Aha, oczywiście czekam na maila, który dotrze do nas za
około 3 minuty, a więc musimy oczywiście chwilę poczekać zanim
taki się tutaj pojawi.
Natomiast skoro to pierwsze back end workflow mamy
gotowe, to może dodajmy jeszcze tutaj jakieś kolejne.
Ja w tym celu chciałbym wysłać dodatkowego maila po bookingu, jak
pamiętasz szybu Kinga.
Rozmawialiśmy sobie o tym, że kiedy taki booking się zakończy, po
trzech dniach chcemy wysłać do użytkownika maila z prośbą o wystawienie recenzji.
Dzięki Back and Workflow możemy sobie właśnie to odpowiednio zaplanować.
Jak to zrobić?
Otóż ja dodałem sobie już odpowiednią klatkę w tym celu stóp.
Pakowałem sobie po prostu to łapką email, a następnie przeszedłem do ustawień
i wprowadziłem kilka zmian.
Przede wszystkim dodałem sobie spaceru o wartości 20 pikseli, żeby
odsunąć ten obrazek od góry.
Sam obrazek tutaj włączyłem na tą opcję i ściągnąłem sobie na całą szerokość,
a kolejno przeszedłem tutaj do tej opcji Edit module HTML
i w tym miejscu dla atrybutu source, który odpowiada za link do takiego obrazka
wstawiłem jak widzisz tutaj odpowiednią zmienną o nazwie Image Link.
Kolejno tutaj pozostaje nam name.
Tu dodałem odpowiednią treść.
Mam kolejną zmienną listing name, czyli nazwę takiego listingu.
Kolejno dodałem tutaj po prostu button, Pozmieniałem kolory,
dałem odpowiedni text, a link to znów kolejna zmienna tym przypadku login link.
Dlaczego robię to jako zmienną?
Otóż będę chciał testować templatki zarówno
wersji deweloperskiej, jak i produkcyjnej naszej aplikacji i wtedy ten link do
logowania nieco się będzie różnił, ażeby po prostu nie musieć za każdym
razem to odpowiednio zmieniać.
Wystarczy, że utworzymy tutaj zmienną i zadbamy o to w samej aplikacji i tam
będziemy po prostu przekazywać link albo właśnie do strony logowania wersji dev,
albo do strony logowania wersji prod.
Tutaj pozostawiam to samo.
W ten sposób mamy taką prostą templatki, którą teraz możemy wykorzystać.
Ja już sobie utworzyłem tutaj akcje na stronie PUT.
Mam tutaj workflow i tutaj wysyłam właśnie takiego maila z prośbą o review.
Tu mam book PW.
Może dajmy dokładnie ten sam tytuł, czyli o właśnie ten sam.
Niech on będzie tu i tu.
I teraz tak kopiujemy sobie znów tą akcję i przechodzimy do Back and Workflow
i dodajemy kolejny workflow.
Tym razem będzie to Send Booking Review.
Email znów wykonujemy tylko w obrębie aplikacji.
Wklejamy sobie tą akcję.
I zerknijmy co tutaj mamy.
Potrzebujemy adres odbiorcy.
OK, czyli na pewno będziemy potrzebować usera.
Dodajmy sobie taki parametr.
Data type. Oczywiście tutaj jest user kolejno.
Co my tutaj jeszcze mamy?
Zamieńmy to odpowiednio od razu na user email.
I mamy tutaj jeszcze sporą listę parametrów.
Przede wszystkim mamy tutaj link do listingu Main Image z naszego listingu.
Potrzebujemy tutaj jeszcze nazwę takiego listingu login login link.
W tym przypadku będziemy przekazywać link do logowania.
I tu od razu mogę Ci pokazać w jaki sposób możesz to zrobić.
Tu mamy link do strony w wersji testowej.
Natomiast jeżeli chciałbym to od razu tutaj przekazywać
link również do wersji produkcyjnej, to mogę to zrobić w ten sposób.
Wycinam to i tutaj wybieram sobie Isn't life version i uważaj, bo
to jest takie trochę podchwytliwe.
To oznacza, że to nie jest wersja life, czyli to jest wersja produkcyjna.
Jeśli tu zaznaczymy Yes.
To oznacza to, że IS I version is.
Czyli to jest wersja testowa.
Jeśli jest to tutaj wybieramy znane Ci już formaty z txt.
Czyli w tym miejscu wstawiamy link do wersji testowej,
a w tym miejscu wstawiamy link do wersji produkcyjnej.
One różnią się tylko tym, że nie ma tamtego version test.
Na razie pozostawiamy tu taką roboczą domenę Babel.
Oczywiście w przyszłości zadbamy o to, żeby tu była taka prawidłowa
domena, czyli Stay nest.
Natomiast właśnie w ten sposób możesz przekazywać linki do stron.
Jeśli zastosujesz taki zapis, to tutaj do wersji testowej.
Tak jak mówiłem tutaj do wersji produkcyjnej klikam Close.
Mamy tutaj name.
No to możemy sobie wywalić Hendrik, odnieść się do User first name.
I teraz zerknijmy tutaj.
Odnosimy się do bookingu i tutaj odnosimy się do bookingu.
A więc jak się domyślasz, kolejnym parametrem będzie po prostu booking.
Data type to oczywiście booking.
I teraz możemy sobie tutaj to odpowiednio powyciągać.
A więc odnoszę się do Booking.
Z tego wyciągam listing, a w zasadzie mogliśmy nawet tutaj listing przekazywać.
Ale to nic.
Niech to będzie w ten sposób, czyli booking.
Z tego wyciągamy listing i z tego wyciągamy sobie image main.
First item i URL do takiego obrazka.
Taki dosyć długi zapis, ale w ten sposób wstawi się tam
odpowiedni obrazek z takiego bookingu.
I teraz tutaj mogę wstawić sobie tą wartość i to będzie booking listing
po prostu name w ten sposób.
Teraz nasze workflow już tutaj będzie działało, będzie wysyłało odpowiedniego
maila, a my tylko oczywiście musimy je sobie zaplanować.
W tym celu przechodzę tutaj na stronę listingu, gdzie mamy
opcję tworzenia bookingu.
Wiemy co mamy rezerwować.
Tutaj tworzy nam się cały ten booking i zanim przejdziemy na stronę bookingu
to możemy sobie wybrać to w ten sposób, czyli schedule a po workflow.
Sandbox email user to będzie tak odnosimy się do krok 1
i będzie to oczywiście guest czyli gość w takim bookingu.
Sam booking to znowu po prostu rezolutna w Step 1 gdzie tworzyliśmy
właśnie taki booking.
I teraz schedule Date.
Kiedy chcemy właśnie uruchomić takie workflow chcemy się odnieść znów
do bookingu, do end date, czyli daty zakończenia.
I tutaj dodać.
Jak widzisz mamy opcję days 3 dni, a więc kiedy taki booking
ulegnie zakończeniu dodajemy 3 dni i wtedy uruchamia się taki workflow.
Zaznaczamy tą opcję i teraz moglibyśmy właśnie utworzyć taki booking.
Co zresztą możemy zrobić?
Sprawdzimy, czy to się odpowiednio utworzy i przy okazji pokaże Ci, gdzie w ogóle
szukać takich zaplanowanych workflow.
Ale w tym celu muszę przejść tutaj. Odświeżyć.
Zaloguj się jako demo Guest.
Mamy tutaj jakiś booking.
Ja tu dodatkowo dodałem jeszcze opcję, że po kliknięciu w
nazwę będę kierowany na stronę danego listingu i teraz będę mógł
sobie dodać kolejny booking.
Daty pozostawiamy tak jak są.
Dodajmy tutaj jednego usera.
Klikniemy Book. bąknął.
I wygląda na to, że taki booking został utworzony, a więc nasze workflow
powinno zostać tutaj zaplanowane.
A gdzie je sprawdzić?
W tym celu przechodzimy do zakładki Logs do Scheduler.
I tu mamy listę wszystkich zaplanowanych workflow.
Jak widzisz mamy informację kiedy ono się wykona tutaj.
U mnie to będzie 28 lipca.
I tutaj mamy nazwę takiego workflow i jego ID oraz właśnie tutaj te parametry,
które przekazaliśmy, czyli user oraz Booking.
W ten sposób właśnie możesz sobie planować na przyszłość takie workflow.
Tu możesz je pokazać, możesz je sobie pauzować.
Jeśli byś potrzebował instalować wszystkie lub tylko pojedyncze.
Czasami po prostu coś źle wpiszesz.
Takie workflow zostanie zaplanowane, a będziesz chciał je odwołać.
Więc w ten sposób możesz kliknąć Cancel to się oczywiście wykona.
Takie workflow zostanie anulowane.
A więc wiesz już jak uruchamiać takie workflow.
Od razu wiesz jak je sobie zaplanować.
Natomiast teraz chciałbym pokazać jeszcze bardzo ciekawą opcję, a mianowicie
uruchomienie takiego workflow na liście.
Jak to zrobić?
Wracamy do back end workflow i co w zasadzie będziemy chcieli tu zrobić?
Ja chciałbym stworzyć workflow, które będzie usuwało pliki.
Jeżeli użytkownik podczas np.
dodawania nowego listingu wyczyści listę z danymi już wcześniej plikami.
Pamiętasz?
Daliśmy mu taką opcję, że najpierw wgrywa sobie obrazki,
my tworzymy podgląd, on klika dalej, a my je po prostu wgrywamy na serwer i
przypisujemy do danego listingu.
Ale on może sobie wrócić i po prostu kliknąć tam opcję Clear all.
Ja chciałbym właśnie, żeby takie pliki po prostu były usuwane z naszego serwera
aplikacji, żeby nie zaśmiecać cały po prostu przestrzeni dyskowej i nie
marnowały tak bardzo cennych GB, za które musimy potem płacić.
A więc w tym celu nadaję sobie tutaj w workflow, nazwijmy je delete file.
Znów odznaczamy to Wykonujemy je po stronie naszej aplikacji i w tym
przypadku mamy tutaj właśnie gotowe.
Łapię Delete an uploaded file.
No i teraz musimy przekazać URL do takiego pliku.
A więc jak się domyślasz, musimy przekazać tutaj po prostu plik, czyli file.
I tutaj będzie to również file.
Teraz możemy się do tego odnieść i wybrać URL.
I to jest cała akcja, którą musimy tutaj wykonać.
Natomiast właśnie mówiłem, że będziemy to wykonywać na
liście, a tutaj wybrałem parametr i nie zaznaczyłem tej opcji.
Dlaczego?
Dlatego, że chcę, aby właśnie takie workflow wykonywało się na pojedynczym
elemencie, czyli na pojedynczym pliku.
W ten sposób mając właśnie taką opcję, będziemy mogli je uruchomić na
liście i Babel zrobi to w ten sposób.
Tam, gdzie przekażemy listę, weźmie sobie pierwszy element.
Uruchomi to workflow, przekaże tutaj ten plik i wykona.
Dodatkowo będzie się starał wykonać tę operację jak najszybciej.
To jest właśnie zaleta operacji, a w zasadzie wykonywania
takich workflow na liście.
Jest ona niesamowicie szybka.
To oczywiście mamy pewne ograniczenia.
Ile takich plików na liście może być.
Natomiast to się zmienia dosyć dynamicznie, Bubble cały czas to rozwija.
Tak więc po prostu jeśli będziesz chciał wykonywać taką operację na bardzo dużej
liście, to najpierw sprawdzić do dokumentacji jak duża ona może być,
ponieważ tak jak mówię, może się to bardzo szybko zmienić.
OK, stworzyliśmy takie workflow.
Ono się ma wykonać na pojedynczym pliku, a my teraz przekażmy sobie
listę takich plików.
Wróćmy chyba na stronę New listing, o ile dobrze pamiętam.
I tutaj zerknijmy. Tu mamy Clear all photos.
O właśnie.
Tu mamy akcję, która tak jak mówię, usuwa nam wszystkie obrazki
przypisane właśnie do Image Strict.
Natomiast zanim to zrobimy, to chcę właśnie usunąć takie obrazki.
Tutaj tylko po prostu czyścimy listę, a te obrazki będą po prostu dalej na naszym
serwerze i będą dalej zaśmiecać nam przestrzeń dyskową.
A więc najpierw chciałbym sobie właśnie tutaj wybrać
schedule, tym razem nie Schedule API Workflow, a Schedule a Workflow okna List.
I teraz tak typeof.
Na czym chcemy to uruchamiać?
Chcemy to uruchamiać na plikach, czyli file.
Na jakiej liście plików w ogóle chcemy to uruchomić?
Na Parent Pages Listing Images List.
Jakie API chcemy tutaj uruchomić?
Third file?
I teraz tutaj.
Jeżeli kliknie, to mogę jak widzisz odnieść się do DC
File, czyli do tego pliku z tej listy Po prostu weźmie każdy plik osobno i na
każdym z nich zaplanuje sobie oddzielnie takie workflow czyli dis file.
Tu wybieramy od razu Current Date time.
Uruchomimy to jak najszybciej, to możemy jeszcze dodać odpowiednie
odstępy pomiędzy takimi operacjami.
Natomiast Pablo zaleca, żeby zostawić to puste.
Wtedy on wykona to jak najszybciej będzie mógł.
Im bardziej skomplikowane takie workflow będzie, które będzie uruchamia na liście,
tym większe powinien być ten interwał czasowy, tak aby te operacje odpowiednio
się wykonały i po prostu nie zastanawiały Ci serwera na Mackenzie, żebyś nie robił
ich po prostu za dużo na raz, ponieważ wtedy może spaść Ci
wydajność całej aplikacji.
Ja natomiast wiem, że tych plików u nas będzie tam chyba maksymalnie 6 albo 8.
Nie pamiętam ile dokładnie tego ustawiliśmy.
A więc ta lista jest niewielka.
Nie musimy się bawić w ustawianie interwałów.
I teraz właśnie użytkownik, kiedy kliknie w taki przycisk,
najpierw zaplanuje właśnie to workflow na całej liście,
my pozbędziemy się niepotrzebnych plików, a potem po prostu właśnie oczyścimy
tę kolumnę przy naszym listingu.
Mam nadzieję, że rozumiesz jak to działa i jak działa.
Uruchamianie workflow na liście Jest ona bardzo podobne do
takiego właśnie zwykłego workflow.
Tylko tutaj właśnie musimy przekazać listę, a resztą zajmie się już sam Babel.
Kolejnym typem workflow, jakie możemy uruchomić w Babel to Workflow, gdzie
trigger jest zmiana w bazie danych.
Jak to zrobić?
Ja chciałbym przede wszystkim wrócić tutaj do elementu Host Booking srl, gdzie
wyświetlamy hotelowi wszystkie booking.
Jak pamiętasz tutaj dodaliśmy mu pole typu Search box, gdzie on może sobie
wyszukiwać właśnie listing.
Czyli przeszukuję booking po nazwie listingu.
Mam nadzieję, że pamiętasz tą lekcję.
I tu niestety właśnie nie mieliśmy nazwy takiego listingu bezpośrednio właśnie w
bookingu i musieliśmy mu wyświetlić wszystkie jego listingu.
Z jednej strony to działa, natomiast z drugiej nie do końca, bo jeśli
wyświetlimy mu np.
setkę listingu, a booking będzie miał tylko do dwóch, no to trochę średnio.
Wolelibyśmy jednak, żeby tu się właśnie pojawiały nazwy tylko tych listingu.
Chociaż oczywiście tutaj user coś sobie zablokował, a więc w tym celu
możemy przejść do Data.
Naszego bookingu i dodać tutaj po prostu nowe pole, żebyśmy mieli w tzw.
flat data, czyli po prostu listing.
Niech to będzie zwykły tekst.
I teraz tak.
Tu możemy sobie wrócić do tego pola Search box i tutaj będzie listing.
Nie, przepraszam, nie listing, tylko tym razem booking.
I tutaj.
Tak, wszystkie booking, gdzie oczywiście hostem jest current user.
A właśnie w ten sposób, czyli wyświetlamy wszystkie jego booking, te które
rzeczywiście zostały utworzone i chcemy teraz to przeszukiwać
po polu Listing name.
Czyli mamy takie bardzo fajne, proste wyszukiwanie.
Skoro dodaliśmy to pole, to teraz zadbajmy też również o to, aby właśnie taką wartość
uzupełniać w momencie tworzenia takiego bookingu.
Czyli wracamy tym razem znów na null.
Sting a w zasadzie przepraszam Cię, nie na new listing, tylko na listing
na stronę liftingu.
To workflow, na którym pracowaliśmy przed chwilą, czyli rezerw.
I tutaj właśnie, kiedy tworzymy nowy booking, od razu uzupełniamy listing name.
Jest to parent club listing.
I oczywiście name.
Mam nadzieję, że rozumiesz co teraz zrobiliśmy, dlaczego dodaliśmy takie pole
pomocnicze i skąd wyciągamy te wartości.
Natomiast takie działanie przyniesie nam jeden mało przyjemny efekt.
Rozważmy taki przypadek, że nasz host dodaje sobie nowy listing.
Nazwał go np. mój listing i zostawił w serwisie.
Użytkownika mu się spodoba.
Stworzyli do niego kilka rezerwacji, czyli kilka bookingu, ale nasz host
po drodze stwierdził, że ok.
Nazwa Mój listing jakoś mało przekonuje użytkowników i przydałoby się
ją zmienić na jakąś inną np.
mój super listing, dzięki czemu więcej osób zakupuje pobyt.
I tu właśnie pojawia się ten problem.
Nazwa zmieni się na listingu, ale nie zmieni się na booking, które zostały
dla takiego listingu już utworzone.
Musimy więc zadbać o to, aby to odpowiednio zaktualizować i w tym celu
możemy właśnie wykorzystać ten trigger.
Przechodzę do Back and Workflow.
Tutaj właśnie do tych naszych workflow.
I tym razem wybieramy stylistę New Database Trigger Event.
Klikam.
I teraz dajmy tutaj nazwę Update booking Listing name.
Jak widzisz ja staram się stosować jak najbardziej opisowe nazwy,
mimo że czasami one są dosyć długie, ale dzięki temu łatwiej jest mi potem
rozpoznać co dany workflow robi.
I teraz tak Type będzie to listing, ponieważ będziemy nasłuchiwać
na zmianę na listingu.
Tutaj na razie generujemy żadnego folderu I teraz właśnie tutaj musimy zastosować
odpowiedni trigger, czyli kiedy to mamy się uruchomić.
A więc tak wybieramy, że listing przed zmianą, czyli listing
before change to pole name.
Nie jest równa is not.
Listing i pole name.
Przelicz w momencie jakichkolwiek zmian na listingu czy jego utworzeniu.
Babel będzie tutaj właśnie to porównywał.
Czyli nazwa takiego listingu przed zmianą nie jest równa nazwie po zmianie.
Czyli jeśli użytkownik zmieni nazwę dla takiego
listingu, to nasze workflow się tutaj uruchomi, a my możemy.
Co zrobić? Możemy właśnie wybrać tutaj.
Make changes a list of things.
Co chcemy zmienić tutaj?
Chcemy zmienić wszystkie bookingu.
Tutaj trzymamy je przypisane do listingu.
Zaraz zerknijmy.
Nie, tutaj Chyba nie.
Musimy w takim razie zrobić to w ten sposób, czyli
wyszukać sobie wszystkich bookingu, czyli Dual Search for booking,
gdzie listing jest równy.
Czy będzie to listing przed zmianą czy po zmianie to nie ważne, ponieważ zwróci
nam to dokładnie ten sam z bazy danych.
Możemy wybrać listing dał ok.
To nam da właśnie całą listę bookingu jeśli one będą istniały.
Jakie pole chcemy tutaj zmienić?
Chcemy zmienić listing name i tym razem odnieść się właśnie do tej
nowej nazwy, czyli do listing i wyciągnąć sobie tutaj name.
Tak, wiem, że na początek jest to dosyć skomplikowane, natomiast mam nadzieję, że
rozumiesz samą ideę, czyli jak to działa?
Dlaczego tutaj właśnie wykorzystujemy te dwie wartości?
Ponieważ właśnie za ich pomocą będziemy mogli porównać, czy jakaś
kolumna nam się zmieniła, czy wartość w danej kolumnie, a w zasadzie czy
wartość w danej kolumnie się zmieniła.
Czyli listing B for change i listing.
U nas jest to pole name.
Jeśli ono nie będzie takie samo, to znaczy, że właśnie musimy zaktualizować
ten listing name we wszystkich bookingu, które jest, które są
przypisane do danego listingu.
Tak działają właśnie Database Trigger.
Wymagają one nieco cierpliwości i trochę wiedzy.
I oczywiście praktyki, praktyki i jeszcze raz praktyki.
Ich zaletą jest to, że ustawiasz je raz i nie musisz o tym pamiętać.
Wadą jest to, że jakakolwiek zmiana na listingu będzie uruchamiała workflow.
Natomiast myślę, że u nas po utworzeniu właśnie takiego listingu to pole nie
powinno się tam zmieniać zbyt często.
Raczej i userzy nie będą tak bardzo często zmieniać nazwy takiego
listingu, więc możemy sobie to zostawić i w ten sposób właśnie
tutaj wtedy aktualizować te booking.
Ostatnim tematem, który chciałbym poruszyć w tej lekcji Tak, wiem, że będzie ona
dosyć długa, natomiast chciałbym zebrać te wszystkie informacje właśnie w jedno
video, a tym tematem będą live rekordowe workflow, czyli workflow, które
będą się wykonywać jedno po drugim.
Dlaczego to jest tak ważne?
Otóż mamy tutaj np.
właśnie tą opcję, czyli to workflow, gdzie ona się uruchamia na liście.
Natomiast jego największą wadą jest to, że bubel w żaden sposób nie informuje nas, że
takie workflow rzeczywiście wykonało się na wszystkich tych elementach.
I czasami niestety ta wada dość mocno rzutuje na to, co będziemy chcieli zrobić.
Ja na przykład będę chciał przejść tutaj do naszej wish list,
czyli guest wish list.
A właśnie Re.
I tutaj dla właśnie tych elementów, czyli wish list kart, dodajmy button delete.
Image na sam dół.
A w zasadzie może zróbmy tak.
Skopiuję sobie ten button.
Czy mamy tutaj jakieś style? Danger?
Mamy Button, Danger, Big.
Dajmy tu na razie Delete.
I oczywiście dodajmy Condition. Ale.
Że ten button.
Dla Parent Group wishlisty.
Jeśli ona jest default owa, to się nie wyświetla.
Natomiast pojawia się dla każdej innej listy.
I teraz tak.
Po kliknięciu w taki button będę chciał usunąć zarówno samą już listę
jak i odznaczyć polubienia.
We wszystkich elementach, czyli we wszystkich tych stringach,
które się tutaj znajdują.
A więc klikamy sobie tutaj Add Workflow.
A i właśnie i będziemy musieli tutaj zaplanować właśnie
nasze back end workflow.
Dlaczego ono nie może zadziałać na liście?
No właśnie dlatego, że ja najpierw chcę odznaczać właśnie te polubienia i dopiero
wtedy, kiedy one się wszystkie odznaczyć, chcę usunąć właśnie taką wish listę.
Czyli najpierw muszą się te odznaczenia pousuwać.
Aby więc to zrobić, dodajemy sobie pakiet workflow.
I teraz tak nowe API Workflow.
Nazwijmy je po prostu wyślij.
I co mamy tutaj?
Co będziemy przekazywać?
Będziemy chcieli usunąć całą listę.
No to to jest jasne.
To będzie oczywiście typ wish list.
I tutaj dodatkowo jeszcze chciałbym przekazać od razu listę wszystkich listing
ów, z których musimy usunąć polubienie.
Jak pamiętasz, jeżeli przejdę do Data type do Listing, nie mamy tutaj właśnie
Like by i lista użytkowników.
Czyli jeżeli użytkownik polubi właśnie taki listing, to go dodajemy tutaj do tej
listy, a dodatkowo ten listing dodajemy właśnie do już listę.
Jeśli nie pamiętasz jak to działało, to odsyłam Cię do odpowiedniej lekcji.
Właśnie tworzyliśmy takie wishlisty, a więc chcę tu przekazać samą już listę
oraz listę listingu, czyli listing.
To będzie lista i tym razem będzie to listing.
Po prostu w ten sposób.
Dobra. I teraz tak.
Najpierw sobie wywołamy taki workflow, czyli.
Gest wishlisty.
O właśnie, to.
A w zasadzie przepraszam, to była ta karta, więc tu mamy ten button.
Edit Workflow i tutaj schedule.
Wish list I tak.
Jaka to jest lista?
To jest parent club Wish list.
List.
To jest parent group, wish list, Lista castingów.
To się zgadza.
Parent date.
I Privacy rules.
I teraz możemy przejść do takiego workflow.
Wystarczy, że kliknę tutaj prawym przyciskiem myszy, wybiorę Edit Workflow
i zostanę od razu do niego przekierowane.
I tu pokażę Ci jak tworzyć tzw.
live workflow, czyli workflow, które będzie się rozumiało
na pojedynczym elemencie, będzie wykonywało operację, na pierwszym coś tam
zrobi, potem usunie go z listy, przejdzie do następnego elementu,
znów coś na nim wykona, znów usunie go z listy i będzie się powtarzało tyle razy,
ile takich elementów na tej liście będzie miało.
Czyli u nas przejdzie przez całą listę listing ów i dopiero kiedy ta lista się
wyczerpie, oznaczymy sobie listę do usunięcia.
A więc wybieram tutaj tak make changes swing.
Czyli właśnie do takiego listingu odnoszę się do pierwszego elementu z
listy, czyli First item i chcę tutaj zmienić pole like.
O właśnie I remove.
Musimy tutaj jeszcze przekazać 0.
A chyba nawet nie wystarczy, że odniesiemy się dołu listy o Ida Ownera.
O właśnie, czyli właściciela takiej listy i on powinien zostać usunięty
z tej kolumny Like B.
W ten sposób od linkujemy właśnie taki listing.
I ok, to jest jedyna operacja, którą na razie tutaj musimy
wykonywać te kilka razy.
Natomiast jak uruchomić takie workflow ponownie?
Wybiorę tutaj opcję Schedule i w tym przypadku odnoszę się
dokładnie do tego samego workflow.
Tworzę taką pętelkę, czyli wykonaj to API raz, potem wykonaj mi je
ponownie, ponownie i ponownie.
I teraz tak wish listę.
Za każdym razem będzie ta sama. Ona będzie jedna.
Tutaj zostawiamy Current Date Time Ignore Privacy rules.
I teraz uważaj w jaki sposób ja będę odejmować te elementy.
Ten zapis na początku bywa dosyć skomplikowany, ale jeśli na spokojnie
sobie siądziesz i go przeanalizujesz, to nie okazuje się wcale tak trudny.
Przede wszystkim odnoszę się tutaj do tej listy castingów i od niej odejmuje
item list things first item.
Czyli tutaj wykonaliśmy operacje właśnie na tym pierwszym elemencie z listy,
a tutaj odejmujemy go z tej listy, czyli odnosimy się do całej tej listy
listingu i wyrzucamy ten pierwszy.
I chcemy to wykonywać tak długo, jak właśnie cała ta lista, czyli
count jest większa, równa 1.
To jest super, bardzo ważny warunek, ponieważ jeśli źle to ustawisz, to taka
lista będzie się wykonywała w nieskończoność.
Gdybyśmy tego nie dodali, to byśmy usunęli pierwszy, drugi, trzeci,
usunęli ostatni i nie dodali czarnej blokady.
To workflow uruchamiało by się ponownie.
Oczywiście tutaj nie miałoby żadnego elementu, więc nic by się nie wykonało,
ale znowu uruchamiało by się jeszcze raz, jeszcze raz i jeszcze raz.
I teraz Babel troszkę to poprawił.
Zaraz przejdziemy do odpowiednich ustawień, gdzie możemy właśnie zablokować.
Ile razy taka operacja właśnie w danym workflow ma się wykonać.
Dodatkowo mamy jeszcze blokadę, że jeżeli czerpiemy workflow unit
to nasza aplikacja się zatrzyma na samym początku kiedy je dodali.
Niestety takiej blokady nie było i spotkałem się z bardzo dużą ilością
narzekań, że użytkownicy nie do końca wiedzieli jak uruchomić taką pętlę.
Ona się wykonywała w nieskończoność i zabijała im tym samym właśnie to workflow
unit i potem pojawiały się rachunki na dziesiątki tysięcy dolarów, euro
złotówek, czymkolwiek tam płacili.
Dlatego przeanalizuj proszę sobie na spokojnie ten zapis.
W tym miejscu będziemy ponownie uruchamiać właśnie to całe workflow.
A teraz mogę sobie skopiować to.
I dodać tutaj opcję Delete Fink.
W tym miejscu będziemy usuwać wish listę. Kiedy?
Kiedy?
Właśnie ilość takich listingu do obsłużenia będzie równa zero, czyli w
naszym przypadku mniejsza od jednego.
Mam nadzieję, że rozumiesz jak to działa.
Czyli uruchamiamy pierwszy raz, przechodzimy przez pierwszy element
pierwszego listingu, usuwamy to polubienie.
Potem ten pierwszy listing wywalamy z listy.
Jeśli tam są jeszcze jakieś listing, to znów przechodzimy od początku.
Przechodzimy tutaj.
I taką pętelkę sobie tworzymy.
Natomiast w momencie, kiedy ta lista z listingu jest już pusta, od pakowaliśmy
wszystkie, to możemy po prostu usunąć taką listę.
Tak działają właśnie Cars i Workflow.
A jeśli przejdziemy do Settings?
Jak widzisz, możemy tutaj dodać tzw. depot, czyli inne.
Właśnie tak jak mówię ile takich powtórzeń może się wykonać?
Tu musisz sobie sam to oszacować.
Ja mogę dodać powiedzmy tutaj.
Myślę, że 100 elementów na liście to będzie i tak bardzo dużo,
a więc dodajmy tutaj 100.
Czyli jeśli taka pętelka dojdzie do 100 powtórzeń, to się po prostu zatrzyma.
I bubble samo to właśnie wyłączy, niezależnie od tego, czy tam rzeczywiście
jeszcze będą jakieś elementy, czy nie.
Dlatego warto właśnie sobie tak powoli oszacować, zastanowić się, ile
takich powtórzeń może się pojawić.
Jak widzisz mamy tutaj dosyć dużo operacji.
Może to być np. 500 000 takich powtórzeń.
Tak więc odpowiednio to sobie szacujemy. Dodajemy tutaj.
I w ten sposób mamy takie dodatkowe zabezpieczenie, że to workflow nie będzie
nam się tak uruchamiało w nieskończoność.
Jak więc widzisz, Back and Workflow mają bardzo szeroki zakres zastosowań i tak
naprawdę chwilowo działamy tylko w obrębie naszej aplikacji.
Za co odpowiada właściwy checkbox, czyli właśnie ten, który cały czas
zastosowaliśmy, a mianowicie.
A tutaj sobie tego nie zaznaczyliśmy odpowiednio, czyli ten.
Nie chcemy tego publikować jako zewnętrzne, tylko jako
wewnętrzny workflow.
W ten sposób do takiego właśnie back and workflow nie ma chwilowo dostępu nikt z
zewnątrz, ale oczywiście tą funkcję możemy zmienić.
Natomiast tym tematem zajmiemy się już w jednej z kolejnych lekcji.
A ja teraz dziękuję Ci za uwagę w tej dość długiej lekcji.
Mam nadzieję, że była ona dla Ciebie bardzo interesująca.
Wiem, że było tutaj bardzo wiele nowych informacji i bardzo dużo
tematów związanych z logiką.
Tak więc proszę Cię, uruchom ją sobie na spokojnie i jeszcze
raz przeanalizuj dokładnie, krok po kroku co tutaj zrobiliśmy, tak abyś wyciągnął z
niej jak najwięcej i jak najlepiej zrozumiał jak działają
właśnie back and workflow.