Od MVP do złożonych aplikacji: czym jest no-code/low-code. Wyjaśniamy i obalamy mity!

Cześć, ja nazywam się Kamil Tarczyński i witam Was w pierwszym odcinku serii Just No-Code, w którym opowiadamy czym jest ta technologia oraz jak możecie ją wykorzystać we własnych firmach. Dzisiejszym tematem, na którym chciałbym się skupić, o którym chciałbym trochę Wam opowiedzieć będzie temat bardzo podstawowy, czyli wytłumaczenie czym w ogóle jest no-code / low-code i do czego możemy go wykorzystać oraz czy nadaje się on tylko i wyłącznie do tworzenia MVP. Więc zacznijmy od samego początku. Czym jest no-code? Jak może niektórzy z Was kojarzą na czym polega programowanie, to programowanie polega na pisaniu linijek kodu i deployowaniu tego wrzucaniu tego na jakiś serwer, dzięki czemu ta aplikacja jest dostępna np. w internecie lub w telefonie lub gdziekolwiek indziej, dzięki czemu nasi użytkownicy czy nasi pracownicy, ktokolwiek będzie naszym użytkownikiem, może z tej aplikacji korzystać. I oczywiście programowanie, które pojmujemy, które jakkolwiek rozumiemy czy mamy pojęcie jak wygląda, nie jest już którymś etapem ewolucji tego, jak programowanie wyglądało w historii. Oczywiście programowanie też jak każda technologia z czasem ewoluuje. Programowanie w pierwszych latach, kiedy zaczynaliśmy pracę z komputerami, kiedy komputery zostały powiedzmy odkryte w dużym cudzysłowiu i kiedy człowiek zaczynał z nimi pracę, też musiał je programować.

‍

To programowanie zaczynało się od tak zwanych kart perforowanych. Mieliśmy takie specjalne kartki, w których robiliśmy dziurki, dzięki czemu komputer wiedział, jakie instrukcje zero jedynkowe ma przetwarzać. Następnie mieliśmy programowanie np. asemblera, czyli takie bardziej troszkę wyższego poziomu, bardziej przetwarzające to, czym jest kod binarny, język bardziej zrozumiały dla człowieka. Później ten asembler ewoluował w coś jeszcze wyższego, te języki niskiego poziomu programowania. Później to wszystko ewoluowało w te wysokie języki programowania, języki wysokiego poziomu programowania. Te właśnie znane nam obecnie języki Java, JavaScript, C++ etc. Gdzie ten kod dla człowieka jest jeszcze bardziej zrozumiały, jeszcze bardziej czytelny, jest bardziej ludzkim językiem napisany. Bo jak wiecie komputer w żadnym stopniu nie rozumie tego, co my ludzie mu mówimy, w co my klikamy, co my robimy etc. To wszystko bardziej polega na tym, że my wydajemy jakieś instrukcje komputerowi, wydajemy mu jakieś instrukcje, one są gdzieś tam przetwarzane, a na końcu są przetwarzane na te zera i jedynki. No i zmierzając do tego no-code jest kolejnym etapem ewolucji programowania. Dlaczego?

‍

Dlatego, że w no-codzie nie tworzymy jak sama nazwa wskazuje za pomocą kodu. No-code znaczy bez kodu, czy low-code. Mała ilość kodu. Tutaj w dużej mierze nasze programowanie opiera się na tak zwanym programowaniu wizualnym, czyli tym co widzimy. Mamy interfejsy powiedzmy takie białe kartki papieru w edytorach no-code’owych, na których umieszczamy elementy strony. Od tego zaczynamy aplikację. Każda też jak wiecie jest podzielona na frontend, jest podzielona na backend i frontend. To jest to co widzi użytkownik. Backend natomiast jest to, co dzieje się po stronie serwera, czyli wszystko to, co jest dla nas niewidoczne, a gdzie przeważnie dzieje się cała magia aplikacji. Przechowywanie danych, ich odpowiednie przetwarzanie, tworzenie wyników, wyprowadzenie tych wyników na frontend itd. Więc, W no-codzie interfejs użytkownika tworzymy właśnie tzw. WYSIWYG, czyli What You See Is What You Get czyli za pomocą przesuwania elementów z listy na tą białą kartkę papieru. Czyli mamy taką białą kartkę papieru. Wyobrażamy sobie jak nasza aplikacja ma wyglądać, że tutaj będzie miała menu i tutaj poniżej będzie miała jakiś formularz logowania.

‍

Na przykład bierzemy sobie poszczególne elementy np. jakieś grupy, jakieś kształty, jakieś inne inputy, czyli właśnie te pola, do których zawsze wpisujecie swój adres mailowy czy hasło, czy jakieś inne informacje. Umieszczamy tutaj przyciski. I w ten sposób mamy stworzony frontend, czyli to co widzi użytkownik. Zaletą takiego podejścia jest to, że jest to oczywiście dla nas dużo bardziej czytelne. Od razu, namacalnie widzimy to, co tworzymy. Nie potrzebujemy sobie tego wyobrażać, nie potrzebujemy napisać setek linijek kodu, żeby ten interfejs stworzyć i nie musimy go później debugować. Znaczy, debugować musimy, ale nie musimy go odpalać, nie musimy go przetwarzać, żeby zobaczyć jak on wygląda. Po prostu od razu to widzimy na poziomie edytora, więc jest to dużo bardziej po prostu czytelne, dzięki czemu jest dużo szybsze w tworzeniu. Jak natomiast wygląda programowanie backendu w no-codzie? W no-codzie backend tworzymy w taki sposób czy wszystko to co ma się dziać na frontendzie, ale mają się kryć za tym jakieś akcje, po kliknięciu na przykład na jakiś przycisk to programujemy to w taki sposób, że zaznaczamy sobie np.

‍

jakiś element przycisk i mówimy aplikacji: W edytorze mamy takie specjalne miejsce, w którym mówimy: oK, jeżeli ja kliknę przycisk to chciałbym aby coś się zadziało. Otwiera nam się edytor i mamy tam step by step, przepływy informacji to się nazywa workflow, przepływy pracy. I w tych przepływach pracy zaznaczamy, że kroku ma się zadziać to w kroku drugim ma się zadziać to, a w kroku trzecim ma się zadziać to. No i oczywiście tutaj już od nas zależy co się tam będzie działo. Na przykład jeżeli wracając do tego formularza rejestracji czy logowania pod przyciskiem umieścilibyśmy akcję, która miałaby za zadanie zalogować lub zarejestrować użytkownika. No i mamy specjalny krok w takim edytorze, który mówimy zarejestruj użytkownika. OK, musimy wskazać skąd te dane mają pochodzić. Oczywiście mają pochodzić z tych input-ów, które mają jakieś nazwy, które mają też przyjmojwać jakieś wartość, jeżeli użytkownik tam te wartości wpisze. No i z tych input-ów te wartości mają być wzięte zapisane w naszej bazie danych. A na końcu, jeżeli rejestracja przebiegła pomyślnie, użytkownik ma być gdzieś przekierowany.

‍

Dla tych z Was, którzy odpowiadają za tworzenie procesów w firmach czy tego typu rzeczy, to będzie to przypominało trochę notację BPMN-owe, czyli tę notację gdzie zapisujemy step by step, co ma się dziać, dla jakiego aktora, jakie są warunki wykonania tych akcji itd. Itd. Więc jak widzicie w no-codzie tworzymy sobie wszystko właśnie za pomocą tych elementów wizualnych, które dla człowieka są czytelne od A do Z, ponieważ są wyrażone po pierwsze ludzkim słownictwem. Bo cała akcja nie wymaga zaprogramowanie całej akcji pod przyciskiem, nie wymaga poznania semantyki danego języka programowania, tylko jest when button x is clicked. Czyli kiedy button X został kliknięty, to ma się zadziać rejestracja, ma się zadziać przekierowanie i ma się zadziać na przykład wyświetlenie alertu o udanej rejestracji czy logowaniu. Dzięki temu jest to po prostu dużo bardziej czytelne. I to jest no-code. Tutaj posługujemy się z tymi takimi predefiniowanych elementami, które oferują nam producenci danej platformy. Takie powiedzmy sobie klocki Lego, z których tworzymy całą naszą aplikację. Oczywiście mamy dostępne różne klocki Lego i tak samo jak klocki Lego, mając różne różnorakie klocki możemy tworzyć różne różnorakie budowle.

‍

I do tego sobie zaraz przejdziemy, Zaraz będziemy rozmawiali sobie właśnie o tych przekonaniach, jakie panują dookoła no-code oraz o tym, co za pomocą tego no-code możemy zbudować. Więc. Generalnie: czym jest w takim razie low-code? Jeżeli no-code to jest ta część programowania, w której my tworzymy sobie wszystko bez użycia kodu tylko z tych predefiniowanych klocków, to czym jest low-code. Low-code za to wygląda trochę tak jak no-code. Mamy również te predefiniowane klocki, predefiniowane elementy, za pomocą których możemy zbudować sobie całą aplikację. No ale tutaj mamy jedno bardzo poważne ograniczenie. Jeżeli korzystamy z takiej platformy, która jest stricte no-codowa, to znaczy, że możemy korzystać tylko i wyłącznie właśnie z tych predefiniowanych klocków. To znaczy, że mamy również jakieś ograniczenia, które wynikają z możliwości danej platformy. Nie było jeszcze takiego producenta i pewnie długo jeszcze nie będzie. O ile w ogóle kiedyś taki producent platform no-code’owych się pojawi, który zdefiniuje wszystkie dostępne elementy świata. Niemożliwe. Według mnie. Przynajmniej na ten moment. I zaoferuje nam je w jednej platformie, żebyśmy mogli po prostu zrobić wszystko, co nam się rzewnie podoba, bez użycia ani jednej linijki kodu.

‍

Dlatego jest również podejście low-code’owe i polega ono na tym, że producenci zostawiają nam małą furtkę. Dzięki której na frontend lub backend lub w obu miejscach możemy dodać nasz własny kod. To znaczy, że w tym momencie możemy zbudować sobie trzy czwarte platformy nie używając ani linijki kodu. Dzięki czemu tworzenie tej aplikacji, tej automatyzacji czy czegokolwiek będzie po prostu dużo szybsze, efektywniejsze, bardziej zrozumiałe dla ludzi. Bo jeżeli wiemy, że Platforma ma jakieś ograniczenia i czegoś nie oferuje natywnie, to mamy tą właśnie małą furtkę, dzięki której będziemy w stanie zbudować czy dorobić sobie tę funkcjonalność, której nam brakuje i zintegrować się z tą platformą. Oczywiście platformy no-code’owe, tak samo jak platformy low-code’owe, oferują nam również bardzo często możliwość połączenia się z API. Jest to taki specjalny interfejs, za pomocą którego możemy łączyć się z innymi rozwiązaniami firm trzecich, dzięki czemu nadal te funkcjonalności platform możemy bardzo szeroko rozszerzać, ale myślę, że to jest temat na już osobny, zupełnie inny odcinek, więc w tym momencie pozwólcie nie będę go poruszał. Więc już wiemy, czym jest platforma no-code’owa, wiemy czym jest platforma low-code’owa i czym one różnią się od tego tradycyjnego podejścia do programowania.

‍

Jest to po prostu kolejny etap ewolucji, za pomocą którego dużo łatwiej jest nam programować te aplikacje, bo są one What You See Is What You get to jest świetne określenie. Czyli to co widzisz to to dostajesz, dzięki czemu to programowanie jest dużo szybsze, dużo bardziej efektywne jeżeli chodzi o wykorzystanie czasowe. Natomiast, również niesie to ze sobą pewne, jak już wspomniałem np. ograniczenia czy pewne potrzeby związane z tym, że musimy o tych platformach myśleć troszkę inaczej niż o takim tradycyjnym podejściu do programowania. Natomiast dokładne różnice w tym, jak te podejście się różni, o czym musimy myśleć, o czym musimy pamiętać, to też jest temat, który będziemy poruszali w kolejnych odcinkach tego podcastu. Dzisiaj chciałbym się natomiast skupić na tym, o czym powiedzieliśmy trochę na początku, czyli właśnie o tych mylnych przekonaniach na temat no-code / low-code i z czego one wynikają. Bardzo wiele ludzi uważa właśnie, że platformy no-code’owe przez to, że to są jakieś już predefiniowane elementy, takie właśnie te klocki lego czy zamknięte platformy, to mają one bardzo niskie możliwości. I oczywiście jeszcze parę dobrych lat temu mogła to być prawda.

‍

Te platformy rzeczywiście nie miały bardzo szerokich zastosowań, można było w nich tworzyć jakieś proste prototypy aplikacji czy automatyzacji, natomiast w tym momencie już są to bardzo dojrzałe produkty. Tacy producenci jak Microsoft, Google też SAP, tworzą własne platformy no-codowe, takie jak PowerApps, AppSheet czy AppGyver, które pozwalają nam na tworzenie bardzo fajnych produktów. Nie są to jeszcze oczywiście niekiedy platformy, które pozwalają nam na wszystko, ale już pozwalają nam na bardzo wiele. Mamy również takie platformy jak Bubble.io, z której my najczęściej korzystamy, czy Flutter Flow czy Xano. Są to już bardzo zaawansowane produkty, bardzo dojrzałe platformy Bubble na przykład już jest dwanaście lat na rynku, które pozwalają nam na tak naprawdę nawet bym pokusił się o stwierdzenie na tworzenie nieograniczonych, nieskrępowanych w żaden sposób rzeczy. Dlaczego? Dlatego, że tak jak już wspomniałem, te platformy są bardzo dojrzałe, a po drugie każda z tych platform pozwala nam na dodawanie własnego kodu. Czyli nawet jeżeli czegoś ta platforma nie oferuje, to nadal ten kod możemy sobie tam dodać. Dobrze. Natomiast skąd wynikają te przekonania?

‍

Jakie one są? Po pierwsze są takie, że te platformy są ograniczone, że się nie skalują, co też oczywiście nie jest prawdą, bo każda z tych platform, to, co sobie stawia za zadanie, to to, żeby mogła się skalować. Jak te platformy się skalują, jak one to robią? Każda z tych platform, oczywiście to jest jakaś zamknięta infrastruktura, gdzie my jako użytkownicy, jako twórcy aplikacji nie możemy wybrać sobie tego, co tam stoi pod spodem. My już dostajemy gotową platformę, gotowy hosting, na którym te nasze aplikacje są odpalane. Ma to swoje oczywiście gigantyczne zalety, takie, że jeżeli chcemy budować, skupiać się na budowie produktów, a nie na wyborze stacku technologicznego, tego na czym te platformy będą stały, to w większości wypadków bardziej zależy nam na dowiezieniu wartości w produkcie, niż na wybieraniu tego na jakiej technologii ona będzie stała. Bo tak długo jak technologia działa i realizuje swoje zadania, tak długo jest dobra, to te platformy pod spodem stoją również na chmurze. W przypadku Bubble jest to AWS.

‍

W przypadku Google'a jest to oczywiście Google. W przypadku platformy backend Xano również jest to *Google, więc tutaj wszystkie platformy oferują nam hosting w chmurze. Czyli one też się skalują. Oczywiście ten hosting wygląda trochę inaczej. My nie mamy na niego wpływu, on jest gdzieś tam pod spodem predefiniowany i my dostajemy odpowiedni cennik od producenta, od producentów tych platform, gdzie możemy sobie te cenniki wybierać, gdzie możemy wskazywać, że ok, my chcemy zacząć od jakiegoś małego planu, który będzie tam kosztował 29 dolarów miesięcznie, a później jak nasza aplikacja będzie się skalować, to również będzie rósł ten plan. Więc myślę, że tutaj właśnie to mylne przekonanie o braku możliwości skalowania możemy wsadzić między bajki. Platforma Bubble.io na ten przykład twierdzi, że jest bezproblemowo w stanie obsługiwać pół miliona użytkowników miesięcznie w aplikacji. Oczywiście patrzyłbym na to trochę z przymrużeniem oka ze względu na to, że to zawsze zależy od tego, co dana platforma robi, jakie funkcje realizuje, jak bardzo obciąża serwery, a nie urządzenie użytkownika. Ale tutaj wchodzimy w takie bardzo mocno detale techniczne, które raczej na ten moment nie mają dla nas żadnego znaczenia.

‍

Kolejnym takim błędnym przekonaniem na temat tych platform jest ich bezpieczeństwo oraz reliability, czyli to jak te platformy powiedzmy są odporne na awarie czy tego typu rzeczy. No i może jeszcze parę lat temu rzeczywiście mogło mieć to jakieś znaczenie, jakiś sens, te dwa argumenty. Natomiast w przypadku, wiadomo, platform takich, które są tworzone przez Microsoft czy przez Google, no to wiadomo, że to bezpieczeństwo jest na jak najwyższym poziomie. Są to rozwiązania typowo enterprise-owe rozwiązanie typu Xano posiada bardzo wiele certyfikacji poświadczających o ich bezpieczeństwie, tego jak przechowują swoje dane. Jest to również jedna z platform, z których my na co dzień korzystamy do tworzenia backendu. Platforma Bubble.io również tutaj oferuje bardzo wiele certyfikacji, które poświadczają o jej bezpieczeństwie, tym, że regularnie są wykonywane tam testy penetracyjne tej platformy, tak aby ona zapewniała jak najwyższe bezpieczeństwo. I z każdej z tych platform korzystają firmy małe i średnie oraz firmy typu enterprise. No i to reliability, czyli to, jak bardzo te platformy są odporne na awarie. Wyobraźcie sobie teraz podam tutaj świetny przykład: tworzycie aplikacji w tradycyjnym podejściu.

‍

Tworzycie ją inhouse-owo lub z pomocą software house'u no i tą aplikację, oczywiście ten kod, który jest napisany musi ktoś przetestować ile osób tę aplikację przetestuje zanim ją wypuścicie live. Dwie, trzy, pięć, może dziesięć. Każdy z tych komponentów zostanie oczywiście jakoś tam przetestowany. Każdy z software house oferuje odpowiednie usługi Quality Assurance, które mają właśnie za zadanie przetestowanie tego kodu, przetestowanie stabilności tej aplikacji, performansu i tak dalej. Mamy też testy automatyzuje, które automatyzuje te procesy, badają to, jak ta aplikacja działa, czy rzeczywiście jest odporna na różnego typu awarie. I teraz porównajmy to do takiej platformy jak Bubble. Takie platformy jak PowerApps, takie platformy jak Xano, gdzie każdy z tych komponentów, który ta aplikacja oferuje jest wykorzystywany na co dzień, przez miliony użytkowników. Miliony użytkowników. Bubble.io na przykład chwali się tym, że w tym momencie ma już ponad, jak dobrze pamiętam, dwa miliony użytkowników swojej platformy. Czyli ludzi, którzy tworzą aplikacje na tej platformie. Ci użytkownicy mają swoich użytkowników w aplikacjach. Więc każdy z tych klocków, z których ta aplikacja jest zbudowana, jest testowany przez miliony użytkowników miesięcznie, miliony użytkowników miesięcznie.

‍

Jeżeli tam się zdarzy najmniejszy błąd, w tym poszczególnym klocku na jednej z tych platform. Uwierzcie mi, że jest to bardzo szybko wyłapywane i łatane, ponieważ spowodowałoby to, że miliony aplikacji by po prostu nie działało na co dzień nie byłyby one stabilne. I oczywiście to nie znaczy, że na takich platformach nie ma możliwości awarii, bo nadal one tam występują, ale bardziej polegają na tym, że to my nieprawidłowo zaprojektujemy ten przepływ informacji albo tą komunikację między backend-em a frontendem, przez co po prostu gdzieś na tym etapie wystąpi błąd, ale nie na etapie samego komponentu, z którego zbudowana jest nasza aplikacja. Więc jak widzicie, podsumowując istnieje bardzo wiele mylnych przekonań na temat no-code, które według nas według mnie w tych czasach i obecnym okresie na ten moment nie są już w żaden sposób prawdziwe. Porozmawiamy sobie teraz w takim razie o tym najważniejszym, mylnym przekonaniu na temat no-code / low-code, że to podejście nadaje się tylko do i wyłącznie do budowania MVP, czyli takich pierwszych testowych wersji aplikacji, takich wersji, z którymi chcemy pójść, zbadać rynek, zbadać, pokazać je wśród znajomych, wśród jakiejś większej rzeszy użytkowników.

‍

Ale nie jest to jeszcze taki wiecie, wielki Enterprise-owy produkt posiadający wiele funkcjonalności, wielkie gigantycznego zbioru danych itd. Itd. Czy to jest w tym momencie prawda? Odpowiedź będzie krótka. Oczywiście to prawdą w tych czasach totalnie nie jest. Dlaczego? Dlatego, że tak jak już wspomniałem, po pierwsze te platformy oferują bardzo wysoki performance, niczym nie odbiegający od tradycyjnego podejścia, co zresztą możecie sprawdzić w bardzo wielu testach dostępnych platform. Możecie je sami przetestować, zobaczyć jak działa, możecie sprawdzić nasze case study, możecie sprawdzić sobie case study innych agencji no-code, które tworzą takie rozwiązania. Zobaczyć po prostu live, przeklikać te aplikację. Jak one działają? Gdzie są tysiące, dziesiątki tysięcy użytkowników? Jak te aplikacje działają na co dzień? Znajdziecie też mnóstwo artykułów producentów tych platform, gdzie są właśnie porównania tego performansu. Uwierzcie zresztą, że tacy producenci jak Microsoft, Bubble, Xano, Google, dla nich performance jest to absolutne top priority. Musicie wziąć pod uwagę to, że producenci platform no-code’owych bardzo długo walczyli właśnie z tym przekonaniem, że nadają się tylko do tego i że ten performance jest na niskim poziomie, przez co dla nich to też było top priority, żeby udowodnić, że tak nie jest. Kolejną rzeczą, która obala trochę ten mit, że nadaje się tylko do budowania MVP jest to, jak zaawansowane funkcje obecnie oferuje. Naprawdę w tym momencie, gdzie tych elementów predefiniowanych mamy mnóstwo, mamy naprawdę gigantyczne możliwości filtrowania, przetwarzania, pokazywania danych, budowania naprawdę pięknych interfejsów frontendu dla użytkownika, budowania bardzo kompleksowych przepływów tych informacji, workflow, integracji za pomocą czy to API, czy własnego kodu. To w tym momencie tak naprawdę ogranicza nas tylko i wyłącznie nasza wyobraźnia oraz znajomość tych rozwiązań i rozumienie tego, jak one działają, żeby budować te rozwiązania w sposób taki, który zapewni nam odpowiednią wydajność tych rozwiązań, a nie ograniczenie po prostu samego czystego przekonania, że te rozwiązania się do tego nie nadają. Owszem, nadają się, co te firmy udowadniają, gdzie możecie przeczytać mnóstwo case study i firm, które już mają setki tysięcy użytkowników, dziesiątki tysięcy użytkowników i nawet korzystają z tego korporacje jako z wewnętrznych czy zewnętrznych narzędzi do dostarczania gigantycznych wartości swoim użytkownikom. I dlaczego no-code, według mnie jest dużo lepszym rozwiązaniem jeżeli chodzi o budowanie MVP, ale również dużo lepszym jeżeli chodzi o budowanie już takich kompleksowych platform.

‍

Po pierwsze dlatego, że tak jak już słyszeliście, dzięki temu podejściu drag and drop, WYSWIG, tego interfejsu znacznie, znacznie przyspieszamy tworzenie aplikacji. Niektórzy mówią o nawet 10 krotnym przyśpieszeniu. Ja jednak raczej bym o aż tak gigantycznym przyspieszeniu nie mówił z tego względu, że jeżeli chcemy zadbać o performance, o jakość tej aplikacji, to nadal jest bardzo wiele procesów, dookoła których no-code nie załatwi, czyli odpowiedni design, odpowiednie quality assurance, odpowiednie przygotowanie do projektu, odpowiednie udokumentowanie, odpowiednie zrozumienie, zaprojektowanie całej aplikacji dopiero ten development, który sobie przyspieszamy. Natomiast z całą pewnością mogę powiedzieć, że development jest w stanie przyspieszyć co najmniej dwukrotnie, trzykrotnie w porównaniu do tradycyjnego podejścia. I to jest gigantyczna zaleta, którą bardzo wiele firm będzie postrzegało jako ta zaleta główna tego podejścia. I oczywiście nadal jeżeli te platformy nie będą oferowały wszystkiego, to ten własny kod będziemy musieli dodawać. Ale pamiętajcie tylko taką bardzo małą część, a nie będziemy musieli budować całą platformę. Dobrze więc teraz, jeżeli w tym momencie już mamy przegadane. Czym jest ten no-code?

‍

Jak z niego można korzystać? Czym jest low-code? Bardzo briefly przegadane. Czym takie podejście projektowania aplikacji się różni od tego tradycyjnego podejścia oraz jakie są mylne przekonania i dlaczego według nas one są mylne. Nie tylko zresztą według nas. Przegadaliśmy sobie również, czy no-code jest tylko i wyłącznie do MVP. Dlaczego niektórzy tak sądzą i dlaczego według nas tak nie jest. Spróbujmy odpowiedzieć sobie pokrótce na pytanie jakie w takim razie rzeczy możemy za pomocą tego no-code / low-code zbudować. Tak naprawdę, czy mam dobrą odpowiedź na to pytanie? Mam odpowiedź bardzo prostą na to pytanie. Tak naprawdę to, co chcemy zbudować zależy w 100 procentach od nas. Za pomocą no-code możemy budować automatyzację procesów, możemy budować aplikacje webowe, możemy budować aplikacje mobilne, natywne aplikacje mobilne oparte o React czy Flutter. Możemy również budować rozszerzenia do przeglądarek, możemy budować sam backend, możemy budować bardzo wydajne strony internetowe za pomocą np. takiego narzędzia jak Webflow. To taki trochę WordPress 2.0, taki WordPress naszych czasów. Więc tak naprawdę w obrębie już tych poszczególnych elementów czy to będzie automatyzacja, czy to będzie web, czy to będzie mobile, czy to będzie cokolwiek innego właśnie np.

‍

rozszerzenie do przeglądarki, czy sam backend, to nasze możliwości są nieograniczone i to tak naprawdę od nas będzie zależało, co dokładnie będziemy chcieli zbudować. Jeżeli chcę na przykład zbudować webowy CRM, do którego będę chciał dorobić sobie aplikację, to czy mogę to zrobić za pomocą no-code? Tak, jak najbardziej tak. Bardzo wiele przykładów takich aplikacji znajdziecie w internecie. Jedne lepsze, jedne gorsze, ale znajdziecie. Zobaczycie, że funkcjonują. Jeżeli będziecie chcieli zbudować aplikację do randkowania taką jak Tinder, która będzie tylko i wyłącznie na urządzenia mobilne i będzie to aplikacja natywna. Czy będzie to możliwe? Jak najbardziej tak. Czy jeżeli będziecie chcieli zbudować aplikację do wideokonferencji, która będzie aplikacją webową i mobilną, to czy będzie to możliwe? Jak najbardziej tak. Czy jeżeli jesteście specjalistami od frontendu, wiecie jak budować frontend, ale o backend-ie nie macie pojęcia i chcielibyście użyć jakiegoś prostego narzędzia, które też step by step w sposób czytelny dla Was, by backend umożliwiło Wam stworzenie to czy jest to możliwe? Tak. Jak najbardziej tak, bo frontend wyklikać sobie sami, backend wyklikacie sobie na przykład w Xano.

‍

Oczywiście trochę trywializuje, mówiąc wyklikacie, bo nadal potrzebujecie jakiejś wiedzy, wiedzieć jak to wszystko funkcjonuje, ale jesteście w stanie to zrobić i ten frontend zintegrujecie z tym rozwiązaniem, bo Xano wystawi Wam odpowiednie endpoint-y do metod, które sobie sami zbudujecie, czy endpointy, które sobie sami zbudujecie. Więc tak naprawdę temat tego, co jesteśmy w stanie zbudować, jak bardzo to będzie zaawansowane, będzie to zależało tylko i wyłącznie od Was, od waszego podejścia i tak naprawdę tego, jak bardzo zaznajomieni z tym tematem oraz podejściem jesteście. Musicie pamiętać, że to tak jak z każdym troszkę rozwiązaniem. Im dalej w las, tym więcej drzew. Tak samo jak w tradycyjnym programowaniu, bardzo łatwo każdemu z nas się nauczyć tego jak napisać pierwszy program, który piszemy chyba w każdym podejściu, czyli Hello world, czyli jak wyświetlić w konsoli napis Hello world. Tak samo jest w no-code. Pierwsze aplikacje będziecie w stanie budować w bardzo szybki, tradycyjny sposób. One będą proste, one będą prymitywne. Te interfejsy będą prymitywne, ale pokaże Wam to, jaka moc drzemie w tych platformach.

‍

Zobaczycie, że rzeczywiście mnogość funkcji, które te platformy oferują, czy mnogość opcji tego, co możecie tam budować, z czym integrować itd. jest naprawdę nieskończenie wielka i tak naprawdę nasza wiedza oraz wyobraźnia tylko nas ogranicza w tym, co możemy zbudować za pomocą tych platform. Podsumowując, no-code / low-code to kolejny etap ewolucji programowania, za pomocą którego w sposób graficzny, wizualny możemy budować aplikacje webowe, natywne mobilne, automatyzację, backend czy rozszerzenia przeglądarki. No-code nadaje się do budowania MVP prototypów, ale również nadaje się w stu procentach do budowania dużych, kompleksowych rozwiązań dla gigantycznych liczb użytkowników z gigantyczną ilością danych, które będziemy przetwarzali. No-code to już jest bardzo dojrzałe podejście do tworzenia oprogramowania, za pomocą którego możemy tworzyć właśnie te wcześniej wspomniane rzeczy. I nie jest to już tylko i wyłącznie zabawka, którą należy trywializować. Microsoft oraz Gartner twierdzą, a raczej precyzując to bardziej to Gartner twierdzi, że w 24 roku aż 65% aplikacji na świecie będzie tworzona właśnie za pomocą podejścia no-code / low-code. Natomiast Microsoft idzie jeszcze dalej i twierdzi, że 450 milionów aplikacji z 500 milionów aplikacji stworzonych do 2025 roku będzie tworzona właśnie za pomocą no-code.

‍

Czy to znaczy, że praca programistów albo stanie się niepotrzebna, albo programiści staną się niepotrzebni? Oczywiście totalnie nie, totalnie nie na tym to polega. Programiści nadal będą potrzebni, programiści wykonują super pracę, ale po prostu punkt ciężkości się troszkę przesunie. Programiści będą mogli się skupić na tworzeniu technologii, które mają bardzo, bardzo takie unikalne IP. To Intellectual Property, którego no-code na ten moment nie jest w stanie załatwić. Nie jest w stanie stworzyć np. czegoś takiego jak obecnie, teraz GPT czy tego typu rzeczy, które wiecie potrzebują naprawdę bardzo skomplikowanych algorytmów, bardzo skomplikowanych rzeczy i bardzo unikalnych rzeczy, które ciężko powtórzyć czy skopiować. To tam przesunie się większość programistów. A większość aplikacji będzie właśnie mogła powstawać za pomocą tego podejścia no-code / low-code. Bo jaki programista, kto z nas zresztą lubi tworzyć powtarzające się rzeczy? Każda aplikacja oferuje ekran logowania czy rejestracji. Każda aplikacja oferuje jakąś listę rzeczy, które w niej tworzymy. I to są rzeczy, gdzie nie trzeba odkrywać koła na nowo i raczej nikt nie chce po raz setny programować tego samego. Dlatego ten ciężar tworzenia tych aplikacji według nas po prostu trochę się przesunie.

‍

To tyle ode mnie w tym dzisiejszym odcinku. Mam nadzieję, że był on dla Was ciekawy i że udało mi się Wam opowiedzieć trochę o tym, czym jest no-code, czym jest low-code, jakie są jego zastosowania, czy nadaje się tylko do MVP i że da Wam to odrobinę wiedzy w tym temacie. To tyle ode mnie na dzisiaj. Dzięki. Cześć!

‍