MVP aplikacji w rekordowym czasie z Bubble: Kilka słów o optymalizacji

0:00Zanim przejdziemy dalej i zadbamy o to, aby wyświetlić pobrane dane użytkownika

0:04lub pozwolić mu je edytować, chciałbym jeszcze na chwilę wrócić od tego, co

0:07przygotowaliśmy we wcześniejszej lekcji.

0:10Jak sam widzisz, nasz workflow jest tak naprawdę banalnie proste.

0:13Jedyne co robimy to pobieramy dane, które nasz user przekazał do pól formularza i

0:18kolejno aktualizujemy właściwy rekord w bazie danych.

0:21Jeśli będziemy stosować odpowiednie nazewnictwo i nazywać nasze pola w

0:24formularzu tak jak mamy nazwane kolumny, to całość sprowadza się właściwie do dość

0:28banalnego klikania właściwych wartości.

0:31Natomiast sam ten proces mógł być nasunąć dwa pytania, które teraz

0:34chciałbym zaadresować.

0:35Pierwsze z nich brzmi Skąd Babel wie, które rekord ma zostać zaktualizowany?

0:40Przecież w bazie możemy mieć miliony rekordów użytkowników, a nie wskazaliśmy

0:44w żaden sposób, który z nich ma to być.

0:46A przynajmniej nie bezpośrednio podając jego ID.

0:49To jednak nie do końca jest prawda, ponieważ z pomocą przychodzi nam tutaj

0:52wbudowana akcja, która odnosi się do obiektu Parent User i jego edycji.

0:56Czyli to właśnie tutaj ta akcja make changes to parent user to Babel zadbał dla

1:00nas o to, by wśród tych milionów rekordów w bazie namierzyć to, które użytkownik

1:04jest teraz zalogowany na swoje konto i wykonuje operacje w naszej aplikacji.

1:09A my poprzez te gotowe akcje możemy nie tylko w prosty sposób pobierać sobie jego

1:12dane, co już udowodniłem w przykładzie kierowania usera na stronę od brandingu,

1:16gdy flaga finish boarding jest równa.

1:18nowa, ale także szybko aktualizować ten rekord lub go usunąć.

1:22Takie uproszczone działanie poprzez obiekt karencji user jest dostępne tylko i

1:26wyłącznie dla tego Data type i niestety w przypadku innych typów danych namierzenie

1:30odpowiedniego rekordu będzie odrobinę trudniejsze.

1:33A teraz czas na drugie pytanie.

1:34Jeśli przyszło Ci do głowy, to jestem naprawdę dumny.

1:37Jeśli jeszcze raz spojrzymy na nasze workflow, to całość sprowadza się do tego,

1:41żeby działania użytkownika w formularzu odzwierciedlić w naszym rekordzie w bazie.

1:45Więc skoro i tak koniec końców zapisujemy te wybory poprzez aktualizację rekordu

1:50Karen User, to mógłbyś zapytać dlaczego poprzez workflow nie ustawiamy od razu

1:54odpowiednich wartości dla user type lub wybranych języków?

1:57Po co utrudniamy sobie życie i korzystamy z custom states?

2:00Przecież równie dobrze po wybraniu danej opcji dla typu konta moglibyśmy od razu

2:04zaktualizować tą wartość w bazie danych, a potem podobnie jak robimy teraz w

2:08zakładce Condition, ale mogę tutaj do niej wrócić.

2:12Czyli właśnie odnoszę się do całej grupy Guest.

2:15Tutaj tej zakładki Condition All i tego warunku.

2:18Moglibyśmy się odnieść bezpośrednio do tego rekordu w bazie danych,

2:21a nie właśnie do Custom Stats.

2:23Jest to oczywiście jak najbardziej poprawny tok rozumowania, ale ma jedną

2:26zasadniczą wadę jaką jest szybkość działania, co wpływa na optymalizacje

2:30tego, jak użytkownik czuje się w naszej aplikacji, A mówiąc prościej chciałbym,

2:34żebyś to zapamiętał, jeśli dopiero wkraczasz do świata budowania aplikacji.

2:38Użytkownik w większości przypadków wymaga, aby jego działania przynosiły

2:42natychmiastowy skutek.

2:43Jeśli więc klika w grupę symbolizującą dany typ konta, to musi otrzymać

2:47natychmiast info zwrotne, że coś się zadziało.

2:49I tak właśnie jest.

2:50W naszym przypadku jest to po prostu zmiana koloru obramowania.

2:53Mogę Ci to udowodnić.

2:54Wystarczy, że wrócimy na stronę rejestracji i

2:57spróbujmy tutaj dodać kolejne konto.

3:06Ja korzystam ze standardowego tutaj typu notatki dla moich użytkowników,

3:10czyli po prostu odnoszę się do tego głównego rekordu

3:13Office, a w zasadzie głównego maila Office News Info i poprzez ten parametr

3:18tworzę sobie takie subkonta.

3:21Proste hasło klikamy sign up.

3:26Jesteśmy teraz na stronie brandingu.

3:29Jak widzisz wystarczy, że kliknę tutaj.

3:32To obramowanie natychmiast się zmienia, co oznacza, że ten custom state został

3:36po prostu dla nas zaktualizowany.

3:38Jak więc sam widzisz, ten efekt jest po prostu natychmiastowy.

3:41I dzieje się tak dlatego, że wykorzystujemy właśnie custom state.

3:44Czyli jak już tłumaczyłem w pierwszej części kursu z wartości, które są

3:48przechowywane w przeglądarce usera.

3:50Jest to bardzo ważna zaleta custom states i chciałbym byś to dobrze zrozumiał,

3:54ponieważ kiedy pobieramy lub zmieniamy wartości zapisane, dzieje się to dosłownie

3:58w mikroskopijnych ułamkach sekund.

4:00Dla ludzkiego oka efekt jest po prostu niemal natychmiastowy.

4:03Natomiast w przypadku baz danych sytuacja wygląda zgoła inaczej.

4:07O ile nie korzystasz z planu dedykowanego w Babel, Twoja baza danych będzie

4:11zlokalizowana na serwerach w USA.

4:13To oznacza, że każde zapytania, jakie do niej wyślemy, nieważne czy będzie to

4:17pobranie danych, ich aktualizacja, czy też usunięcie wymaga nieco więcej czasu.

4:21Jest w dużej mierze zależne od szybkości łącza internetowego, z którego

4:25korzysta użytkownik Twojej aplikacji.

4:27Na pewno kojarzysz sytuację, gdy Twoje łącze internetowe łapie zadyszkę i strony

4:31zdają się ładować w nieskończoność.

4:33Tak naprawdę nie zawsze trwa to aż tyle, ale jesteśmy tak przyzwyczajeni do tego,

4:37że wszystko działa niemal natychmiast, że każde odstępstwo od normy wydaje się trwać

4:41znacznie dłużej, niż jest w rzeczywistości.

4:43W tej sytuacji, gdyby user wybrał właściwy typ danych, musielibyśmy najpierw wysłać

4:48taką informację do bazy danych w Stanach i tam odpowiedni rekord

4:51zostałby zaktualizowany.

4:52Ponieważ Babel posiada bazę typu real time, to oznacza, że automatycznie odsyła.

4:57Inaczej mówiąc, propaguje tę zmianę z powrotem do naszej aplikacji

5:00i przy przełącza tym krótszy czas takiej operacji.

5:03Ale nawet przy szybkich łączach potrafi to zająć chwilę, która ludzkie oko

5:06jest już w stanie wychwycić.

5:08Jest duża szansa, że użytkownik uzna, że to po prostu nasza aplikacja wolno działa

5:12i stwierdzi, że nie warto z niej korzystać.

5:14Czy więc zawsze musimy zapewniać mu natychmiastowy efekt?

5:17Jest to bardzo dobre pytanie, ale odpowiedź jak zwykle

5:20nie jest jednoznaczna.

5:21I znów brzmi to zależy.

5:23Jeśli jesteśmy w stanie tak zbudować daną funkcjonalność, by działała

5:26błyskawicznie, to zawsze to róbmy.

5:29Dlatego też zastanów się, czy możesz jakoś przyspieszyć dane

5:31działanie i skorzystać np.

5:33właśnie z custom stats, zamiast od razu odnosić się do bazy danych.

5:36Oczywiście nie zawsze będzie to możliwe, ale to wcale nie oznacza, że stoimy na z

5:40góry przegranej pozycji, ponieważ wszystko da się odpowiednio

5:43rozegrać właściwą komunikacją.

5:45Jeśli działania użytkownika powoduje zmiana np.

5:48bardzo wielu rekordów, co może zająć dłuższą chwilę,

5:51wystarczy wyświetlić odpowiedni komunikat o tym, że dana operacja zostanie

5:54zrealizowana w ciągu powiedzmy kilku kilkunastu minut, a jej

5:58zakończenie opowiadaliśmy my.

5:59Kolejnym komunikatem.

6:00Jest to nie tylko dobra, ale wręcz wskazana praktyka.

6:03Podobnie jak wyświetlanie loader ów, jeśli pod spodem coś się dzieje.

6:07Oczywiście musimy znać umiar, ponieważ nikt nie będzie siedział

6:09i czekał w nieskończoność.

6:11Ale jeśli zrobimy to z głową i dodamy do tego np.

6:14jakiś zabawny komunikat lub grafikę o ile się nie mylę, chyba MailChimp miał

6:18lub może nadal ma w zwyczaju wyświetlać info, że stado wyszkolonych małp właśnie

6:22pracuje nad wykonaniem danego zadania, to uwierz mi, że użytkownik to zrozumie.

6:27To Twoim zadaniem jako developera jest zadbać, aby użytkownik wykonując jakąś

6:31operację został w widoczny sposób poinformowany, że coś się dzieje.

6:35Jeśli bowiem doprowadzisz do sytuacji, że np.

6:38po kliknięciu w button nie otrzyma żadnej zwrotnej informacji,

6:41a efekt swojego działania zobaczę dopiero po dłuższej chwili,

6:44to możesz być w 100% pewien, że przestanie korzystać z Twojej aplikacji.

6:49Dlatego też chciałbym zadać Ci praca domową nieco.

6:51Może na przyszłość, bowiem proszę byś usiadł do niej dopiero po kolejnej lekcji,

6:56gdzie poruszymy temat tego, jak pobierać dane użytkownika.

6:59Spróbuj wtedy dla testu przebudować nasz obecny workflow tak, aby nie korzystało z

7:03custom state, tylko od razu zapisywało i pobierało dane z bazy danych.

7:08Sprawdź, czy zauważysz różnicę.

7:10Może ona być minimalna, ale jestem pewien, że uda Ci się ją wychwycić,

7:14a dodatkowo możesz również przejść do podglądu strony, czyli wybrać np.

7:19Zbadaj.

7:21Kolejno przejdź do zakładki Network i tutaj kliknąć tą opcję.

7:26Domyślnie ustawiona jest ona na Node Routing, ale możesz wybrać np.

7:31tutaj tą opcję Slow 3G.

7:32I właśnie za modelować sobie pracę na takim wolniejszym łączu.

7:36Jestem na 100% pewien, że wtedy na pewno zobaczysz różnicę.

7:40Jeżeli nie będziesz korzystał z custom stats, tylko odnosił się i wysyłał

7:43request bezpośrednio do bazy danych.

7:46To by było na tyle w tej lekcji.

7:47Ja dziękuje Ci w takim razie za uwagę, a w kolejnej zajmiemy się już pobieraniem

7:51i edycją danych użytkownika.