Cześć, Z tej strony Kamil Tarczyński. Witam Was w kolejnym odcinku naszego podcastu JUST NO-CODE. Dzisiaj porozmawiamy sobie o bardzo ważnych tematach dotyczących no-code, dookoła których bardzo często krąży wiele pytań, niedomówień, niedopowiedzeń czy niepewności. Tematy, które dzisiaj poruszymy to wydajność, stabilność oraz koszty. Są to bardzo ważne kwestie, które de facto każdy z nas chce mieć zaopiekowane i chce znać odpowiedzi jak to de facto z tym no codem jest. Czy jest on wydajny, Czy możemy na nim obsługiwać setki tysięcy użytkowników? Czy jest on stabilny? Jakie za sobą niesie koszty? I dzisiaj właśnie o tym porozmawiamy. Na wstępie chcę tylko zaznaczyć, że dzisiejszy odcinek będzie takim powiedzmy zbiorem naszych doświadczeń czy odniesieniem takim uśrednieniem i znalezieniem wspólnego mianownika w odniesieniu do czterech platform, z których po prostu korzystamy i z których mamy też największe doświadczenie. Te platformy to Bubble.io, Xano, Webflow oraz FlutterFlow tam, gdzie będzie oczywiście trzeba. Czy będzie taka konieczność, bo platforma będzie znacząco się różniła właśnie tym wspólnym mianownikiem. Nie da się i do tego wspólnego mianownika sprowadzić to to oczywiście postaram się zaznaczyć i Wam dokładnie o tym opowiedzieć.
Natomiast drugą bardzo istotną kwestią jest to, że jeżeli rozmawiamy o wydajności, stabilności czy kosztach danej platformy, jest to dla nas bardzo istotna kwestia, bo chcemy zbudować rozwiązanie produkcyjne, które będzie działało dla wielu użytkowników. Wiemy, że chcemy, żeby się skalowało, żeby zaraz nie musieć tego przepisywać czy nie migrować do innego rozwiązania no-codowego czy cokolwiek innego. To powinniśmy zawsze dostosować nasze wymagania do potrzeb. To znaczy, że powinniśmy sobie na samym początku zwerbalizować to, jakie mamy potrzeby, jaka platforma jest w stanie te potrzeby pokryć i w jakim też zakresie, bo np. Bubble jest platformą bardzo elastyczną czy Xano jest platformą bardzo elastyczną, to są również na rynku no codowym platformy, które takiej elastyczności już nie oferują i nic z tym niestety nie zrobimy. I będzie to rozwiązanie dobre na zbudowanie tylko i wyłącznie MVP dla kilkudziesięciu użytkowników. Więc nie przedłużając zacznijmy sobie od wydajności. Jak ta wydajność de facto w no codzie działa. Bardzo często to pytanie o to biega nas od naszych klientów czy developerów tradycyjnych. Kod nie jest tak wydajny, bo jak się nie pisze samemu kodu, no to to nie może tak super działać I oczywiście pod pewnym względem w pewnym zakresie się z tym zgodzę.
Oczywiście, że jeżeli mamy zespół developerów, który w stu procentach operuje kodem i ten kod wymuska do każdej pojedynczej linijki, kropki i tak dalej, zoptymalizowany będzie od A do Z, to oczywiście on będzie dużo bardziej wydajny od takiego kodu, który jest generowany przez jakąkolwiek platformę, ponieważ został wypuszczony, zoptymalizowany w każdym możliwym względzie i do tego konkretnego, jedynego rozwiązania. Musicie pamiętać o tym, że platformy kodowe są platformami przeznaczenia ogólnego. To nie jest tak, że platforma no-codowa jest dobra do budowy fintechów albo jakiś social mediów, albo medtech, albo czegoś innego. Są to rozwiązania ogólne, które mają nam pozwolić budować również ogólne czy różnorakie rozwiązania. Z tego względu kod ich również jest zoptymalizowany, ale pod względem ogólnego performance czy ogólnej wydajności, a nie pod względem jednej, którejś konkretnej, którą my chcemy zbudować. I może się okazać tak, że jak cała platforma chodzi super, świetnie i ekstra, to niestety jakaś jedna funkcja, którą sobie wymyśliliśmy, już nie do końca, bo niestety na tej platformie będzie ona troszkę inny sposób funkcjonowania niż w tradycyjnym podejściu.
Oczywiście nie jest to przeszkodą, bo możemy budować różne workaround, możemy posiłkować się jakimiś rozwiązaniami firm trzecich, możemy zbudować sobie API na zewnątrz, żeby to obejść, na platformach no codowych możemy po prostu dodać kawałek własnego kodu, który będzie przetwarzał wtedy te dane tak jak będziemy chcieli. No ale tak, w tym wypadku wiadomo, że ten kod nie jest idealnie zoptymalizowany, natomiast jest zoptymalizowany tak jak powiedziałem, do zadań ogólnie i pod tym względem jest on świetnie zoptymalizowany, ponieważ platforma. Korzysta coraz więcej osób. Samego Bubble na ten moment korzysta już prawie 3 miliony osób i to samych deweloperów, którzy budują swoje rozwiązania na tej platformie. Więc Bubble i producenci innych platform no codowych dbają o to, aby ta wydajność była na jak najwyższym poziomie, ponieważ współpracują z dużymi firmami, współpracują ze średnimi firmami. I gdyby nie oferowali tej wydajności na odpowiednio dużym poziomie, na odpowiednio wysokim poziomie, to tracili by po prostu klientów. Dlatego oczywiście pod spodem ten kod jest generowany nadal on jest, jest zoptymalizowany trochę inny sposób, no ale działa to w zupełnie inny sposób.
Jest przeznaczony też do innych rozwiązań. Natomiast w przypadku np. FlutterFlow tutaj musimy właśnie dać ten wykrzyknik czy gwiazdkę przy przy tym rozwiązaniu, ponieważ FlutterFlow tworzy rozwiązanie natywne mobilne, gdzie aplikacja natywna z reguły będzie optymalna, o ile backend będzie na to pozwalał, będzie działała w sposób szybki. Plus FlutterFlow pozwala nam grzebać w no-codzie i go od A do Z optymalizować, ściągnąć, zmienić, dostosować czy zoptymalizować. Więc tutaj mamy troszkę większe pole manewru i też jest to zupełnie inny przypadek. Natomiast musicie też pamiętać, że jeżeli chodzi o wydajność czy skalowanie tych rozwiązań, to każda platforma no-codowa działa obecnie na chmurze Bubble np. na AWS, Xano na Google Cloud itd itd. Każde rozwiązanie korzysta z czegoś innego. Znowu poza FlutterFlow, który buduje nam aplikację mobilną, czyli Frontend. Tylko Backend musimy mieć skąd indziej. To już od nas zależy skąd on dokładnie będzie. Natomiast jeżeli właśnie mówimy o tym, czy te rozwiązania się skalują, czy one są wydajne, to jak najbardziej są. I znowu porównajmy. Porównajmy to do tradycyjnego podejścia. Tradycyjne podejście musimy mieć zespół DevOpsów czy innych ludzi, którzy zajmą się tym, żeby zbudować dla nas infrastrukturę, na której nasza aplikacja będzie chodzić.
Bo oczywiście jedną rzeczą jest zbudowanie, napisanie kodu aplikacji, ale zupełnie inną jest umieszczenie jej na infrastrukturze, która odbędzie przetwarzania również wydajny sposób jak będzie działał networking w takim rozwiązaniu, jak będą zbudowane zabezpieczenia itd itd. Jest to czas, który musimy poświęcić na budowę naszego rozwiązania itd. I który też musi być zrobiony dobrze. W no-codzie wygląda to zupełnie inaczej, ponieważ w no-codzie te nasze rozwiązania korzystają już z gotowej infrastruktury. Dostajemy taki wiecie, jeden opakowany produkt, gdzie my o infrastrukturę się nie martwimy, która stoi pod spodem, bo jest ona skalowalna, bo stoi na chmurze, bo jest ona dostosowana do tego rozwiązania. Tam już te wszystkie security rules itd są odpowiednio zaimplementowane. Jeżeli ktoś chce się z tym zapoznać, jak dokładnie to działa, to oczywiście odsyłam do dokumentacji danego dostawcy, gdzie możemy o tym wszystkim przeczytać. No i my tak naprawdę nie musimy się już tym przejmować. Musimy zadbać o wydajność na poziomie samej aplikacji, a nie infrastruktury, bo ta na poziomie infrastruktury jest już na odpowiednio wysokim poziomie. Bo to jest tak jak już mówiłem na AWS, tak dalej jest to tam gdzieś skonfigurowane, możemy się z tym zapoznać, jak znowu.
Oczywiście jest to dostosowane do tej poszczególnej platformy, ale działa w większości wypadków super. Jeżeli znowu mamy jakąś specjalną funkcję, której platforma nie obsługuje dobrze itd. Tak jak już mówiłem wcześniej, możemy sobie to wyjąć gdzieś na zewnątrz, więc pod tym względem znowu tutaj mamy pewną automatyzację, mamy pewne dostosowanie, które oczywiście ma swoje plusy. Jeżeli np. tak jak banki mamy jakieś specjalne regulacje, jakieś specjalne przepisy dotyczące bezpieczeństwa czy duże korporacje, to mamy dwa wyjścia. Oczywiście albo musimy postawić własną aplikację i własną infrastrukturę, bo inaczej nie da rady. Z drugiej strony możemy korzystać z aplikacji no codowych, ponieważ większość z nich pozwala na umieszczanie tych aplikacji na dedykowanych serwerach. To znaczy, że możemy skorzystać z takiego dedykowanego planu, gdzie po prostu serwer będzie nasz w naszej chmurze, albo nawet na naszym on premise, czyli lokalnie postawiony, a tam firma zdeployuje swoje rozwiązanie tak, żebyśmy mogli z niego korzystać i stawiać na nim nasze aplikacje. Więc jak widzicie dróg jest wiele. Możemy różnie do tej wydajności tutaj na poziomie infrastrukturalnym podchodzić i to zależy oczywiście od tego, jakie nasza firma czy nasz klient ma dokładne wymagania.
No i tak trochę podsumowując ten temat wydajności, gdzie porozmawialiśmy sobie o tym, jak de facto wygląda no code jak to funkcjonuje pod spodem, gdzie wiemy oczywiście, że ten kod na pewno nie jest tak idealny jak ten kot wymuskany, gdzie oczywiście wymuskany, co też swoje kosztuje, bo takie rzeczy jak wyuskanie najwięcej zajmują czasu. To, żeby nasza aplikacja była tak naprawdę wydajna, to naszym głównym zadaniem jest to, aby zadbać o jej wydajność. Jeżeli już producent platformy no codowej zadbał o to, żeby infrastruktura była wydajna, to naszym zadaniem zostaje zadbanie o wydajność aplikacji. Bo jeżeli kod nawet został zoptymalizowany maksymalnie, jak mógł zostać zoptymalizowany, chociaż cały czas ta optymalizacja kodu następuje, cały czas producenci platform no-codowych coś optymalizują, zmieniają, dostosowują itd itd. To my jako deweloperzy aplikacji. Naszym zadaniem jest zbudowanie wszystkich workflow czy zbudowanie interfejsu użytkownika w sposób taki, aby ta aplikacja była wydajna. Czyli np. na front endzie. Oczywiście unikamy dublowania elementów, żeby nie było tych elementów za dużo na jednej stronie, żeby serwer mógł łatwo te żądania przetworzyć, żeby te strony nie były ciężkie, żeby nie ściągał mnóstwa informacji z serwerów, czyli nie milionów rekordów czy tysięcy rekordów naraz, gdzie wiadomo, że to jest problemem.
Więc my musimy zadbać o to, aby ten Frontend był wydajny, tzw. lightweight, żeby on się szybko ściągał. Z drugiej strony oczywiście te nasze wszystkie workflow, jak one działają, jak będzie stworzona architektura bazy danych, czy te rekordy nie będą za ciężkie? Czy baza danych nie będzie za ciężka, Czy będzie zbudowana w sposób performatywny? Czy wszystkie workflow będą zbudowane w sposób performatywny, Czy nie będziemy robili za dużo? Czy to jest już właśnie kwestia, którą my jako deweloperzy musimy w aplikacji zadbać po to, aby była ona wydajna. W mojej osobistej opini w obecnych czasach, gdzie mamy naprawdę dostęp do super infrastruktury, gdzie większość aplikacji to raczej nie są super ekstra mega skomplikowane aplikacje, które mają za zadanie robić bardzo kompleksowe rozwiązania, to w tym momencie jesteśmy bez problemu w stanie zbudować większość aplikacji za pomocą no-codu czy low-codu, po prostu odpowiednio optymalizując naszą pracę. Co a propos stabilności jeżeli ta wydajność jest taka super i to działa, to jak jest z tą stabilnością? No stabilność trochę będzie zahaczyła o temat wydajności z tego względu, że.
Powiedzieliśmy sobie o tym wcześniej, że te rozwiązania stoją w chmurze albo gdzieś u nas. Więc o czym jest Stabilna? Stabilność może być znowu na poziomie infrastrukturalnym albo na poziomie kodu. Czyli czy nasz kod ma jakieś luki, bugi czy coś w ten deseń, co może powodować, że aplikacja się wywali, nie będzie stabilna, będzie przerywało jej działanie czy cokolwiek innego? Zacznijmy od tej części infrastrukturalnej, bo ona będzie po prostu krótsza. Jeżeli Bubble, Xano, Flutter, Flutter nie przepraszam, jeżeli Bubble, Xano i Webflow stoją na rozwiązaniach na Google Cloud. Czy trzeba właśnie to ich stabilność jest oparta o te rozwiązania. Oczywiście nadal one mają jakiś kod, który jest deployowany na tej infrastrukturze itd. Natomiast z punktu widzenia infrastrukturalnego my nie musimy się o to martwić. Tak długo, jak działa AWS, tak długo będą działały nasze rozwiązania czy jakakolwiek inna chmura. Natomiast możecie podnieść temat tego ok, ale nie mam pewności czy Bubble czy Flutter czy Xano czy Webflow jest napisany w sposób optymalny, bez bugów i tak dalej. Oczywiście takiej pewności mieć nie mamy, ale po to też ci producenci dostarczają swoje status page itd, żeby zobaczyć jak często te aplikacje się ewentualnie wywalają.
Zdradzę Wam, że Bubble w ostatnim miesiącu miał dostępność na poziomie 99,99%, więc mają na takim samym poziomie jak chmura publiczna stabilność. Plus czy ten kod nam się nie wywala? Tam mamy te wszystkie informacje o tym, że jeżeli nawet jakaś była awaria gdzieś po drodze, to my możemy o tym przeczytać, czego dotyczyła? Czy to był audyt AWS, czy to był jakiś audyt, czy po stronie danego producenta danej platformy. Wtedy będziemy po prostu mogli sobie wewnętrznie zreewaluować. OK. Czy ta platforma jest stabilna pod względem swojej własnej infrastruktury i kodu, czy nie? No i teraz jeżeli mamy już za sobą ten temat infrastrukturalny, to teraz przejdźmy do tego tematu kodu, czyli czy kod, który te platformy oferują, z którego my możemy korzystać, jest stabilny. No i znowu tutaj wrócę do tematu właśnie ilości osób, która korzysta z tych rozwiązań. Jeżeli my budujemy w jakimś software house albo wewnętrznym zespole, budujemy jakieś rozwiązanie, to ile osób to rozwiązanie ten kod przetestuje? 5 10 to jest super wynik. Oczywiście jeszcze możemy do tego puścić testy.
Automatyzujące, żeby mieć pewność, że całość jest stabilna. Co powinniśmy robić? Natomiast wyobraźcie sobie, że tak jak już powiedziałem wcześniej, z takiego Bubble samych deweloperów jest 2 miliony, ponad 700. Oni stawiają swoje aplikacje. Każdy z tych developerów może mieć kilka aplikacji, nawet załóżmy, że ma jedną. No i z każdej tej aplikacji korzysta jakiś użytkownik, chociażby jeden. To w tym momencie mamy prawie 5 milionów użytkowników, którzy na co dzień badają ten kod, który dostarcza np. Bubble np. Webflow czy np. Xano, który jest cały czas badany. Jeżeli coś jest w nim nie tak, albo powoduje jakieś awarie czy cokolwiek innego, jest to od razu do producenta platformy zgłaszane i w jakimś czasie naprawiane. Jedna rzecz wiadomo nie będę kłamał, są naprawiane szybciej, inne wolniej, ale są naprawiane. Gdyby tej stabilności nie było, gdyby te platformy nie oferowały tej stabilności, nie oferowały tych wszystkich rozwiązań, no to w tym momencie straciłyby użytkowników z tego względu, że po prostu byłby pewien problem z ich działaniem. Więc jak widzicie, ta wydajność czy stabilność testowym razem współgrają, są oparte na tych samych de facto podwalinach, na tych samych fundamentach.
Jedna czerpie z drugiej. I się razem ładnie zazębiają. Więc w mojej opinii jeżeli chodzi o stabilność też nie powinno być najmniejszego problemu. Zresztą to też możecie sobie sprawdzić sami wchodząc na nasze case study, sprawdzając nasze aplikacje czy sprawdzając po prostu statystyki dostępności danych rozwiązań. No i na końcu chciałem porozmawiać, poruszyć właśnie ten temat, który interesuje bardzo wielu, bo pomaga planować w jakiś sposób biznes, przewidywać to, z czym będziemy się de facto w tym biznesie mierzyli, czyli koszty, jakie to ze sobą wszystko niesie koszt. Oczywiście to wszystko zależy od platformy i tego, jaką platformę chcemy zbudować, jak wielu użytkowników będziemy obsługiwali, czy jak bardzo kompleksowe workflow będziemy budowali. Z tego względu, że ma to po prostu wpływ na zasoby serwera. Platforma Bubble ją za. Xano oraz Webflow oferują nam abonamenty i te abonamenty polegają na tym, że my kupujemy jakieś funkcjonalności plus jakieś zasoby serwera. One nie są bezpośrednio określone, że kupujemy 4 CPU i tak dalej, bo to nam niewiele mówi do końca, bo każdy z producentów tych platform poszedł trochę własny, indywidualny, cennik, który pozwala nam w jaki sposób określić to, ile de facto będziemy zużywali tych zasobów.
Serwera Bubble dostarcza kalkulator, w którym my możemy sobie te koszty policzyć. Jeżeli zbudujemy sobie testową aplikację, to tam mamy obliczenia tak zwane workflow unit, które nam pomagają reewauować to ile dana akcja kosztuje tych workflow unitów, dzięki czemu też jesteśmy w stanie naszą aplikację lepiej optymalizować, ponieważ możemy zobaczyć co najbardziej jest zasobożerne w naszej aplikacji, przyjrzeć się temu i to pod jakimś kątem, spróbować zoptymalizować. Natomiast wracając do tych abonamentów każda z tych platform jest oparta o chmurę, więc też trochę podąża tym konceptem. Możemy dokupić wykupić sobie takie podstawowe plany, które nam dają jakiś zasób serwera w jakimś fixed fee, czyli w jakiejś określonej cenie. Niektóre platformy pozwalają nam tak jak Bubble na przykład dokupować sobie tą wydajność serwera, żeby nas nie zblokować kiedy np. na raz wejdzie bardzo wielu użytkowników. Czy bardzo zostanie serwer obciążony, żeby nie blokować, timeout go, nie wywalać jakichś innych problemów, to Bubble automatycznie nam dobiera zasoby, ale oczywiście też się za to płaci. To się nazywa subskrypcją Pay as you Go Czyli tak długo jak używasz czy używasz więcej to po prostu płacisz za to, czego realnie używasz.
Trochę inna rozmowa jest w przypadku FlutterFlow, gdzie FlutterFlow de facto nie hostuje naszej aplikacji w żaden sposób, więc tam płacimy za dostęp do samego edytora, gdzie możemy naszą aplikację zbudować i ją umieścić w sklepach, gdzie backend również jest umieszczony gdzieś indziej. I oczywiście to jest jedna strona medalu. To jest ta publiczna strona medalu, tak bym to nazwał. Gdzie mamy dostęp do tych tradycyjnych abonamentów czy właśnie tych subskrypcji Pay as you Go, gdzie płacimy de facto za używanie serwera, więc to też jest znowu w naszej gestii. Wracając do wydajności leży to, aby zbudować tą aplikację optymalnie. Żeby te workflow nie zjadały dużo tych jednostek serwera, żeby one nie zapychały serwera, bo dzięki temu będziemy po prostu płacić mniej. Będziemy w stanie w tej samej cenie obsłużyć większą ilość użytkowników czy naszych klientów. Natomiast oczywiście też wspomniałem Wam o tym, że te rozwiązania mogą. Być umieszczone na naszych serwerach czy naszej chmurze. Wtedy wchodzimy już w tzw. indywidualne cenniki. Cenniki Enterprise, gdzie to już bezpośrednio z producentem danej platformy ustalamy sobie to, ile dana usługa będzie kosztowała i jak będziemy za nią płacić.
Oczywiście są tam cenniki, znamy te ceny, ale nimi się specjalnie w tym odcinku nie dzielimy, ponieważ zawsze i tak dochodzi do indywidualnych kalkulacji czy negocjacji na temat tego jak dane rozwiązanie będzie chodziło, co będzie zawierało, ile będzie kosztowało itd itd. Więc de facto my dostajemy jakies zasoby serwera, o które my też musimy musimy dbać. Więc jak widzicie koszty, stabilność, wydajność to wszystko idzie ze sobą w parze i daje nam jeden komplet, o który powinniśmy zadbać. I tutaj podsumowując dzisiejszy odcinek, to co chcę bardzo, bardzo mocno podkreślić, to jest właśnie to, że to od nas zależy w głównej mierze, czy nasza aplikacja no-codowa, low-codowa będzie wydajna, stabilna i jakie będzie niosła ze sobą koszty. Z tego względu, że jeżeli my te workflow czy bazę danych źle zaprojektujemy, będziemy obciążani niepotrzebnie serwer, to de facto zjemy więcej jego zasobów. Jeżeli my zjemy więcej jego zasobów, to aplikacja może się wywalać, będziemy więcej za nią płacić, więc tracimy stabilność oraz tracimy pieniądze. Wszystko sprowadza się do tego, że zawsze powinniśmy podchodzić do aplikacji w sposób przemyślany, zaplanowany, tak abyśmy mieli pewność, że robimy to w optymalny sposób.
I tutaj było świetne powiedzenie, które powiedział kiedyś podobnież Abraham Lincoln powiedział, że jeżeli dostanę 10 dni na ścięcie drzewa, to 8 dni będę ostrzył swoją piłę, aby była odpowiednia naostrzona. Trochę pracowałem, nie trwało to idealnie. Tak, ale oddaje ideę tego właśnie jak powinniśmy podejść do sprawy budowy aplikacji w no-code low-code oraz tradycyjnym podejściu, tak aby były one wydajne, stabilne i nie kosztowały nas wiele. To tyle ode mnie na dziś. Do zobaczenia!
