TECH MONDAY: Czy narzędzia low-code są nam w dalszym ciągu potrzebne?

Głównym celem przyświecającym firmie Microsoft przytworzeniu usług dostępnych pod nazwą Power Platform było zdemokratyzowanieprocesu tworzenia oprogramowania i analityki danych w organizacjach. Microsoftchciał rozwiązać problem długiego czasu i tzw. „wąskiego gardła” w procesiewytwarzania oprogramowania przez działy IT lub dedykowanych dostawców. Miało tonastąpić poprzez przekształcenie pracowników nieposiadających wykształcenia lubumiejętności z obszaru inżynierii oprogramowania w tzw. Citizen Developerów i wyposażenieich w narzędzia do rozwiązywania codziennych problemów za pomocąsamodzielnie tworzonych aplikacji bez konieczności pisania kodu. Udostępnionyprzez Microsoft zestaw narzędzi dawał możliwość budowy aplikacji dostępnych zpoziomu przeglądarki oraz klienta mobilnego, portali internetowych, silnikprocesów automatyzujących przepływy danych między systemami oraz kreatortworzenia chat botów.

Łatwość tworzenia oprogramowania za pomocą omawianychnarzędzi związana była jednak z pewnymi ograniczeniami. Ekrany aplikacjitworzonych za pomocą dostępnych w ramach platformy narzędzi sprawdzały siędoskonale przy prostych rozwiązaniach typu CRUD. W przypadku bardziej skomplikowanychinterfejsów, zbierających dane z wielu źródeł lub tabel, bardzo szybkodochodziliśmy niestety do granic możliwości platformy. Dodatkowo implementacjaskomplikowanej logiki biznesowej za pomocą narzędzi lub „języków” dostępnych wramach platformy była dość trudna i mocno uciążliwa. W takich przypadkach firmyponownie sięgały po wsparcie zespołów programistów i rozszerzały swojeaplikacje o komponenty tworzone za pomocą „klasycznych” języków programowania.Do tego wszystkiego dochodził pojawiający się często problem wydajności, która równieżnigdy nie była mocną stroną systemów opartych na platformach low-code.

Obecnie, w epoce popularyzacji generatywnej sztucznej inteligencji, narzędziaMicrosoft Power Platform coraz bardziej ewoluują w kierunku paradygmatu znanegopowszechnie jako „vibe-coding” (termin spopularyzowany przez AndrejaKarpathy’ego, współtwórcę OpenAI), polegającego na tworzeniu oprogramowania nieza pomocą języków programowania lub narzędzi, lecz za pomocą opisu w językunaturalnym. Model językowy zajmuje się w tym przypadku całą implementacjątechnologiczną, w tym tworzeniem struktury danych, logiki biznesowej orazinterfejsu użytkownika. Co jest w naszym przypadku istotne, duża częśćnarzędzi do „vibe-kodowania” aplikacji dostępnych w ramach Power Platformgeneruje kod w tradycyjnych językach, takich jak JavaScript, zamiastwykorzystywać dostępne w środowisku mechanizmy.  

Przyjrzyjmy się teraz popularnym sposobom budowyfunkcjonalności lub aplikacji za pomocą narzędzi low-code oraz ichodpowiednikom opartym na mechanizmach sztucznej inteligencji, dostępnym w ramachMicrosoft Power Platform.

Canvas Apps vs Code Apps

Technologia Canvas Apps (pierwotnie udostępniona pod nazwą „PowerApps”)to zestaw narzędzi umożliwiających budowę aplikacji za pomocą edytora WYSIWYG („whatyou see is what you get”) oraz zbioru kontrolek i konektorów dostępnych wramach Power Platform. Implementację logiki biznesowej umożliwia w tymprzypadku język Power Fx, zbliżony składniowo do języka formuł w Microsoft Excel.

Za odpowiednik Canvas Apps w świecie generatywnej sztucznej inteligencjimogą uchodzić Power Platform Code Apps. Są to aplikacje front-end tworzone zapomocą frameworków Vite oraz React (w domyślnej konfiguracji, możemy oczywiściewykorzystywać inne ulubione biblioteki) i uruchamiane wewnątrz platformy Power Apps.Dostęp do danych uzyskiwany jest za pomocą konektorów Power Platform, cozapewnia zgodność z regułami bezpieczeństwa i politykami DLP worganizacji. Ponieważ interfejs użytkownika opiera się w tym przypadku na kodzieJavaScript uruchamianym w przeglądarce, może on być znacznie bardziejinteraktywny i wydajny, a także odbiegać od standardów budowy UI dostępnych wramach platformy. Implementację złożonej logiki (np. kalkulatoraofertowego) możemy pokryć testami jednostkowymi, co z kolei umożliwiaautomatyzację kontroli jakości rozwiązania w ramach procesów DevOps.

Jedynym minusem opisywanego powyżej frameworka, któregoudało mi się dopatrzeć, jest brak możliwości uruchamiania aplikacji tworzonejza pomocą kodu wewnątrz klienta mobilnego Power Apps. Być może jest to chwilowa„przypadłość”, ale musimy być tego świadomi, tworząc aplikację za pomocą wspomnianejtechnologii. Dodatkowo, nawet jeśli nie korzystamy z Microsoft Dataverse jako głównego źródładanych, do używania aplikacji Code App i tak wymagana jest licencjaPower Platform Premium lub Pay-as-you-go.

Custom Pages vs Generative Pages

Pod nazwą Custom Pages kryje się możliwość osadzania jednostronicowychCanvas Apps wewnątrz aplikacji opartych na modelu (Power Platform Model-DrivenApps, MDA). Podobnie jak w poprzednim przypadku, technologia ta może byćzastąpiona przez aplikację stworzoną za pomocą języka JavaScript zwykorzystaniem generatywnej sztucznej inteligencji, tzw. „generative pages”.Microsoft poszedł w tym przypadku nawet o krok dalej i udostępnił edytorumożliwiający wydawanie poleceń agentowi budującemu rozwiązanie bezpośrednio z poziomuportalu make.powerapps.com. Dlabardziej zaawansowanych użytkowników istnieje możliwość budowy oczekiwanej funkcjonalnościw ramach lokalnego środowiska z wykorzystaniem udostępnionego przezMicrosoft zestawu skilli (w przypadku zastosowania Claude Code) lub pluginów(dla GitHub Copilot).

Power Platform Generative Pages są na razie dostępne jedyniew wersji Preview w wybranych regionach środowisk Power Platform.

Power Pages „classic” vs SPA

Power Pages w ekosystemie aplikacji biznesowych Microsoftpełnią rolę systemu CMS (Content Management System) przeznaczonego do budowy portali dlaklientów i/lub partnerów naszej organizacji i umożliwiającego natywnąintegrację oraz dostęp do danych w repozytorium Microsoft Dataverse. Niestety narzędziaumożliwiające rozbudowę funkcjonalną stworzonych w ten sposób witryninternetowych, pomimo pozytywnych zmian wprowadzanych w ostatnich latach wformie narzędzia Design Studio, są w dalszym ciągu mocno siermiężne, w porównaniu zinnymi dostępnymi na rynku rozwiązaniami podobnego przeznaczenia. Szczególnieistotną kwestią spędzającą sen z powiek architektów i projektantów rozwiązańzbudowanych na bazie Microsoft Power Pages był zawsze temat modyfikacji UI/UX.Przyznacie, że dostosowywanie lub implementacja logiki wykonywanej po stronieklienta za pomocą jQuery lub szablonów Liquid brzmi już mocno niedzisiejszo.

Na szczęście, podobnie jak w omawianych wcześniej przykładach,Microsoft poszedł po rozum do głowy i umożliwił budowę portalu za pomocą językaJavaScriptoraz wzorca architektonicznego SPA (Single Page Application). Całośćinterfejsu użytkownika może być obecnie tworzona lokalnie wewnątrz naszegoulubionego środowiska (oczywiście najlepiej z wykorzystaniem agentów AIwspartych przez dedykowany zestaw umiejętności lub rozszerzeń) i zainstalowana wśrodowisku docelowym Power Pages za pomocą zestawu komend Power Platform CLI. Zadostęp dodanych (za pośrednictwem dedykowanego API) oraz za bezpieczeństwoodpowiada w dalszym ciągu backend platformy. Nie mamy więc w tych obszarachwiększego ryzyka związanego z potencjalnym niepożądanym wyciekiem informacji,niż w przypadku wykorzystania klasycznego silnika Power Pages.

Wróćmy teraz do postawionego w tytule artykułu pytania. Czy wobecistnienia opisanych powyżej rozwiązań, które dzięki generatywnejsztucznej inteligencji znacząco skracają czas budowy oczekiwanych funkcjonalności zapomocą klasycznego kodu, okres popularności narzędzi no/low-code dobiega końca?Niestetynie istnieje w tym przypadku prosta, jednoznaczna odpowiedź. Dochodzimy tu niestetydo klasycznego, „konsultanckiego”: „To zależy” 😊.

W praktyce o wyborze technologii powinno decydować kilkaczynników. Najważniejszym z nich są w moim przekonaniu kompetencje zespołu tworzącego, a wprzyszłości utrzymującego budowaną funkcjonalność. Musimy odpowiedziećsobie na pytanie, czy będą to „makerzy” (czyli osoby nieposiadające szczegółowej,dogłębnej wiedzy technicznej z obszaru inżynierii oprogramowania), czy możeraczej programiści, będący w stanie ocenić lub poprawić generowany przez sztucznąinteligencję kod (który – bądźmy szczerzy – obecnie w większości przypadków sporo odbiegaod ideału).Musimy być również świadomi ryzyka związanego z artefaktami tworzonymi przezAI. Microsoft zaznacza, że kod generowany przez sztuczną inteligencję nie dajegwarancji gotowości produkcyjnej ani zgodności ze standardami organizacji,jeżeli takowe istnieją.

W niektórych przypadkach powinniśmy wziąć również pod uwagękwestię licencji (nowe metody tworzenia aplikacji, oparte na mechanizmach sztucznejinteligencji, mogą skutkować wyższym TCO), kanału dystrybucji aplikacji(wspomniany wyżej brak możliwości udostępniania Code Apps jako aplikacjimobilnych lub aplikacji zagnieżdżonych wewnątrz Microsoft Teams) oraz pożądanejfunkcjonalności. W przypadku ostatniej z wymienionych kwestii pamiętajmy zawszeo fundamentalnej zasadzie efektywności, mówiącej o tym, że narzędzia dobieramydo celu, a nie cel do narzędzi. A celem w naszym przypadku będzie zawszedostarczenie pożądanego efektu końcowego (funkcjonalności spełniającej wymaganiafunkcjonalne i niefunkcjonalne) w zakładanym czasie i budżecie.

Na koniec warto również wspomnieć, że istnieje jeszcześcieżka pośrednia w postaci agentów AI generujących klasyczne artefakty no-code.To już jednak temat na osobny artykuł.

Poniższa tabela zbiera najważniejsze wnioski dotyczącewyboru między klasycznymi systemami no/low-code, a kodem generowanym przez narzędziaAI uruchamianym w ramach Microsoft Power Platform.

Podsumowanie wniosków