Json Driven UI / Server driven UI

Co by się stało, gdyby kod frontendowy aplikacji można było by generować lub pisać w formie JSON?Przykładowo, każda podstrona aplikacji mogła by być pobierana jako osobny plik konfiguracyjny, który zostanie załadowany do kompilatora i z niego, odtworzone zostaną sekcje oraz logika. 

Obecnie widoki robimy tak, że pobieramy dane z serwera i czasem mapujemy je na widoki niemal 1:1, a czasem, po prostu wstawiamy je w już istniejące komponenty.  

Przykładem może być komponent tabelki. 

Najprostsze rozwiązanie to tworzenie tabeli od nowa za każdym razem, gdy chcemy mieć nową tabelę. Następnie wrzucamy do niej naszego JSONa z danymi, żmudnie deklarujemy headersy i stylowanie pól.

Można pójść krok dalej i utworzyć reużywalną konfigurację tabelki na frontendzie, na przykład jako komponent przyjmujący jakieś propsy. Dzięki temu tabelka wie, jak ma się wyrenderować. 

Jeśli wrzucimy wszystkie dane potrzebne do utworzenia tabeli w JSONa, to tworząc nową tabelę, po prostu zadeklarujemy jakie pola ma mieć, a nie będziemy się męczyć jak ma ona renderować te pola. Trochę to pachnie podejściem deklaratywnym.  

Możemy napisać mini-kompilator, który dostanie JSONa z danymi z backendu i przełoży go na nagłówki, kolumny i wiersze. 

Idąc dalej, można by w ten sposób przesyłać informacje o sekcjach strony, formularzach czy panelach. 

W wielu aspektach pracy ułatwiło by to pracę:

• Kod aplikacji można by przesłać z backendu. Dzięki temu, nie trzeba by deployować frontendu by uzyskać zmiany wyglądu.
• Można by zapisać konkretny wygląd UI i następnie go odtworzyć. Przydatne na przykład w konfiguratorach formularzy
• Odchodzi nam wiele powtarzalnej pracy (np. ze stylowaniem czy logiką), ponieważ widoki będą robione zawsze tak samo, w ustandaryzowany sposób. Tworząc nową tabelkę, nie robimy jej od nowa, tylko oczekujemy konfiguracji z backendu, który zostanie przetworzony przez wspomniany wcześniej konfigurator.
• Aplikacja wygląda zawsze spójnie 
• Team może być podzielony na osoby które tworzą nowe widoki, oraz osoby utrzymujące kompilator  

Jakie takie rozwiązanie ma wady?

• Wymaga utworzenia potencjalnie bardzo skomplikowanego kompilatora JSON > kod aplikacji, który będzie wyzwaniem dla teamu
• Każda nowa funkcjonalność będzie wymagała update kompilatora 
• Pisanie konfiguracji jest znacznie nudniejszym zajęciem niż tworzenie aplikacji. Wymaga to innego podejścia od programistów oraz potencjalnie ograniczenia liczby funkcjonalności w stosunku do zwykłego rozwiązania. 
• Kod pisany jest "naokoło". Z serwera pobieramy JSON, z którego odtwarzamy wygląd aplikacji w HTML. W niektórych rozwiązaniach, jak HTMX, można z serwera pobrać po prostu HTML z kawałkiem JS, co znacznie upraszcza kod.