W tym odcinku opowiadam o konkretnych technologiach no-code/low-code i ich zastosowaniach.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek czterdziesty czwarty „Jak to jest z tym no-codem - aspekty praktyczne”. Zgodnie z zapowiedzią w odcinku czterdziestym pierwszym, że w niedalekiej przyszłości powstanie kontynuacja, dziś zajmę się omówieniem konkretnych technologii, ich wad, ich zalet. Jeśli chodzi o technologie zerokodowe, niskokodowe, czyli właśnie no-code i low-code.

Przede wszystkim będę chciał wspomnieć o zastosowaniach w konkretnych przypadkach, gdzie te technologie mają, nie da się ukryć, spory sens. Jeśli jeszcze nie miałaś, nie miałeś okazji zapoznać się właśnie z odcinkiem czterdziestym pierwszym, no to oczywiście zachęcam. Jak to w podcastach, shameless plug, jeśli chodzi o polecanie innych odcinków, ale akurat w tym przypadku naprawdę ma to sens, więc w tym odcinku czterdziestym pierwszym właśnie znajdziesz wprowadzenie do tej tematyki i wszystko to, co pozwoli ci płynnie przejść do przesłuchania tego odcinka w jak najbardziej wartościowy sposób.

Gwoli formalności, tylko jedną rzecz przypomnę. Mianowicie niektóre z tych technologii można sklasyfikować jako i no-code i low-code. W zasadzie można też wesprzeć tymi komponentami bardziej tradycyjnymi, gdzie po prostu programujemy w jakimś wybranym języku programowania. Tutaj warto pamiętać, że pojęcie tej niskokodowości jest w dużej mierze konceptem biznesowym. To nie jest jakieś pojęcie naukowe, to zostało stworzone po to, aby szerzyć technologie, które nie wymagają programowania, aby tworzyć aplikacje. Więc ten podział nie jest ścisły, formalny, tylko raczej biznesowy.

Kluczowym aspektem jest to, w jakim stopniu można tworzyć aplikację, nie będąc faktycznie programistą, a jedynie znając - oczywiście do pewnego stopnia - technologie i mając zdrowy rozsądek i trochę umiejętności logicznego myślenia.

Zaczniemy od jednej z bardziej znanych technologii no-code’owych, czyli Microsoft Power Apps. Można lubić Microsoft, można nie lubić. Nawet moja relacja z tą firmą była zróżnicowana, bo byłem i MVP Microsoftu i też miałem takie momenty, w których technologie Microsoftu wydawały mi się nie zawsze doskonale dopasowane. Natomiast trzeba się zgodzić z tym, że Microsoft ma ogromne doświadczenie, jeśli chodzi o rozwój, wspieranie, utrzymywanie technologii związanych z tworzeniem i wdrażaniem oprogramowania. Bo w zasadzie historia takich technologii sięga właściwie początku istnienia tej firmy. W latach osiemdziesiątych był Basic, mieliśmy środowisko programistyczne Visual Studio. Mieliśmy później na początku tego stulecia początek platformy .NET, jednej z kluczowych platform programistycznych obecnie. A jeszcze wcześniej był przecież Visual Basic for Applications, który w latach dziewięćdziesiątych poza wieloma makrami w Excelu i Wordzie poskutkował na przykład wirusem ILOVEYOU. Ciekawe, czy ktoś jeszcze ze słuchaczy pamięta?

Ale też wreszcie Microsoft, ten sam Microsoft dał nam Accessa, czyli może nie takie najbardziej znane, ale jednak wciąż istotny element pakietu Office. Wspominałem o nim w tym poprzednim czterdziestym pierwszym odcinku, że tak naprawdę to Access był jednym z takich pierwszych de facto bezkodowych, czy niskokodowych narzędzi do tworzenia aplikacji. Oczywiście takich zorientowanych na bazę danych, bo prawda jest taka, że właśnie takie proste aplikacje bazodanowe, w których jest jakaś baza, mamy jakieś proste interfejsy, które pozwalają na przykład na obsługę danych w bazie za pomocą trywialnych interfejsów wyświetlających po prostu odpowiednią liczbę pól dla poszczególnych informacji. Na przykład jak mamy kontrahentów, faktury i płatności. No to mamy formularz, gdzie możemy sobie zmienić dane kontrahenta, nazwę, numer NIP, adres. Możemy sobie zmieniać powiązanie, czyli który kontrahent, na które faktury. Takie bardzo proste aplikacje bazodanowe.

Porównując to do nowoczesnych rozwiązań chmurowych, webowych można się trochę uśmiechnąć, ale z drugiej strony w małych organizacjach Access naprawdę potrafił się sprawdzać, choć oczywiście miał pewne ograniczenia głównie związane z tym, że praca w Accessie oznaczała pracę na pojedynczym pliku. Praca współbieżna, czyli praca wykonywana przez wiele osób jednocześnie nie była po prostu możliwa, i nie da się ukryć, że było to dużym ograniczeniem.

No ale wracając do czasów obecnych, Power Appsy są jednym z ważniejszych trendów no-codowych, jednym z ważniejszych rozwiązań no-codowych. Można tworzyć w nich aplikację zarówno bezkodowo jak i dodając ten kod, co zresztą znajduje swoje odzwierciedlenie w tym, że Microsoft wyróżnia tak zwanych App Creatorów, czyli twórców aplikacji, ale właśnie bardziej bezkodowych od App Developerów, czyli takie osoby, które jednak programują, rozszerzając te aplikacje tworzone właśnie jako Power Apps. Co ważne, można te aplikacje uruchamiać zarówno jako aplikacje webowe, jak i mobilne.

Natomiast nie da się ukryć, że kluczowe z punktu widzenia Power Appsów jest to, że są one częścią ekosystemu Microsoftu. Jeżeli zależy nam w naszym projekcie na integracjach właśnie Microsoftowych, z SharePointem, z Sql Serverem, czy z innymi usługami Microsoftu, tymi zwłaszcza Power usługami takimi jak Power Automate, Power BI to w zasadzie nie ma co szukać dalej. Power Appsy są właściwym wyborem. Możemy jako Power Appsy tworzyć takie aplikacje właśnie bazodanowe, bliższe temu co znamy z Accessa, ale są też aplikacje oparte na tak zwanym płótnie, czyli sytuacji, gdzie mamy znacznie większą kontrolę nad interfejsem. Także jest dość duża swoboda tworzenia aplikacji.

A jeśli chodzi o wady, no cóż, spotykałem się ze stwierdzeniami, że gdy tworzy się takie większe projekty, chce się stworzyć większe projekty, też takie, w których występuje już faktycznie kod, to nie najlepiej Power Appsy radzą sobie z reużywalnością kodu, z możliwością jakby skorzystania z już wcześniej wypracowanych rozwiązań, czy też edycją aplikacji przez wiele osób jednocześnie. Nie mówię o użyciu, tylko o zmodyfikowaniu tej Power Appsowej aplikacji. Natomiast to dotyczy już sytuacji, kiedy faktycznie te projekty są większe. Jednocześnie sugerowałbym zwłaszcza, jeżeli słuchasz tego odcinka gdzieś tam w przyszłości, to może być też tak, że te problemy będą w pewien sposób już zaadresowane i rozwiązane.

Nie da się ukryć, że w ogóle w temacie wszystkich technologii no-code’owych bardzo ważną kwestią jest kwestia cen, i nie tylko tego, czy te ceny są duże, czy małe, ale także powiedziałbym kwestia takiej przejrzystości cenowej, bo z reguły bardzo łatwo jest zacząć. To już tak, nawet patrząc szerzej, wykraczając poza technologie, które omawiam w tym odcinku, z reguły to jest tak, że tanio czy wręcz za darmo można tworzyć takie aplikacje, ale oczywiście koszt wiąże się z ich użyciem. Power Appsy akurat pod względem kosztów rosną dość liniowo, są oczywiście pewne progi cenowe, im więcej użytkowników korzysta, to tam taniej wychodzą te koszty licencyjne. Natomiast w gruncie rzeczy jesteśmy tutaj oparci o płatność za użytkownika, ewentualnie za użytkownika per aplikację. Czyli tam są plany, że po prostu za użytkownika, który korzysta z nielimitowanej liczby aplikacji, płacimy pewną kwotę dolarów miesięcznie, ale możemy też na przykład, jeżeli mamy tylko jedną aplikację, to zapłacić mniej, i wtedy po prostu płatność odbywa się per user, per apka, ale jednocześnie mamy też pewne limity związane z ilością przechowywanych danych i plików.

Model ten nie jest, jak widać, bardzo skomplikowany. Natomiast, no nie da się ukryć, że jeżeli chcemy stworzyć aplikację, z której będą korzystać setki osób, na przykład każdy pracownik organizacji, to się okazuje, że nagle mówimy już o kwotach rzędu kilku czy kilkunastu tysięcy dolarów miesięcznie, i to już jest niemało. Dlatego ja bym powiedział, że Power Apps, zresztą to też dotyczy nie tylko tej technologii, bardzo fajnie się sprawdza, zwłaszcza wtedy, kiedy mamy na przykład do zrobienia aplikacje, w której mamy niewielu użytkowników. Na przykład pracowników danego działu, ale na przykład dużo ekranów, dużo danych do przetworzenia, rzeczy, które może nie dałoby się łatwo szybko zaprogramować, natomiast da się w miarę szybko „wyklikać” w takiej aplikacji no-code’owej.

Kiedy w wakacje przygotowałem sobie rozpiskę, może nawet nie tyle do tego odcinka, a bardziej takie luźne notatki jak mi wpadnie coś do głowy, to notuję, to właśnie spisywałem te usługi, które chciałbym omówić, wspomnieć w kontekście no-code’owym. I chciałem skonfrontować Power Appsy z, można powiedzieć, może nie bliźniaczą, ale jednak w jakiś sposób porównywalną usługą, jaką była AWS Honeycode, przynajmniej w założeniu. Natomiast no niestety nie zrobię tego, ponieważ ta usługa obecnie podlega wygaszeniu. Jeszcze do lutego 2024 będzie działać dla obecnych użytkowników, ale niestety cóż jest to pewien przykład, który wiąże się z ryzykiem, z jakim mierzymy się, gdy chcemy oprzeć biznes na jakichś usługach gotowych. Gdyby to było rozwiązanie dostarczonej do hostowania, do uruchomienia u siebie, w swojej infrastrukturze to czegoś takiego, ryzyka by wprost nie było.

Odchodząc może na moment od świata takich dużych organizacji, wielkich korporacji, przejdziemy teraz do platformy Bubble. Bo jest to jedna z dłużej istniejących, co też właśnie pod kątem chociażby właśnie trwałość i pewności usługi ma znaczenie. Więc jest to jedna z dłużej istniejących, ale też ciekawszych inicjatyw takich powiedzmy, że niezależnych. Bubble oferuje podobne możliwości co Power Apps, choć oczywiście bez takiej integracji z usługami Microsoftu, i Bubble mocno pozycjonuje się właśnie na oprogramowanie dla startupów, co jest zresztą niegłupie, bo tak naprawdę startupy, które chcą szybko uzyskać rozwiązanie techniczne, żeby zweryfikować swój pomysł, to dla nich szybki prototyp no-code-owy, to jest po prostu świetny kierunek, świetny trop, a jednocześnie Bubble też pokazuje, że nie jest to tylko narzędzie do szybkiego „wyklikania” aplikacji, z uwagi na też dbałość o zachowanie pewnych standardów bezpieczeństwa, ochrony danych czy też integrację z zewnętrznymi usługami, chociażby logowanie społecznościowe.

Jak dodamy do tego jeszcze system użytkowników, uprawnień, rejestrowanie zmian w aplikacji, ale także możliwość rozszerzania tej platformy - tak samo jak w Power Appsach mamy możliwość do programowania czegoś, no to w zasadzie mamy tutaj spore poczucie takiej swobody w tworzeniu aplikacji. Ja akurat z Bubblem osobiście nie miałem takich doświadczeń. Stykałem się z tą technologią, z tą firmą właśnie w postaci pewnych zapytań i analizowaliśmy, co i jak da się zrobić, i to jest ciekawa technologia. Choć siłą rzeczy też trzeba troszkę czasu poświęcić na to, żeby się w nią zagłębić.

A jakie wady? No cóż, jest to jednak mniejsze przedsięwzięcie niż takie Power Appsy. Choć dalej mówimy o ekosystemie, w którym według informacji ze strony Bubble’a jest już kilka tysięcy deweloperów. To co mnie strasznie zirytowało, to jest dużo bardziej skomplikowany model rozliczania. Ponieważ jakkolwiek mamy kilka tam planów cenowych, przy czym oczywiście dla dużych firm też jest możliwość jakiejś wyceny dodatkowej, to opieramy się tutaj o płatności za tak zwane workloads units, czyli ile jednostki obciążenia. Czyli de facto za pracę wykonaną przez Bubble’a, i to jakby samo w sobie jest w porządku. Tylko problem polega na tym, że sposób rozliczania tych jednostek jest niesamowicie skomplikowany, ponieważ nawet nie tyle każda operacja, nie wiem, na bazie danych, czy wyrenderowanie strony jest rozliczana, ale jest bardzo skomplikowany cennik zawierający bodajże kilkadziesiąt pozycji, w tym na przykład za każdy znak zwrócony z bazy danych. Tam jest oczywiście jakaś mikroskopijnie mała wartość ułamkowa, ale jakby ktoś się mnie spytał, ile będzie kosztowało utrzymanie aplikacji w Bubble, to ja bym powiedział, że chyba trzeba napisać narzędzie w Bubble’u, żeby móc obliczyć koszt trzymania takiej aplikacji.

Omówiłem dwa przykłady platform takich powiedzmy SASowych, gdzie nic nie musimy mieć. Podpinamy kartę i działa. Natomiast choćby historia tego wspomnianego Honeycoda pokazuje, że poleganie na SaSach może generować pewne problemy. Owszem, jeżeli chcemy uzyskać szybki prototyp, nie chcemy stawiać infrastruktury, to taka opcja z uruchomieniem czegoś gotowego jest świetna, ale im ważniejszą staje się wytworzona na szybko aplikacja, tym większe jest ryzyko, jeżeli coś pójdzie nie tak. A umówmy się, że nawet nam zdarzało się tworzyć aplikacje, które tam pozornie na początku wydawało się, że nie mają wielkiego znaczenia dla klienta, ale z czasem po cichu okazywały się strategiczne. Potem jak na przykład przestawały działać, bo ktoś na przykład zrestartował serwer czego nie robił od lat, no to na przykład „ojej ojej, pomóżcie, bo bez tej aplikacji to nie jesteśmy w stanie funkcjonować”, no i tak bywało.

Ryzykiem SASów może nawet nie aż tak często jest zamknięcie usługi, choć jak widać po Honeycode i to się zdarza, ale nawet kwestia zmian w pricingu, kwestia zmian cen,  może się okazać, że jakiś tam model funkcjonowania działu w firmie czy wręcz całej firmy oparte właśnie o takie koszty ulega jakiejś drastycznej zmianie. W związku z tym warto tutaj w tym momencie, abyśmy poświęcili chwilę na omówienie pewnego rodzaju kompromisu, pomiędzy z jednej strony takim tradycyjnym oprogramowaniem szytym na miarę, a aplikacją, która jest zupełnie dostarczona w modelu SAS na cudzej infrastrukturze. Czyli mówimy o sytuacji, w której mamy aplikacje, w których zdecydowanie nie programujemy od zera. Może nie są to no-code’owe aplikacje, bym powiedział, że raczej niskokodowe, ewentualnie po prostu trochę się programuje, ale jednak dużo mniej niż zwykle, ale robi się to we własnej infrastrukturze, bo wtedy w razie czego, gdyby coś się stało to, no nie jesteśmy w kiepskiej sytuacji.

Tutaj warto zwrócić uwagę, że to też nie jest remedium na zawsze, na wszystkie problemy, bo jeżeli ktoś przestanie rozwijać technologię i my zostaniemy z jakąś starszą wersją technologii na swoim serwerze, to jasne - jest nieźle, bo oprogramowanie będzie nam dalej działać, ale z czasem po upływie roku, dwóch czasem dłużej, to oprogramowanie będzie miało więcej podatności bezpieczeństwa, będzie większe ryzyko związane z utrzymaniem takiego nierozwijanego oprogramowania, więc po prostu trzeba coś i tak z tym zrobić. No ale z reguły mamy i tak wtedy więcej czasu.

Takich rozwiązań, o których mówię, jest mniej i wiążą się one z pisaniem jednak jakiejś ilości kodu. I tak naprawdę częściej, łatwiej można spotkać osobną część backendową, czyli tę, która działa na serwerze, tę, która łączy się z bazą danych i osobno frontend, czyli to, co widać - interfejs. Natomiast zanim jeszcze przejdę stricte do samodzielnie uruchamianych tak zwanych self hosted rozwiązań, czyli właśnie we własnej infrastrukturze, to wspomnę tu dla porządku jeszcze o rozwiązaniach co prawda działających w chmurze, ale właśnie tylko w wymiarze samego backendu, bo trzeba trochę wspomnieć niewątpliwie o Firebase’ie, czyli mówiłem trochę o AWSie, o Amazonie, był Microsoft, Google ma Firebase’a, czyli rozwiązanie, które służy do tworzenia API, czyli tych powiedzmy warstw serwerowych, z którymi mogą się łączyć nasze aplikacje frontendowe, aplikacje mobilne, gdzie poza samym tworzeniem właśnie funkcji biznesowych, możemy chociażby dodać obsługę pushy, powiadomień typu push na telefony, uwierzytelniania, podpinać różne źródła danych. I to jest niewątpliwie rozwiązanie, w którym dość łatwo można zacząć przygodę. Ja tutaj firma firmą, ale wielu moich studentów opierało swoje prace dyplomowe, jakieś projekty właśnie na Firebase’ie, bo jest po prostu łatwy. Mogli na przykład skupić się na robieniu własnego frontendu, podpinając go do Firebase’a.

Alternatywą dla Firebase’a jest na przykład AWS Amplify, jeżeli myślimy o dostawcach takich właśnie korporacyjnych, dużych. Natomiast niestety to są rozwiązania dalej zdalne, znaczy zdalne, no świadczone jako usługi. I tutaj jeżeli faktycznie chcemy mieć backend u siebie, to warto się zapoznać na przykład z takim narzędziem jak Supabase, który z jednej strony w zakresie tych podstawowych funkcji backendowych nie odstaje od tych usług korporacyjnych, a jednocześnie ma też fajny prosty cennik, no i właśnie jest też do samodzielnego uruchomienia self hosted.

Jeśli zaś chodzi o frontend, bo w końcu nie samym backendem żyje człowiek, to tu jest trochę inaczej, bo backend mimo wszystko wygląda podobnie, niezależnie od technologii, też niezależnie od projektu. Natomiast frontend to często żmudne dłubanie w tych interfejsach, aby zaspokoić oczekiwania klienta. I tu ciekawą opcją jest Appsmith, który działa w chmurze, ale działa też w trybie właśnie takim samodzielnie hostowanym. Appsmith zawiera kolekcje szablonów, widgetów, całych schematów aplikacji, tak że generalnie da się zrobić w tym całą aplikację, natomiast bez źródeł danych. Także można na przykład zostawić z własnym API, albo właśnie z Supabase’m, albo z Firebase’em, i w ten sposób stworzyć coś takiego hybrydowego.

I na tym kończę ten dzisiejszy odcinek, to tak naprawdę tylko wycinek, kilka przykładów technologii. Można by mówić chociażby o Salesforsie jako całej technologii do robienia aplikacji, i to wcale też nie niskokodowych. Są też inne przykłady, jak choćby Appian, technologie właśnie takie nakierowane na no-code. Natomiast tych technologii jest sporo, one powstają, zmieniają się. Wniosek jest prosty, na pewno bez konieczności stosowania dużej ilości kodu możemy już obecnie tworzyć rozmaite aplikacje webowe i mobilne, i ma to zwłaszcza sens w przypadku prototypów Proof of Concept. To jest coś co z czym my w Makimo spotykamy się, że często ktoś chce zweryfikować swój pomysł biznesowy na startup, ale też na jakieś przedsięwzięcie w ramach już takiej ustatkowanej firmy czy korporacji, i naprawdę potrzebuje czegoś szybko i tanio, ale żeby zweryfikować swój pomysł. Jeżeli ten pomysł jest weryfikowany pozytywnie, to potem się okazuje, że można z łatwością wtedy uzyskać większe środki na zbudowanie czegoś trwalszego, bardziej skalowalnego, bezpiecznego. No właśnie, ale trzeba zrobić ten pierwszy krok.

Z pewnością za jakiś czas powrócę do tego tematu, zobaczymy, co nowego się pojawiło, a może któreś projekty też się z zdezaktualizują. Natomiast nie da się ukryć, że jest to ekosystem bardzo dynamicznie rozwijający się. Na dziś to już wszystko. Dziękuję bardzo za uwagę, kłaniam się nisko i do usłyszenia.

KONIEC