Jak budować wydajne aplikacje? Frontend, backend i no-code.

Cześć! Witam Was bardzo serdecznie w naszym kolejnym odcinku naszego podcastu JUST No-Code. Dzisiaj poruszymy temat bardziej techniczny niż biznesowy, organizacyjny czy tego typu. Dzisiaj porozmawiamy sobie dokładnie o tym, jak zadbać o odpowiedni performance aplikacji no code. Przejdziemy przez wszystkie aspekty takich aplikacji, które tworzycie za pomocą platform no code’owych. Ponieważ to, jak podchodzimy do ich tworzenia jest bardzo podobne do tego, jak robimy to w tradycyjnym podejściu, czyli musimy zadbać o takie aspekty jak odpowiednia struktura bazy danych, jak odpowiedni performance, przerzucenie pewnych rzeczy między Frontend Backend między serwerem a urządzeniem użytkownika. Musimy oczywiście odpowiednio podejść do planowania. Natomiast chcę Wam też dzisiaj powiedzieć o kilku istotnych aspektach, które są specyficzne dla świata aplikacji no code, szczególnie takich platform jak Bubble oraz Xano. Tak jak powiedziałem, temat dzisiaj będzie trochę bardziej techniczny. Oczywiście przejdziemy przez takie tematy jak planowanie. Oczywiście każdą aplikację, którą tworzymy, musimy odpowiednio zaplanować. Porozmawiamy sobie o tym, jak dbać o performance na Frontend, czyli po tej części użytkownika, której on de facto dotyka, którą on widzi. Jak komunikować się z tym użytkownikiem?

‍

Jak sprawić, żeby te aplikacje na tym Frontend nie zamulać były tzw. tak, żeby działały one w sposób odpowiedni? Oraz porozmawiamy sobie o performance na Backend, czyli jak sprawić, aby aplikacja już po stronie serwera również nam w żaden sposób nie opóźniła tego, czy nie zżerała zasobów serwera w jakiś straszny, niedorzeczny sposób. Więc zapraszam Was bardzo serdecznie. Dzisiejszy odcinek zaczynamy. Dobrze, więc porozmawiajmy sobie na początku o planowaniu. Za każdym razem, kiedy rozpoczynamy pracę nad nową aplikacją, powinniśmy się zastanowić de facto, czego ta aplikacja będzie dotyczyła i dlaczego powinniśmy to robić. Jak wiecie, każda aplikacja, każdy rodzaj aplikacji czy to będzie CRM Client Relationship Management, czy to będzie jakiś sklep internetowy, czy to będzie platforma do zarządzania zadaniami, czy to będzie jakaś platforma z listingu ofert pracy, czy to będzie platforma do zarządzania pracownikami w firmie, czy zasobami firmy musi być odpowiednio zaplanowana. Bardzo kluczową kwestią jest to, że kiedy zaczniemy, podejdziemy w ogóle do tworzenia aplikacji. Powinniśmy sobie oczywiście zadać pierwsze pytanie czym jest aplikacja, gdzie de facto będą te punkty, które najbardziej będą tą aplikację obciążały?

‍

Wiadomo, że ekrany takie jak ekran logowania czy rejestracji raczej nie są tymi ekranami które są najcięższe czy wykonują najcięższe workflow w naszej aplikacji. Więc powinniśmy się zastanowić ok. Gdzie mamy te punkty naszej aplikacji, których ewentualnie te problemy z performance mogą wystąpić? Gdzie nasi użytkownicy liczą na to, że coś się będzie działo szybko? A gdzie de facto są punkty, w których użytkownik będzie świadom tego lub będzie zmuszony do tego, ale odpowiednio poinformowany, że będzie musiał poczekać na wykonanie jakichś akcji? Musicie pamiętać o tym, że niezależnie od tego, jakiej aplikacji byście nie tworzyli czy jak infrastruktury nie mieli dostępnej zawsze trafić, zawsze może się trafić punkt taki, który będzie wymagał po prostu czasu na realizację i ten czas nie będzie liczony w sekundach, tylko np. w minutach w godzinach. I właśnie te punkty muszą być odpowiednio zaplanowane. Jak do nich podejść? Co w nich powinno się znaleźć? Jak poinformować użytkownika jak ten cały workflow rozbić między tą frontową częścią aplikacji, czyli tym co użytkownik widzi, a jak między serwerem, czyli tym, co de facto użytkownik nie widzi, ale dzieje się gdzieś poza jego de facto zakresem czy polem widzenia.

‍

Więc zawsze musimy sobie te aspekty dokładnie planować. Oczywiście w planowaniu mamy kilka innych aspektów, które powinniśmy brać pod uwagę i o których też będziemy mówili trochę dalszej części naszego dzisiejszego podcastu. Mianowicie jeżeli planujecie aplikację, to będziecie planowali również jej strukturę. Jeżeli będziecie planowali strukturę, to musicie się zastanowić nad tym, czy aplikacja będzie tzw. Single Page czy Multi Page, czy aby struktura bazy danych, którą będziecie robić teraz, czy chcecie ją zrobić po prostu jak najszybciej, bo chcecie po prostu zrealizować pomysł w jak najkrótszym czasie, co też jest ok, ale ma również swoje minusy takie, że jeżeli nie zadbajcie o odpowiednią strukturę bazy na początku, bo chcecie po prostu zrobić to jak najszybciej, żeby działało jakkolwiek i nie zadbać np. o to, żeby baza była w dłuższej perspektywie bardziej performatywne, bardziej wydajna, żeby łatwo można było ją rozbudowywać o kolejne rzeczy. No to problem ewentualnie pojawi się później. Oczywiście możecie do tego podejść tak ja tylko teraz realizuję pomysł, a jeżeli pomysł się sprawdzi, to będą środki i czas na przebudowę. No ale nie zawsze ma to rację bytu.

‍

I o tych wszystkich aspektach sobie też dzisiaj porozmawiamy, bo one z punktu widzenia właśnie planowania naszej aplikacji są kluczowe. Natomiast to, co chcę podkreślić i to jest pierwszy punkt, który jest krótki, ale bardzo rzeczowy i bardzo ważny. Musicie pamiętać, że planowanie zawsze naszej aplikacji jest kwestią kluczową. Bardzo wiele osób na tym wczesnym etapie deprecjonuje to, że jeżeli nie zadbamy właśnie o te aplikacje na samym początku, to później będziemy mieli potencjalnie dużo więcej problemów, niż gdybyśmy po prostu poświęcili dzień czy dwa na odpowiednie zaplanowanie czy to struktury aplikacji, czy bazy danych, czy stron, czy tego jak ten workflow cały będzie rozłożony pomiędzy częściami czy między modułami tej aplikacji. I musicie o tym zawsze pamiętać i będę to podkreślał. Powtórzę to po raz trzeci. Planowanie jest kwestią kluczową. Jeżeli Wy lub wasi klienci mówią, że dla nich to nie jest kluczowe, że chcą iść jak najszybciej, to powinniście podnieść czerwony alarm, powiedzieć hej, ok, rozumiem, że velocity, że ta prędkość wytwarzania oprogramowania jest dla Ciebie kluczowa, ale zaplanujmy chociaż jakieś podstawowe elementy tej.

‍

Żeby działały one w odpowiedni sposób, ponieważ może się okazać, że jeżeli zrobimy to w zły sposób, zrobimy to szybko, nie zastanawiając się w żaden sposób nad tymi aspektami, to później po prostu będziemy musieli spędzić dwa razy więcej czasu nad przebudową tej aplikacji, albo nawet co gorsza budową jej od nowa. De facto to będzie oznaczało, że musimy dwa razy tyle na tą aplikację po prostu wydać, a de facto skończy się tak, że wydamy pewnie trzy razy więcej. Więc pamiętajcie, proszę, podkreślam planowanie jest zawsze kwestią kluczową, jeżeli chodzi o tworzenie aplikacji, ponieważ aplikacje nie są czymś bardzo prostym. Chyba że tworzymy bardzo prostą aplikację, którą jesteśmy w stanie stworzyć w tydzień, co oczywiście jest bardzo mocną rywalizacją tworzenia aplikacji. Natomiast planowanie jest kluczowe, ponieważ aplikacja to żyjąca organizm. Jeżeli nie zadbamy o serce aplikacji, czyli np. niektóre bazy danych, to później skończy się to po prostu brakiem wydajności, anemią naszej aplikacji. Więc pamiętajcie powtarzam to po raz kolejny, ale to jest naprawdę bardzo ważna kwestia. Planowanie jest kwestią kluczową.

‍

Jeżeli to już mamy za sobą, to będę chciał dzisiaj omówić podział aplikacji, podział tego performance, tej wydajności aplikacji na dwa obszary. Mamy oczywiście obszar aplikacji, w którym w jednym z naszych podcastów rozmawialiśmy. Jest to Frontend, czyli to co widzi użytkownik, to gdzie użytkownik wchodzi w interakcję z naszą aplikacją. Czyli wszystko to, co widzi na ekranie swojego komputera czy swojego telefonu, jak również mamy Backend, czyli to miejsce, gdzie odbywają się rzeczy bez udziału użytkownika, których użytkownik de facto nie widzi, które dzieją się na naszym serwerze. Oczywiście zasoby w początkowych etapach tworzenia aplikacji, kiedy jeszcze nasz pomysł nie jest zrealizowany, mamy też mocno ograniczone i powinniśmy szczególnie dbać o ich performance. Ale powinniśmy też dbać i mieć to w głowie, że jeżeli teraz nie zadbamy performance, to później będziemy po prostu musieli np. dwa razy tyle płacić za utrzymanie serwerów. Dlaczego? Dlatego, że do przetworzenia tych samych rzeczy, jeżeli nasza aplikacja nie będzie miała odpowiednio przygotowanego performance, odpowiednio specyfiki tej wydajności, to po prostu będziemy potrzebowali więcej mocy przerobowych.

‍

Więcej mocy przerobowych równa się wyższe koszty miesięczne utrzymania po prostu tych serwerów. Więc wiemy, że mamy Frontend, wiemy, że mamy Backend i to od frontendu. Dzisiaj zacznę tę rozmowę dookoła tego, jak zadbać właśnie o tą wydajność, żebyśmy mieli pewność, że aplikacja działa odpowiednio. I pierwszy punkt, który chciałbym omówić to strony. Jak wiecie, każda aplikacja składa się z różnych stron. Aplikacja webowa, którą tworzycie ma różne podstrony, z którymi użytkownicy mają do czynienia, np. landing page, na którym jest przedstawiony cennik, parę informacji o Waszej aplikacji czy Waszej firmie. Tak, jest to strona taka typowa wizytówka, do której jeszcze użytkownicy się w żaden sposób nie logują. Po prostu tam pierwszy raz widzą Waszą aplikację np. jest to oczywiście strona rejestracji logowania, jest strona również, która jest dostępna dla użytkowników już po zalogowaniu. I teraz tak. Każda aplikacja powinna być rozbita na kilka stron, bo tak jak mówiłem, powinny one być od siebie odseparowane np. funkcjonalnie. Czyli mamy ten landing page na nim raczej nie chowamy żadnych rzeczy za Paywall czy za tą ścianą do logowania itd.

‍

To jest po prostu nasza wizytówka, która powinna być light weight, mega lekka, żeby się mega szybko odczytywała. Strona logowania też powinna być stroną osobną, do której użytkownik przechodzi, żeby się zalogować. To będzie osobna strona. To już będzie wynikało z samej struktury naszej aplikacji, którą powinniśmy wcześniej sobie zaplanować. No i ta strona, która jest dostępna już po wczytaniu. Jak wiecie, za każdym razem, kiedy użytkownik przechodzi na kolejną stronę, to ta strona się musi załadować. To znaczy, że trwa to jakiś czas. Czym więcej użytkownik będzie musiał nawigować między różnymi stronami, tym więcej czasu będzie de facto będzie de facto tracił. No bo będzie musiał czekać, aż każda pojedyncza strona się zaloguje. Jak? Oczywiście dla każdego użytkownika jest naturalne to, że między stroną logowania i tym co jest dla niego dostępne po zalogowaniu jest jakiś czas, który musi zająć aplikacji na przeładowanie tej treści, udostępnienie mu tej treści i tak dalej. No bo jest weryfikowany czy on to on, że został zalogowany, jest przekierowany w jakieś miejsce dostępne tylko dla zalogowanych użytkowników?

‍

To właśnie tutaj znajdujemy się w miejscu, gdzie już użytkownik liczy na to, że aplikacja będzie działała super. I tutaj zrobimy małą pauzę, bo chciałbym właśnie teraz Wam powiedzieć o tym, że i uświadomić Wam to. Dla tych, którzy nie wiedzą, że aplikacje mogą być strukturyzowane w różny sposób i co to dokładnie znaczy? Mamy podejście, które nazywa się Single Page Apps oraz Multi Page Apps. Single, jak sama nazwa wskazuje, to znaczy, że mamy jedną stronę, dosłownie jedną stronę, na której są wszystkie funkcjonalności. Jeśli teraz zapytacie jak to jest jedna strona, Jeżeli w wielu aplikacjach ja mam boczne menu nawet po zalogowaniu ja sobie na to klikam no i widzę, że tam jest inna treść na tej stronie. Jak to się dzieje? No de facto w takim podejściu chodzi o to, że tak naprawdę wszystkie elementy mamy na jednej stronie. Mamy tutaj powiedzmy takie symulację menu, to nawet nie jest symulacja, to jest po prostu menu, ale po kliknięciu na dany element menu, powinna nam się wyświetlić inna strona my nie przeładowujemy użytkownika na inną stronę, tylko chowamy pewne treści.

‍

Z punktu widzenia użytkownika i pokazujemy mu inne treści. Pamiętajcie, że każda treść w naszej aplikacji jest grupowana w jakiś kontener, w jakąś grupę, więc te wszystkie elementy, które np. dotyczą strony mój profil, lista użytkowników, lista zamówień to. Mamy właśnie kontener, który nazywa się np. lista zamówień, lista użytkowników, mój profil i po prostu ten kontener chowamy przed użytkownikiem, a pokazujemy mu inny. Dzięki temu właśnie nie musimy przeładowywać tej treści, bo ładuje się ona za tym pierwszym logowaniem użytkownika. Wczytujemy te wszystkie elementy, a one są po prostu schowane. A kiedy użytkownik klika na jakiś element menu, to wtedy pokazujemy mu tą grupę. I to jest właśnie podejście Single Page. Dzięki temu mamy wrażenie użytkownik, który korzysta z naszej aplikacji ma wrażenie, że kurcze zobaczy jak wszystko szybko działa. Jak klikam od razu wszystko widzę. Oczywiście nadal te same rzeczy i o tym też sobie porozmawiamy. On widzi na tym Single Page, gdzie ma np. listę użytkowników czy cokolwiek innego. Muszą być wczytane, muszą być załadowane. Ale to już jest troszkę co innego i o tym porozmawiamy sobie później.

‍

Jak sprawić, żeby tutaj też te rzeczy ładowały się w bardzo szybki sposób. Natomiast samo przechodzenie między stronami jest bardzo szybkie i z jednej strony jest to super podejście, bo oczywiście wtedy użytkownicy mówią, zobaczcie tak to działa, działa to po prostu jak burza. Klikam, od razu wszystko widzę. Musicie natomiast pamiętać, że jeżeli załadujecie tam widoki 20 stron, 30 stron, 15 stron czy coś takiego. To zawsze zależy. Oczywiście tez co się znajduje w tych kontenerach. No bo kontener kontenerowy nierówny, strona stronie nierówna, to musicie pamiętać, że to pierwsze ładowanie będzie dużo dłuższe, bo to znaczy, że de facto przy tym pierwszym logowaniu, przy pierwszym ładowaniu strony my te wszystkie informacje musimy z tego serwera pobrać. Na temat struktury strony oraz tego, co się na niej de facto znajduje. Oczywiście, dopóki element nie jest widoczny, to my nie pobieramy danych, więc de facto nie obciążamy użytkownika ani jego łącza tym, że on też musi wszystkie dane pobrać, które by tam widział. No ale strukturę samej strony, czyli ten cały HTML, CSS itd.

‍

Wtedy już to jak najbardziej jest pobierane. Oczywiście to jest benefit, ale musicie pamiętać też, że jeżeli strona będzie za ciężka i np. doprowadzimy do sytuacji, w którym nasza strona ładuje się powyżej 5 8 sekund, to użytkownik powie kurczę, no dobra, trochę trwa to długo, trochę trwa to długo. Oczywiście jeżeli to się dzieje raz, a użytkownicy spędzają cały dzień w naszej aplikacji, no to to jest zawsze kwestia wyważenia Multi Page. Natomiast podejście polega na tym, że każdy z tych widoków, o których powiedziałem, czyli lista użytkowników, lista zamówień, mój profil tak, to za każdym kliknięciem mielibyśmy przekierowanie użytkownika do innej strony. Czyli użytkownik by po prostu przychodził i czekał aż ta strona między sobą się załaduje. I tutaj mamy to, że oczywiście ta strona będzie się ładowała szybciej, bo ona będzie lekka. Każda z tych pojedynczych stron, ale częściej będzie występowało ładowanie przeładowywania użytkownika między tymi wszystkimi stronami. I tutaj sami de facto nie mam. W mojej opinii nie ma takiego czegoś, że jedno podejście jest lepsze od drugiego.

‍

Bo musicie pamiętać też, że takie rozczłonkowanie stron pomaga nam np. w utrzymaniu tego, aby użytkownicy mieli na pewno dostęp tylko do tego, czego dostęp mieć powinni. Pozwala nam na separację pewnych danych od siebie. Pozwala nam na separację funkcjonalności, bo na przykład uznajmy, że nasza aplikacja ma funkcjonalności, które są dostępne na różnych poziomach abonamentowych. Wtedy jest łatwiej. Może czasami mówię, może i czasami, bo to też nie jest reguła utrzymać dostęp do tych funkcjonalności z dala użytkowników, którzy są na niższych planach abonamentowych. Natomiast tak jak mówię, nie ma tutaj reguły i nie ma jednej słusznej odpowiedzi, które podejście jest lepsze. Więc wiecie już czym się różni Single Page oraz Multi. Wiecie dokładnie jak ono funkcjonuje i czym się różni. Musicie również pamiętać, że naszym nadrzędnym celem jest to, aby strony były lekkie i w przypadku singli jest to ciężkie do utrzymania. No bo po prostu ładujemy wiele stron w jedną i posługujemy się np. parametrami w URL u, aby wyświetlać odpowiednie grupy, odpowiednio chować kontenery itd. Więc musimy zadbać o to, że

‍

Jeżeli ściągamy tę strukturę danych, to żeby wraz ze strukturą danych nie ściągały się dane czy listy elementów, które są niewidoczne. No bo to by znaczyło, że wtedy strona z pierwszym logowaniem będzie ściągała się bardzo powoli, czyli de facto ładujemy oczywiście strukturę całej strony. Mamy je trochę więcej, ale występuje to tylko raz. To jest jakiś benefit. Coś za coś zawsze jest. Natomiast musimy zadbać o to, żeby wraz z tymi elementami, które są niewidoczne, nie ściągały się dane, żeby dane pobierały się tylko wtedy, kiedy elementy są widoczne. I o tym musicie pamiętać. I to jest właśnie bardzo ważny aspekt, który musicie podnieść na planowaniu swojej aplikacji. Jak de facto będzie wyglądała struktura tej aplikacji i struktura stron, żeby użytkownik poruszał się po tej aplikacji w sposób szybki, wydajny i nie odczuwał tego, że co chwilę musi się przeładowywać między różnymi stronami, bo to jest de facto wkurzające. A z drugiej strony, żeby to pierwsze ładowanie też nie było za długie, bo musicie sobie zadać pytanie również, jak często użytkownicy odwiedzają naszą stronę, czy raczej korzystają z niej także po prostu do niej wchodzą, odpalają ją raz i pracują z nią cały dzień czy co chwilę wchodzą, wychodzą, wchodzą, wychodzą.

‍

No bo to ma wpływ na to, jaki odbiór będą mieli z tej aplikacji i z tego jak ona się ładuje. Więc to tyle jeżeli chodzi o podejście Single Page kontra Multi Page i planowanie tego, żeby strony były lekkie, szybko się wczytywać i żeby po prostu w żaden sposób użytkowników najzwyczajniej w świecie mówiąc nie wkurzało. Dobrze. Co zrobić natomiast, żeby strony były lekkie, tak jak sam HTML? CSS są raczej elementami lekkimi. O ile nie przesadzimy, bo tutaj też możemy sobie przesadzić, to na naszych stronach bardzo często dodajemy różne grafiki, obrazy, które coś tam ważą i to one bardzo często powodują problemy z wydajnością. Musicie pamiętać, że jeżeli umożliwia użytkownikom dodawanie różnych rekordów na przykład do Waszej aplikacji, które się wyświetlają jako jakiś listing lub cokolwiek innego i użytkownicy mogą tam dodawać np. pliki lub mogą dodawać tam obrazy, to musicie lub powinniście zadbać o to, aby te obrazy, które użytkownicy dodają. Pamiętajcie, użytkownicy nie są techniczni. Użytkownicy bardzo często będą wrzucali obrazy, które ważą 10 MB, 20 MB albo o zgrozo jeszcze więcej.

‍

Będą wrzucali tam mnóstwo różnych rzeczy. To Wy musicie jako developerzy tej aplikacji zadbać o to, aby te elementy zanim pójdą na serwer, kto się będzie ściągał ze swojej perspektywy, aby one były odpowiednio lekki. Natomiast jako developerzy to jest jeden aspekt, o którym sobie jeszcze porozmawiamy troszkę później. My natomiast jako developerzy, jeżeli tworzycie np. jakiś landing page lub na stronie powinny być jakieś grafiki, jakieś pliki czy cokolwiek innego, powinniście również zadbać o to, aby nie były one ciężkie. Musicie pamiętać, że jeżeli na Waszej stronie pojawi się grafika, która waży kilka MB i to będzie jedna grafika, która waży po prostu 5 MB, 10 MB czy cokolwiek innego, to bardzo mocno spowolni to ładowanie Waszych stron, bo po prostu ta strona będzie ciężka. I teraz jeszcze pomnóż to przez ilość użytkowników i to. Jeżeli serwer serwuje tą stronę do użytkowników to on nagle musi dużo więcej tych danych wysłać, a Wasi użytkownicy dużo więcej tych danych pobrać. Więc musicie pamiętać o tym, aby po pierwsze obrazy, które wrzucacie były najlepiej w formacie PNG albo albowiem są to obrazy.

‍

Są to formaty grafik, które są najlżejsze i najbardziej rekomendowane jeżeli chodzi o tworzenie właśnie webaplikacji czy w ogóle stron www, ponieważ są one lekkie, a zapewniają bardzo wysoką rozdzielczość. Z drugiej strony oczywiście jeszcze taki format to obraz obrazów czy ikon jakie sobie, który jest czystym elementem HTML i pozwala nam na wrzucanie. To jest tak zwana grafika wektorowa, która pozwala nam skalować ją do różnych rozmiarów, ale w tle jest przeliczana właśnie skala tego, w jakiej skali jest ten element wyświetlany i zawsze ona zachowuje po prostu swój odpowiedni, swoją odpowiednią jakość. Jest ona po prostu zawsze bardzo wyraźna i odpowiednio wygląd. Więc to jest kolejny aspekt, który musicie zadbać. Po pierwsze o to, aby obrazy czy pliki, które budujecie na strony, które pobierają użytkownicy były lekkie i żeby nie obciążały właśnie tego pierwszego ładowania stron. Więc to jest kolejny aspekt tego, jak zadbać o to, aby te strony były lighting lite, żeby one były jak najlżejsze i żeby można było je bardzo szybko wczytać czy pobrać po prostu z serwera. Musicie pamiętać, że za każdym razem, kiedy wchodzicie na stronę, to pobieracie jej zawartość z serwera.

‍

Robicie po prostu ściąganie jej na własne urządzenie. I teraz właśnie przejdę do tego, o czym troszkę odrobinę powiedziałem na początku, czyli przeszukiwanie i wyświetlanie informacji na Frontend. I porozmawiamy sobie tutaj właśnie o tym jak nie tworzyć wyszukiwań, wyświetlaniu informacji itd. Filtrowaniu czy paginacji. Jak właśnie zadbać o to, żeby dane, które pobieramy. I nie chodzi mi tylko o to. Jak wygląda strona, ale też dane, które na swojej stronie wyświetlamy. Czy to właśnie listy elementów, czy już jakiś detal jakiegoś pojedynczego elementu, czy coś w ten deseń? Jak zadbać o to, żeby te dane również się szybko wczytywać i na tym Frontend? Zacznijmy może od właśnie tego, o czym już troszkę powiedziałem, czyli o tym, co wrzucają nasi użytkownicy. Bardzo często w aplikacjach czy na różnych stronach mamy do czynienia z listami. Czyli mamy listę jakichś elementów, czy to właśnie są np. lista ofert pracy, czy lista użytkowników, czy jakakolwiek inna lista. To my tę listę ściągamy. I tutaj znowu do listy mamy różne podejścia. Natomiast jeszcze zanim przejdziemy do tego, jakie mamy podejścia do listy, porozmawiajmy o tym, co użytkownicy wrzucają na naszą platformę.

‍

Musicie pamiętać, że żeby umożliwiać użytkownikom tworzenie treści w Waszej platformie, to musicie też mieć nad tym jakąś pieczę. Użytkownicy nie zastanawiają się nad tym, co wrzucają, jak wrzucają i jaki będzie miało to efekt na działanie Waszej strony. Jeżeli pozwolicie użytkownikom wrzucać tekst i nie ogarniecie tego w żaden sposób, to może zdarzyć się użytkownik, który wrzuci tam tekst, który ma milion znaków. Co to de facto znaczy, że ma milion znaków? To znaczy, że będzie ważył całkiem sporo i użytkownik, który będzie chciał ściągnąć, taką informację może mieć mały problem, bo będzie ściągał tekst, który ma milion znaków, a do tego grafikę, która waży 20 MB. I co się w tym momencie stanie? Stanie się to, że będzie po prostu bardzo długo czekał na ściągnięcie takiej informacji. Więc my jako deweloperzy powinniście zadbać o to, że jeżeli umożliwiać użytkownikom swobodne tworzenie treści, a jest to aplikacja ogólnodostępna, do której może zalogować się każdy nieprzeszkolony użytkownik, nie uświadomcie go, co on powinien robić. To Wy musicie zadbać o to, aby ograniczyć to, co on de facto może wrzucać.

‍

Czyli na przykład jeżeli dajecie możliwość wrzucania obrazków czy jakiś plików, to na przykład ograniczyć ich maksymalny rozmiar, albo jeżeli nie ograniczać tego maksymalnego rozmiaru, to go kompresować. Czyli po wrzuceniu do Was na serwer jako kompresuje czy obniżać jego jakość? Coś takiego jak robi Facebook? Na pewno zauważyliście, że jeżeli korzystacie z Messengera i macie super grafikę zrobioną najnowszym Samsungiem czy najnowszym iPhonem, gdzie jakość aparatu jest super i na waszym urządzeniu to zdjęcie waży 50 MB, to po wrzuceniu go na Messengerze ono mocno traci na jakości czy na Facebooka? Dlatego, że właśnie Facebook po drodze to zdjęcie mocno kompresuje po to, żebyście właśnie nie zabrali serwerów. Musicie pamiętać również o tym, że za miejsce na serwerach, czyli na to, ile możecie tych zdjęć wrzucić, również płacicie. Więc jeżeli będziecie pozwalali każdemu użytkownikowi wrzucać tam nieskończenie wiele danych albo nieskończenie wielkie pliki, to okaże się, że nagle będziecie ponosili dużo wyższe koszty utrzymania tej przestrzeni dyskowej, na której te dane będą dodawane. Więc to tyle. Słowem tego, jak powinniśmy dbać o to, co nasi użytkownicy tworzą.

‍

Natomiast porozmawiajmy właśnie teraz o listingu. Po pierwsze są złożone z tego, że my wyszukujemy w naszej bazie danych jakieś informacje, żeby te dane ładowały się szybko. No to oczywiście nasze bazy danych powinny być odpowiednie dla indeksowane. To już jest temat bardziej zaawansowany, bardziej Frontend i tutaj nie będę wchodził tak bardzo mocno w detale czym jest indeksacja, co to jest casting itd. Bo nie dzisiaj nie jest to temat na dzisiaj. Jest to już temat bardzo zaawansowany. Natomiast musicie pamiętać, że czym bardziej macie skomplikowane reguły wyszukiwania tych danych, czym więcej reguł przeszukiwania tych danych, tym dłużej takie wyszukiwanie będzie po prostu trwało. Więc powinniście tego unikać. Powinniście już na etapie samego serwera ograniczać dostępy do pewnych danych czy na przykład wyświetlać użytkownikom wstępnie przefiltrowane dane, a jeżeli chcą bardziej filtrowane dane w sposób bardziej sprecyzowany czy bardziej ustrukturyzowane, czy bardziej kompleksowy, to. I niższy. Nie jest zbyt ładne polskie słowo, ale na samym początku ładuje Ci dane jakoś wstępnie filtrowane, żeby ta lista zaczytała się bardzo szybko, tak żeby użytkownik miał już wstępne dane.

‍

A kiedy użytkownik będzie chciał sobie aby filtrować to dajecie mu tą możliwość. To znaczy, że on sobie zaznacza filtry, klika, szuka i wtedy pokazujecie loader i użytkownik jest świadomy, że takie wyszukanie może zająć trochę więcej czasu, ale przez to by automatycznie z samej góry z samego początku nie obciążać tej aplikacji, czyli unikać właśnie tych kompleksowych, tych bardzo złożonych wyszukiwań albo skurczów serca, skurczów serca. Czyli mamy zagnieżdżone wyszukiwanie elementów, bo to też bardzo mocno obciąża performance wyszukiwania tych list. Mamy również możliwość filtrowania tych list i filtrowanie. Oczywiście możemy robić po stronie serwera, co jest dużo szybsze, ale możemy również robić to na urządzeniu użytkownika. Każde z tych podejść ma swoje plusy i minusy. Nie będę tej dokładnie omawiał. Natomiast musicie mieć zawsze w świadomości to, że dane możecie filtrować właśnie po stronie urządzenia i wtedy to urządzenie użytkownika będzie obciążone albo po stronie serwera. Więc tutaj też musicie do tego w odpowiednio wyważony sposób podchodzić, żeby to rozłożyć w odpowiedni sposób. Żeby z jednej strony jeżeli macie bardzo wielu użytkowników nie pchać wszystkiego na serwer, bo serwery mogą być przeciążone, ale spróbować pewne rzeczy zostawić do zrobienia urządzeniom na do zrobienia na urządzeniu użytkownika.

‍

Przepraszam, troszkę mi się tutaj poplątało więc, dzięki czemu po prostu odciąża swoje serwery i zostawiacie coś do zrobienia użytkownikowi czy jego urządzeń. Następnym elementem, który może bardzo mocno przyspieszyć ładowanie danych jest paginacja, czyli de facto nie ładuje Ci od razu wszystkich elementów jakie są znalezione w Waszej bazie danych. Powiedzmy, że jest ich 1000 tylko je paginujecie, czyli stronicujecie wyświetlacie jakąś część tych informacji np. 10 pierwszych rekordów na serwer i w pamięci serwery ma zapisane kolejne 10, dzięki czemu użytkownik widzi, że ma 10 rekordów, widzi, że ma kolejne strony, które może odwiedzić i w momencie kiedy klika na drugą stronę tak na stronę kolejną ładuje mu się kolejne 10 rekordów. I kolejne 10 wczytuje sobie serwer, żeby mieć w pamięci, dzięki czemu de facto użytkownik ma wrażenie Hej, zobaczcie super jak to się szybko ładuje. Od razu widzę 10, kolejne 10 klikam trzecią stronę, widzę od razu kolejne 10. De facto jest to zrobione tak, że my wyświetlamy 10 rekordów użytkownikowi i trzymamy w pamięci kolejnych 10 rekordów.

‍

Jak on klika wyświetla to, ale serwer sobie od razu pracuje, czyli pobiera kolejne 10 rekordów. Dzięki temu nie ściągamy od razu informacji o tysiącu rekordów, które mamy w bazie tylko z dwudziestu, co jest dużo szybsze i dużo szybciej da nam odpowiedź z tego serwera. Tak więc w ten sposób możemy zadbać o to, aby dane wszystkie nie tylko struktura aplikacji, ale też dane, które będziemy chcieli wyświetlać użytkownikowi, były ściągane w bardzo szybki i wydajny sposób. Na samym końcu o czym chciałem porozmawiać jeżeli chodzi o temat Frontendu i trzymania odpowiedniej wydajności na Frontend jest jasna komunikacja z użytkownikiem i to jest temat, który chciałbym zaznaczyć, że również jest bardzo istotny, a w wielu aplikacjach z niewiadomego powodu jest bardzo mocno pomijany czy traktowany po macoszemu. Nie wiem czy Was też to spotyka, ale ja bardzo wielu aplikacjach różnych producentów widzę to, że jeżeli kliknąłem na coś. To czekam. Czekam, czekam. Nic się za bardzo nie dzieje, nie jest za bardzo poinformowany, albo ekran się po prostu wpisuje lub zaczyna być za takim szarym, troszkę takim szarym blurze.

‍

Czy jest pokazane ok. Niby coś się dzieje, ale ja nie wiem czy aplikacja się zawiesiła czy coś się dzieje i dopiero po chwili coś ten ekran znika i są pokazane kolejne dane. Według mnie jest to średni UX i naszym zadaniem jako developerów jest zawsze informować użytkownika, że coś się zadziało albo przy logowaniu kilka przycisk Zaloguj. No i ok, widzę, że przeglądarce tam na kółeczko, bo ja zwracam akurat uwagę na takie rzeczy, ze coś tam się dzieje, zaczęło się coś ładować, a na ekranie nie ma nic. Kliknąłem mogę kliknąć drugi trzeci raz no i coś trwa długo. Ja nie wiem czy znowu ja nie kliknąłem, czy może coś się nie zadziało. Bardzo często też buttony nie mają reakcji na kliknięcie, tylko po prostu są cały czas takie samo wyglądają. Więc ja nie wiem czy kliknąłem czy nie kliknęłam. Nie jestem poinformowany o tym, co de facto w naszej aplikacji się dzieje. I tutaj chciałbym zaznaczyć, że w mojej opinii jest to bardzo ważne, żeby z użytkownikami rozmawiać poprzez ten interfejs Frontend, żeby ich dokładnie informować o tym co się dzieje.

‍

Musicie pamiętać, że frustracja użytkowników z tego, że według nich coś nie działa albo działa wolno, przeważnie wynikają z tego, że nie zostali poinformowani o tym, że coś może działać wolno. Użytkownicy przeważnie nie mają problemu z tym, że na coś muszą poczekać. Jeżeli im powiemy i jasno za komunikujemy. I o co dokładnie chodzi? Tak jak już dałem na przykład ten przykład ekranu logowania, wpisałem email, wpisałem hasło, kliknąłem zaloguj przycisk nie zareagował w żaden sposób, nie dał żadnej animacji czy żadnego wysadzenia takiego windykatora, że został tknięty. To po pierwsze, a po drugie po kliknięciu na niego na ekranie nic się nie dzieje, tylko trzeba czekać. Według mnie dużo lepszym podejściem byłoby to, że jeżeli kliknąłem to dostałem. Wiecie, taką odpowiedź organoleptyczną, czyli pod tytułem przycisk zaświecił. Dał taki obraz indicator, że kliknąłem widzę, że kliknąłem. A po drugie na przykład na przycisku pojawił się loader, czyli ja wiem, że coś się ładuje i trzeba poczekać. Oczywiście znowu jeżeli będzie to trwało niewiadomo ile, to użytkownik zacznie się frustrować, ale chociaż w tym momencie został poinformowany, że kliknął, że coś się ładuje i dopiero coś się zadzieje.

‍

I to jest prawidłowe podejście. Kolejną rzeczą jest np. eksportowanie czegoś do PDF, do plików CSV itd. Bardzo często, jeżeli użytkownicy chcą np. coś eksportować, nie są o tym poinformowani, że coś będzie trwało długo, kliknęli eksportuj pdf. Mija 5-10 sekund i dopiero plik został ściągnięty, ale na ekranie de facto nic nie widać. I to się dzieje w bardzo wielu aplikacjach, które obserwuję czy z których korzystam. Według mnie dużo lepszym podejściem byłoby znowu włączenie jakiegoś loader a czy jakiejś planszy na ekranie użytkownika z napisem generujemy PDF. To może zająć chwilę. Poczekaj, nie odświeżaj ekranu, coś, co często użytkownicy robią. Jeżeli coś się generuje według nich za długo i nie zostali o tym poinformowani, że nie powinny odświeżać ekranu, bo przerwie to proces, który będą musieli robić od nowa. Powinniśmy w jasny sposób zawsze czy jakimiś elementami, czy mapami, czy czymś informować użytkowników w jasny sposób, że coś się dzieje i powinni poczekać. W ten sposób po prostu zbijamy ich frustrację, zbijamy ilość pakietów, które będą do nas wysyłać czy mailowych zapytań, że hej, coś nie działa.

‍

Hej, czekam strasznie długo, żeby ktoś się załadował i nie wiem dlaczego. Musicie pamiętać, że bardzo często wynika to z frustracji i braku odpowiedniego informowania użytkowników, że coś się dzieje, coś się ładuje albo że muszą poczekać. Więc to są te właśnie najważniejsze elementy tego, jak nasz frontend powinien być ustrukturyzowane, aby w jasny sposób informował użytkowników o tym, co się dzieje w naszej platformie oraz żeby działał w sposób wydajny i super. I myślę, że omówiliśmy sobie Frontend całkiem kompleksowo jak możemy o niego dbać i jego wydajność. Więc teraz chciałbym porozmawiać o tym, jak zadbać o ten performance Backendu. I tutaj wrócę do czegoś, o czym mówiłem też już na etapie planowania, czyli struktura bazy danych. Mianowicie jest to jeden z najważniejszych tematów jeżeli chodzi o aplikacje, a zauważyłem, że w bardzo wielu agencjach no code czy w ogóle w no code podejściu bardzo często pomijany. I z czego to wynika? Bazy danych bardzo często są przedstawione dla codziennych użytkowników czy deweloperów czy czegokolwiek kogokolwiek innego w sposób podobny do Excela. I w automatyczny sposób nasz mózg oczywiście włącza ten małpi mózg.

‍

Gadzi mózg, który zaczyna kojarzyć pewne informacje, odnosić się do nich, do pewnych skojarzeń itd. Moja subiektywna opinia. No i ze względu to, że mamy takie skojarzenie może trochę z Excelem, że są tabelki, gdzie tworzymy sobie te bazy danych, że jest to takie proste. Sposób można tworzyć relację między tymi danymi, że tak łatwo się do tych danych dostać. No to ludzie zaczynają to trochę deprecjonować i odpychać. Okay, dobra, to ja mam strukturę bazy danych. Mam tutaj wszystkie dane, informacje, które chciałem tutaj zawrzeć. No więc super, mamy już to gotowe, Wyświetla się na Frontendzie, działa, to super. I oczywiście w momencie kiedy jesteś sam i tworzysz tą aplikację sam i testujesz ją Ty + 5 Twoich kolegów czy koleżanek to jak? Ej aplikacji nie testował to ona będzie działać super. Będzie działać super dlatego, że tych danych po pierwsze jest mało. Wasza piątka czy dziesiątka nie jest w stanie wygenerować takiej ilości danych, jaką wygeneruje pół miliona użytkowników Albo 10 000 użytkowników, albo nawet stu użytkowników, którzy działają w aplikacji już pół roku, bo to jest pół roku pracy użytkowników, więc ciężko to nadrobić, jeżeli te dane mają być jakiekolwiek sensowne czy replikować, czy naśladować te realne dane, to Wam się wydaje, że ta aplikacja działa super, że będzie działać super.

‍

Natomiast to nie jest prawda. W dłuższej perspektywie zobaczycie, że zaczniecie mieć bardzo duży problem. Jeżeli nie zadbajcie o poprawność tej bazy danych na samym początku to niestety będziecie mieć bardzo duży problem. I wielu skarżących się użytkowników, którzy po prostu przestaną korzystać z Waszej aplikacji. Jak zadbać o tę strukturę bazy danych? Oczywiście zaznaczam, że może nas spotkać ta pułapka, że na początku jesteśmy sami, że jest nas mało i że zaczynamy korzystać, więc tam nic złego się nie dzieje, bo po prostu infrastruktura da sobie z tym radę i nie będzie zbytnio tym obciążona. Może na początku za bardzo nikt się tym nie przejmuje. Natomiast to jest jedna z najważniejszych rzeczy. Jaki ma to wpływ? Po pierwsze, jeżeli struktura danych będzie zła, a na przykład Bubble, działa ona w taki sposób, że jeżeli mamy jakiś rekord w bazie danych, który ma 20-30 pól, to niestety jeżeli wyświetlamy go na Frontend, to my pobieramy te wszystkie pola. I co to de facto znaczy? Jeżeli macie listę użytkowników, a użytkownik w bazie danych przechowuje informacje o imieniu, nazwisku, dacie urodzenia, dacie rejestracji, adresie mailowym, haśle o tym czy potwierdził Kukiz, kiedy to zrobił i o swoim adresie zamieszkania, o tym czy ma dzieci, o tym czy ma żonę, czy ma psa, jakiś opis swojego profilu, zdjęcie profilowe, jeszcze jakieś inne informacje?

‍

Tak, linki do social mediów to tych danych się robi dużo. I oczywiście na Frontend, gdzie widzicie. Okej, ale ja na liście użytkowników wyświetlam tylko imię, nazwisko i jego adres mailowy. To pomyślicie, że wyciągacie tylko te trzy dane. Natomiast nie jest to prawda. W przypadku Bubble działa to w ten sposób, że jeżeli pobieracie listę użytkowników, to nie wyciągacie z bazy danych tylko tych pól, które widzicie, tylko ściągacie wszystkie pola. To znaczy, że jeżeli użytkownik ma 30 pól w sobie z tymi informacjami jak imię, nazwisko etc. I wyświetlacie 20 użytkowników to musicie pomnożyć 20 razy 30, nie 20 razy 3. Czyli nie 20 razy 3 pola które wyświetlam czyli ta ilość danych tylko 20 razy 30. To już daje zupełnie inną ilość danych, które de facto pobieramy na Frontend, które pobiera nasz użytkownik, który korzysta z naszej aplikacji. I musicie o tym pamiętać. Inaczej to wygląda w Xano, kiedy my tworząc jakieś endpoint które możemy pytać o listę z bazy danych to już mamy kontrolę nad tym i możemy powiedzieć OK, jeżeli to jest zapytanie, które ma taki parametr to chcę żebyś zwracał tylko te 3 pola i wtedy zwracamy tą małą ilość danych.

‍

Natomiast musicie mieć to z tyłu głowy, że musicie zawsze brać pod uwagę, że Wasza struktura bazy danych w przypadku Bubble będzie miała gigantyczne znaczenie ile ma pól i jakiego rodzaju to są pola, czy tam są pliki, czy tam są obrazy, czy jest lista plików itd. Czy nie jest to Xano gdzie mam kontrolę nad tym co de facto mój użytkownik dostanie w odpowiedzi, że on np. dostanie tylko te 3 pola a nie 30 pól. No i to jest jeden aspekt, który ma bardzo znaczący wpływ na to, jak wasza struktura bazy danych będzie wyglądała, bo ona też tak jak już powiedziałem przypadku Bubble powinna wyglądać trochę inaczej i w przypadku Xano powinna wyglądać trochę inaczej. To oczywiście czego nie zalecam to budowanie np. list plików w polach dotyczących konkretnego rekordu. Załóżmy, że mamy użytkownika i ten użytkownik wrzuca dokumenty na naszą platformę. To bardzo wiele osób ma takie podejście, że tworzy dodatkowe pole użytkowników data type typu użytkownik, gdzie daje pole Lista plików. I wszystkie pliki, które wrzuca użytkownik wrzuca tam i on sobie tam wrzucił 10 plików po 10 megabajtów, czyli łącznie 100 MB.

‍

Co to znaczy? To znaczy, że jeżeli ja ściągam jeden rekord z użytkownikiem, to ja ściągam automatycznie 100 MB danych, bo jeszcze mam te wszystkie informacje, które tam są, wszystkie informacje. I to jest bardzo złe podejście, które ja bardzo odradzam, czyli trzymanie list bezpośrednio w rekordach. Dużo lepiej jest zbudować osobny data type, który będzie miał relację, czyli informacje do jakiego użytkownika należy informacje o pliku i będzie pojedynczym rekordem, bo dzięki temu mamy kontrolę nad tym ile plików pobieramy, czy je w ogóle pobieramy i pobieramy je np. dopiero wtedy, kiedy wejdziemy w detale konkretnego użytkownika i ściągamy tylko te pliki konkretnego użytkownika, a nie. Znowu jeżeli wyświetlamy listę 20 użytkowników to ściągamy 20 razy 30 plus jeszcze razy ilość plików, które mają Ci użytkownicy. Więc w ogóle jakąś chorą liczbę danych. Więc to jest bardzo ważny aspekt naszej struktury bazy danych. I oczywiście nie będę się rozwodził nad strukturą bazy danych, bo byśmy mogli zrobić osobne w ogóle szkolenie, osobny webinar. To są też różne bazy danych różnych notacjach. Jeszcze inaczej to wygląda w różnych platformach no code, bo one pod spodem korzystają z różnych struktur, baz danych, z różnych baz danych itd.

‍

Więc tutaj moglibyśmy zrobić o tym całkowicie osobne szkolenie czy osobny referat. Natomiast chciałem wrócić na takie punkty ogólne, które mają bardzo wysokie znaczenie czy bardzo duże znaczenie, w aspekcie tego, jak powinniśmy dbać i że powinniśmy właśnie zadbać zawsze na samym początku o tą strukturę bazy danych, bo jeżeli o to nie zadbamy, to będziemy mieli problemy prędzej czy później. Problemy, które będą bardzo ciężkie do odkręcenia, bo struktura bazy danych jest również uwzględniana na Frontend i jeżeli zmienimy strukturę bazy danych, będziemy również musieli robić zmiany właśnie w strukturze naszej aplikacji, co będzie bardzo uciążliwe już na dalszym etapie, gdzie będziemy już mieli tą aplikację całkiem rozwiniętą. Kolejnym aspektem o którym chciałbym pomówić to jest tzw. complex workflow, czyli skomplikowane, ciężkie heavy workload. Bardzo często spotykam się z tym, że te heavy workload są robione na Frontend i po pierwsze jest to złe z tego względu, że mogą one zajmować dużo czasu, a po drugie jest to złe, że wtedy to urządzenie użytkownika musi wykonać te wszystkie obliczenia, a nie wiemy de facto jakie urządzenie ma nasz użytkownik.

‍

Czy on ma super ekstra drogiego laptopa, czy on ma jakiegoś starego androida albo starego iPhona z 2010 roku. No może 10 tego to przesadziłem ale na przykład z 2015 i to urządzenie już nie będzie tak wydajne, nie będzie sobie tak dobrze radziło jak nasz najnowszy iPhon czy nasz najnowszy Samsung, no bo nie będzie miało takiej mocy obliczeniowej. Bardzo często o tym zapominamy, patrzymy przez swój pryzmat. Okej, ja testowałem to na swoim nowym iPhonie, testowałem to na swoim nowym Samsungu i działało super. U Ciebie tak, ale Twój użytkownik może mieć dużo gorsze urządzenie. Dużo starsze urządzenie, które już tak super sobie z tym radzić nie będzie. Więc raczej te powtarzające się workflow, te ciężkie workflow powinniśmy raczej wrzucać na Backend i to Backend nimi obciążać. Czyli przekazywać te informacje na Backend, a na frontend wyświetlać po prostu rezultat. I to tak powinniśmy te workflow restrukturyzować. Bardzo ważne jest właśnie to, abyśmy ważyli to, kiedy to urządzenie użytkownika powinno być odpowiedzialne za wykonywanie jakiejś pracy, a kiedy serwery? Bo znowu tutaj musimy wyważyć to, że nie chcemy wszystkiego pchać na serwer, bo będzie to bez sensu dociążenie serwera i zwiększanie kosztów jego utrzymania.

‍

No ale też nie wszystko wypychamy na urządzenie użytkownika, więc bardzo ważne jest właśnie wyważenie tego między jednym a drugim. Oczywiście są też takie workflow, które wymagają bardzo długiego czasu wykonania. Załóżmy sobie, że mamy bardzo dużą bazę danych i nasz użytkownik chce wyeksportować do CSV dane z tej bazy danych. No i to zajmie powiedzmy 15 minut. Czy powinniśmy to robić na Frontend? Zdecydowanie nie. Użytkownicy nie zawsze zrozumieją, że to będzie trwało 15 minut. Nie zawsze będą mogli trzymać laptopa i stronę otwartą przez 15 minut, bo w momencie kiedy opuszczą stronę, zamkną ją. To przerwą też workflow. Musicie pamiętać o tym, że workflow na Frontend są wykonywane tak długo jak na tym Frontend, gdzie jest zalogowany użytkownik i ma otwartą tą kartę. W momencie w którym on tą kartę zamyka. De facto zamyka też workflow i zostaną one wszystkie przerwane. Więc jeżeli np. mamy właśnie taki workflow, który może zająć paręnaście minut czy parę minut, powinniśmy wyświetlić użytkownikowi informację Hej Słuchaj, przyjęliśmy realizację tego, wiemy co chcesz zrobić, ale potrwa to paręnaście minut czy parę minut.

‍

Wyślemy Ci notyfikacje czy wyślemy Ci maila. Kiedy skończymy, wyślemy Ci link do pliku, który chcesz pobrać, żebyś sobie go popraw w wygodnym dla Ciebie czasie. Kiedy skończymy przetwarzać twoje żądanie, bo może ono zająć parę minut. Użytkownik jest poinformowany, rozumie co się dzieje, rozumie dlaczego zajmie to więcej czasu, więc dla niego to jest ok, Ale nie trzymamy go na siłę przy tej otwartej karcie, bo na pewno większość z nich zamknie tą kartę. Przerzucamy odpowiedzialność na serwer. Serwer nie musi mieć użytkownika aktywnego, żeby wykonywał swoją pracę. W momencie kiedy swoją pracę wykona to wyślemy do użytkownika informację. Więc tak, powinniśmy strukturyzować właśnie ten workflow jeżeli chodzi o Backend i dbanie o to co powinno się tam w naszym Backend po prostu dziać. Więc to jest temat, który dotyczy workflow. Na koniec, kiedy już omówiliśmy sobie Frontend oraz Backend, chciałbym powiedzieć trochę o tym. OK, a jak sprawdzać, jak podejść w ogóle do tego do debugowania? Czy do sprawdzania, gdzie de facto mamy problem? No bo okej, tworzymy też te aplikacje, Nie zawsze mamy czas się dokładnie zastanowić, nie zawsze też to, co wymyślimy, czy to, co zaplanujemy, będzie miało rację bytu w praktyce, bo nie jesteśmy w stanie przewidzieć wszystkiego, nie jesteśmy w stanie wszystkiego zaplanować i to też musicie o tym pamiętać.

‍

Na tym planowaniu też nie ma sensu wiecie, każdego przecinka, każdej kropki planować, bo nie jesteście w stanie po prostu tego robić. Więc jak podejść do tego, kiedy zrobiliśmy coś według planu, Ale to nie działa. Po prostu nie działa. Co zrobić, Jeżeli będzie to dotyczyło frontendu, to oczywiście mamy Dev Tools w każdej przeglądarce, czyli takie narzędzie, które po pierwsze pokaże nam, co się dzieje przy ładowaniu naszej strony, cały workflow, czyli co się ładuje, ile czasu to zabiera, czy ten czas był dlatego długi, bo na przykład na coś nasz workflow czekał, czy tak długo trwała odpowiedź z serwera? Jeżeli to była bardzo długa odpowiedź z serwera, no to będziemy wiedzieli, że problem mamy po stronie serwera i to gdzieś tam. Musimy szukać tej przyczyny. Więc tak możemy sobie debugować Frontend. Patrzeć po prostu w tych Dev Tools co de facto było ściągane, ile czasu to trwało i gdzie de facto mieliśmy te najdłuższe, czasy reakcji czy najdłuższe czasy odpowiedzi. I tam też właśnie zobaczymy, że jeżeli problem jest na Backend, to właśnie zobaczymy to tam, bo na przykład będziemy wiedzieć, że response from Server zajęło 10 sekund około 10 sekund, to bardzo długo na wczytanie czegoś całkiem prostego, więc dlaczego to zajęło tyle czasu?

‍

Wtedy idziemy na swój serwer, więc jak możemy to debugować na serwerze. Na serwerze oczywiście musimy wykonywać te workflow i patrzeć w logi serwera i patrzeć w to ile każdy workflow czy każdy step zajął czasu i de facto na czym ten czas został spędzany. Tak, oczywiście nie jestem w stanie wejść już w detale tego, gdzie będziemy szukać takich odpowiedzi, bo to musielibyśmy omawiać na konkretnych przypadkach czy konkretnych zapytaniach. Natomiast chciałem po prostu zwrócić Waszą uwagę na to, gdzie de facto możemy szukać odpowiedzi w przypadku tego, kiedy coś zajmuje według naszych użytkowników, czy według nas za dużo czasu. Na Frontend Dev Tools w przeglądarce, które nam bardzo wiele są w stanie powiedzieć na temat tego, jak nasza aplikacja się wczytuje, co się wczytuje, co ile czasu zajmuje i jakie jest źródło tego ewentualnego problemu. Jeżeli problem leży po stronie serwera, no to oczywiście zależnie od tego gdzie mamy ten serwer przeglądanie logów, przeglądanie cash etc. Żeby sprawdzić, gdzie de facto leży problem. Więc podsumowując dzisiaj omówiliśmy sobie jak dbać o performance aplikacji nie tylko de facto no code, tylko ogólnie jak dbać o performance aplikacji.

‍

Dałem Wam mały tip jak dbać o strukturę bazy danych. Jaka jest różnica w strukturze jeżeli mówimy o Bubble albo mówimy o Xano. Wiadomo, każde podejście, każda platforma będzie się różniła, bo też możemy no code łączyć z tradycyjnym podejściem możemy łączyć tradycyjne podejście z no code, więc odpowiedzi będziemy szukać bardzo często w różnych miejscach. Planowanie będziemy wykonywać w różny sposób, bo inaczej będzie wyglądało planowanie do każdej różnej struktury bazy danych czy do każdego innego rozwiązania bazodanowego. I tak dalej, i tak dalej. Ale omówiliśmy sobie jak generalnie dbać o Frontend i performance na Frontend, czyli po stronie użytkownika. Omówiliśmy sobie jak wyważać workflow czy te wszystkie dane między urządzeniem użytkownika a naszym serwerem. Omówiliśmy sobie też de facto jak dbać o performance na naszym serwerze czy po stronie Backendu, co de facto ma największy wpływ na performance po tej stronie. Więc ja mam nadzieję, że dzisiejszy odcinek był dla Was pomocny i da Wam ogląd na to, jak dbać o ten performance. Ja chciałbym tylko dodać od siebie, że jak najbardziej te wszystkie aspekty są też uwzględniane w platformach no code i tam też z tym performance.

‍

Jeżeli o niego zadbamy, nie powinno być żadnego problemu, nawet przy setkach tysięcy użytkowników. To tyle ode mnie na dzisiaj. Mam nadzieję, że odcinek był dla Was ciekawy. Do usłyszenia w kolejnym odcinku. JUST No-Code Cześć!

‍