.svg)
00:46 - Porównanie obu podejść w teorii
2:17 - Budowanie funkcjonalności
3:18 - Reużywalność kodu
4:23 - Infrastruktura i hosting
5:00 - Bezpieczeństwo i skalowalność
6:09 - Własność aplikacji
7:04 - Eksportowanie kodu
7:43 - O czym należy pamiętać w obu podejściach
8:47 - Przewagi no-code low-code
Cześć, z tej strony Kamil Tarczyński i witam Was w kolejnym odcinku naszego podcastu Just No Code. Dzisiaj w bardzo krótki sposób porównamy sobie, jak wygląda tradycyjne podejście w programowaniu kontra to podejście No Code Low Code. Zaczniemy pokrótce od teorii, następnie powiemy jaki jest tego potencjał. Dzięki temu, będziecie mieli pewnie większe zrozumienie jakie są de facto różnice między tymi dwoma światami.
Więc zaczynając od teorii, generalnie, dlaczego No-Code, Low-Code mówi się, że jest szybszym podejściem? Dlatego, że jeżeli programujemy w tradycyjny sposób, musimy cały nasz kod pisać linijka po linijce. Co powoduje, że samo pisanie tej każdej linijki, dbanie o to, jest czymś po prostu bardziej czasochłonnym.
Jest też zupełnie innym poziomem abstrakcji, bo nam, ludziom jeżeli czegoś nie widzimy, coś co jest dla nas bardzo wizualnie czytelne, tylko jest jakimś zbitkiem tekstu, jeszcze nie jest zbitkiem tekstu pod tytułem "jeżeli użytkownik kliknie w przycisk X to ma się zadziać rzecz Y" tylko jest zbitkiem "if this then that" i jeszcze bardziej złożonych syntaksów zdań programistycznych czy wyrażeń programistycznych, to nie jest to dla nas na pierwszy rzut oka czytelne.
Musimy się w to wgryźć, musimy to przeczytać, musimy to zrozumieć, musimy to umysłowo przetworzyć, żeby zrozumieć co się dzieje. W No Code wygląda to troszkę inaczej, bo w No Code sam interfejs wizualny budujemy z gotowych elementów. Czyli mamy pustą białą kartkę A4, na którą nanosimy elementy - czy to przyciski, czy to jakieś teksty, czy to jakieś grafiki. Więc od razu widzimy, jak to dokładnie wygląda. To jest tak zwane podejście WYSWYG - what you see is what you get - czyli to, co widzisz, to dostajesz. To jest dla nas bardzo czytelne, nie musimy wchodzić w to, jak wygląda kod pod spodem, po prostu od razu widzimy, jak będzie wyglądała ta nasza strona, którą właśnie sobie zbudowaliśmy.
Pod spodem, jeżeli chcemy oczywiście podpiąć na niej jakieś funkcjonalności, a na pewno będziemy chcieli, znowu mamy odrobinę łatwiej. Jest to kolejny level abstrakcji w programowaniu, który jest dla nas, ludzi, bardziej czytelny. Ponieważ tutaj budujemy znowu z gotowych klocków. Mamy na przykład workflow, że jeżeli użytkownik kliknie na przycisk X, to ma się zadziać krok pierwszy, krok drugi, krok trzeci. To jest dla nas bardzo czytelne, dzięki czemu rozumiemy tę aplikację i szybciej możemy ją zbudować. Bo pod spodem tego klocka jest tak naprawdę 50 linijek kodu, a tutaj jest to tylko jeden klocek, który po prostu dodajemy, konfigurujemy, uzupełniając pola i mamy gotowy workflow.
Kolejną sprawą jest, że tak samo jak w programowaniu, tak samo i w no-codzie możemy pewne rzeczy sobie reużywać, kopiować, klonować. Natomiast w programowaniu, jeżeli skopiemy sobie kawałek kodu, musimy się upewnić, że on będzie współgrał z całą resztą tego kodu. W no-codzie również możemy sobie kopiować workflow i również będzie trzeba dostosować, ale znowu kopiujemy sobie cały workflow, którym jest mnóstwo różnych kroków, a musimy dostosować pojedyncze drobne rzeczy, żeby on był odpowiednio w tą aplikację wklejony, co znowu jest dużo, dużo szybsze i dużo prostsze. Możemy również kopiować sobie całą aplikację w bardzo prosty sposób i po prostu zmienić ich wygląd, ich stylistykę czy drobne rzeczy, żeby to była już druga zupełnie inna aplikacja.
I oczywiście znowu w tradycyjnym podejściu jest to możliwe, ale w tradycyjnym podejściu jeżeli sobie coś skopiujemy i chcemy to zdeployować, musimy pod to przygotować całą infrastrukturę, wszystko inne, tak żeby to odpowiednio działało. W no-codzie wystarczy, że podepniemy do tej aplikacji domenę w większości platform i klikamy 1 przycisk deploy i mamy to już umieszczone na naszej infrastrukturze, ponieważ o tą infrastrukturę nie musimy dbać.
W no-codzie większość platform oferuje hosting. To znaczy, że tak samo jak budujemy sobie strony na różnych kreatorach tych stron, oczywiście nie porównuję tego, bo to jest dużo bardziej trywialne rzeczy, czy dużo prostsze rzeczy, to tutaj na platformach no-codowych wystarczy, że klikniemy właśnie jeden przycisk, bo pod spodem mamy już jakąś infrastrukturę, płacimy miesięczny abonament za jakąś infrastrukturę, za jakiejś jej capacity. i po prostu umieszczamy tam naszą aplikację. Nie musimy się martwić o całą konfigurację.
No i tutaj dochodzimy właśnie do dwóch bardzo istotnych rzeczy mianowicie security czyli bezpieczeństwa tej infrastruktury oraz jej skalowalności. Tak samo jak w tradycyjnym podejściu musimy dbać o security infrastruktury czy security aplikacji, o security aplikacji zaraz porozmawiamy. No to tutaj mamy tą przewagę, że ta infrastruktura z której korzystamy w NoCode'zie wiemy, że jest dobrze skonfigurowana. Mamy na to odpowiednie certyfikaty, bo wszystkie te platformy mają certyfikacje ISO, SOC i tego typu inne certyfikacje, które poświadczają po prostu o tym, że są to dobre, skalowalne i bezpieczne infrastruktury. Dlaczego skalowalne? Dlatego, że każda z nich po prostu korzysta pod spodem z AWSa albo z Google Clouda. Dzięki czemu wiemy, że są one i skalowalne i bezpieczne i nie musimy się obawiać tego, że jeżeli do naszej aplikacji nagle wbije kilka tysięcy użytkowników, to aplikacja nie będzie wyrabiała. Po prostu pod spodem się wyskaluje, jeżeli jej na to pozwoliliśmy, czyli tak samo jakbyśmy umieścili naszą aplikację w chmurze.
Bardzo wiele osób pyta za to co z własnością takich aplikacji, które budujemy na platformach no-codowych. Bo w tradycyjnym podejściu wiadomo jak to jest. Jeżeli stworzyliśmy sobie ten kod, napisaliśmy to to jest nasz kod. I jakby nikt nie ma niczego do tego, to jest po prostu nasze. Tutaj na platformach no-codowych sprawa wygląda odrobinkę inaczej, ponieważ ten kod wygenerowaliśmy za pomocą jakiejś platformy.
Więc jak to de facto wygląda?
Wygląda to tak, że do samej platformy my nie mamy oczywiście praw, bo to jest czyjaś platforma, ale do tego co wygenerowaliśmy na tej platformie mamy pełne prawo. Tak to wygląda na przykład w przypadku Bubble czy w Xano. Natomiast jeżeli chcielibyście wiedzieć jak to dokładnie wygląda od strony prawnej, no to ja tutaj odsyłam was do regulaminów gdzie takie rzeczy są bardzo dokładnie opisane przez twórców tych platform i gdzie będziecie mogli się dokładnie z tym zapoznać żeby na przykład wasz dział prawny powiedział czy to jest dla was OK czy to nie jest OK. Natomiast własność aplikacji jest w 100 procentach wasza.
No i w tym momencie może ktoś z was zapytać OK, to jeżeli to jest moje to znaczy, że mogę wyeksportować sobie kod, który został pod spodem wygenerowany. No i tutaj niestety muszę odpowiedzieć, że to zależy. Niektóre platformy na to pozwalają, żeby ten kod sobie wyeksportować, zmodyfikować umieścić gdzieś indziej niektóre platformy na eksport kodu po prostu nie pozwalają ponieważ są zbudowane w troszkę inny sposób który tego nie umożliwia i tutaj znowu jeżeli własność kodu posiadanie tego kodu jest dla was bardzo istotna no to musicie się po prostu zapoznać z tym która platforma na to pozwala jak to dokładnie funkcjonuje i czy to jest dla was odpowiednie rozwiązanie.
No i jedna rzecz którą te dwa podejścia mają ze sobą bardzo wspólne czyli to tradycyjne podejście i no-code, low-code jest to, że nadal zawsze, pomimo tego, że mamy security infrastruktury, skalowalność infrastruktury, że mamy jakby te dobre praktyki w kodzie zachowane, nadal my jako deweloperzy tych aplikacji musimy zadbać o bezpieczeństwo na poziomie logicznym aplikacji, czyli na poziomie samej aplikacji, czyli my musimy określić kto do jakiego typu danych będzie miał dostęp. Jak użytkownicy będą się mogli do naszej aplikacji logować. Co oni będą w tej aplikacji widzieć. jak będą mogli zarządzać tymi danymi jak również oczywiście musimy dbać o odpowiedni performance tej aplikacji no bo jeżeli nawet w aplikacji no-codeowej damy 500 różnych searchy na starcie ładowania strony no to wiadomo, że aplikacja będzie działała wolno bo po prostu ograniczy to nawet przeglądarka bo przeglądarka pozwoli nam zrobić tylko 6 requestów na raz więc zanim zrobi się 500 requestów na raz no to chwilę to będzie musiało po prostu potrwać więc nadal my jako deweloperzy będziemy musieli dbać o ten performance i skalowalność naszej aplikacji.
No i teraz tak powiedzmy sobie, jaki dzięki temu podejściu no-codowemu wobec tego tradycyjnego podejścia zyskujemy potencjał?
No głównie oczywiście czasowy. Jesteśmy w stanie budować skalowalne kompleksowe aplikacje jak również MVP dużo szybciej. Czy dużo szybciej to znaczy że generalnie ten proces jesteśmy w stanie skrócić kilkukrotnie? Nie do końca. Z naszych obserwacji wynika, że cały proces dostarczania aplikacji jest skrócony o jakieś 30 -50 % w zależności od skomplikowania projektu.
Dlaczego o tyle, jeżeli budujemy tak dużo szybciej? Dlatego, że musimy pamiętać, że proces budowy aplikacji, tutaj was odsyłam do naszego odcinka, w którym właśnie mówiliśmy o tym, jak wygląda proces budowy aplikacji, to nie jest tylko sam development. Development jest częścią procesu powstawania aplikacji, ale częścią tego procesu jest również faza warsztatów, jest również faza designu, jest również faza testów. I te fazy w obu podejściach trwają tyle samo, my przyśpieszamy tylko tą fazę developmentu. Więc oczywiście wiele na niej oszczędzamy, jeżeli jesteśmy w stanie oszczędzić od 30 do 50 procent, no ale nadal nie przyśpieszymy tego procesu dziesięciokrotnie, czy pięciokrotnie, jak bardzo w wielu materiałach marketingowych różnych agencji możecie wyczytać.
Jest to po prostu według nas, Nieprawda.
Tego procesu nie da się aż tak przyspieszyć, bo to znaczy, że musielibyśmy pominąć wszystkie inne procesy i porównujemy tylko i wyłącznie ze sobą czasy developmentu. Wtedy oczywiście w niektórych bardzo konkretnych i bardzo prostych przypadkach, rzeczywiście ten proces dewelopmentu może być aż tak bardzo przyśpieszony, ale przy bardziej kompleksowych rozwiązaniach jest to raczej po prostu nierealne, bo nadal nawet jeżeli tworzymy aplikację w no-codzie musimy się zastanowić nad tym jak ją zbudować dobrze zgodnie z dobrymi praktykami, zadbać o to bezpieczeństwo, zastanowić się jak ta logika aplikacji będzie rozłożona, jak ona dokładnie będzie funkcjonować i tak dalej i tak dalej.
Ten proces jest bardzo skomplikowany, tak jak mówiłem, odsyłam tutaj do jednego z naszych odcinków, w którym dokładnie, o tym bardzo rozmawiamy. Natomiast też tutaj możecie zobaczyć wykres, jak to dokładnie wygląda w podejściu tradycyjnym kontra no-code'owym, po prostu wyciągnąć też z tego jakieś wnioski.
Dzięki temu oczywiście jesteśmy w stanie szybciej wejść na rynek, jesteśmy w stanie szybciej zebrać feedback od naszych użytkowników, dzięki czemu jesteśmy w stanie po prostu z naszą aplikacją szybciej iterować, szybciej dostarczać wartość naszym użytkownikom, przebudować z nimi relacje, a to powoduje, że po prostu w najzwyczajniej świecie zwiększamy nasze wskaźniki, które będą wpływały na to, czy nasza aplikacja odniesie sukces, czy nasi wewnętrzni użytkownicy będą chcieli z niej korzystać, czy ona będzie dostarczała realną wartość naszej firmie.
Mam nadzieję, że ten odcinek był dla Was pomocny. To tyle ode mnie na dzisiaj. Cześć!
Podcast No-Code / Low-Code to podcast o technologii, w którym opowiadamy o digitalizacji, automatyzacji i tworzeniu stron, budowaniu aplikacji oraz platform internetowych. Poznasz wady i zalety low code i no code oraz zrozumiesz podstawy tych narzędzi. W odcinkach podcastu eksperci firmy havenocode poruszają także tematy biznesowe, wskazują najlepsze platformy low code i najlepsze platformy no code.
Dowiedz się jak korzystać z platform no-code i low-code, takich jak: Bubble.io, Xano, Webflow, Flutter Flow, AppSheet czy Zapier. Naucz się tworzyć aplikacje bez kodowania. Poszerz swoją wiedzę i zostań citizen developerem. Sprawdź, jak rozwija się branża low code i no code w Polsce i na świecie. Słuchaj i oglądaj podcast Just No Code!
