Framework sieciowy Pusa, który przenosi logikę front-endu JavaScript na stronę serwera

Opublikowano framework sieciowy Pusa wraz z implementacją koncepcji przeniesienia logiki front-endu, realizowanej w przeglądarce przy użyciu JavaScript, na stronę back-endu - zarządzanie przeglądarką i elementami DOM oraz logiką biznesową odbywa się na zaplecze. Kod JavaScript wykonywany po stronie przeglądarki zostaje zastąpiony uniwersalną warstwą wywołującą procedury obsługi znajdujące się po stronie backendu. Nie ma potrzeby tworzenia front-endu przy użyciu JavaScript. Implementacja referencyjna Pusa została napisana w języku PHP i jest objęta licencją GPLv3. Oprócz PHP technologię można wdrożyć w dowolnym innym języku, w tym JavaScript/Node.js, Java, Python, Go i Ruby.

Pusa definiuje protokół wymiany oparty na minimalistycznym zestawie poleceń. Kiedy strona się ładuje, przeglądarka ładuje podstawową zawartość DOM i rdzeń JavaScript Pusa-Front. Pusa-Front wysyła zdarzenia przeglądarki (takie jak kliknięcie, rozmycie, fokus i naciśnięcie klawisza) oraz parametry żądania (element, który spowodował zdarzenie, jego atrybuty, adres URL itp.) do modułu obsługi serwera Pusa-Back za pomocą żądań Ajax. Na podstawie otrzymanych danych Pusa-Back określa sterownik, wykonuje ładunek i generuje zestaw poleceń w odpowiedzi. Po otrzymaniu odpowiedzi na żądanie Pusa-Front wykonuje polecenia zmieniając zawartość DOM i środowisko przeglądarki.

Stan frontendu jest generowany, ale nie jest kontrolowany przez backend, co sprawia, że ​​programowanie dla Pusa przypomina kod na kartę graficzną lub Canvas, gdzie wynik wykonania nie jest kontrolowany przez programistę. Aby tworzyć interaktywne aplikacje w oparciu o Canvas i onmousemove, istnieje możliwość pobrania i wykorzystania po stronie klienta dodatkowych skryptów JavaScript. Do wad metody należy również przeniesienie części obciążenia z frontendu na backend i zwiększenie częstotliwości wymiany danych z serwerem.

Wśród zalet można wymienić: eliminację konieczności udziału programistów front-endowych JavaScript, stabilny i kompaktowy kod klienta (11kb), niedostępność kodu głównego z front-endu, brak konieczności serializacji REST i narzędzi typu gRPC, eliminację problemy związane z koordynacją routingu żądań pomiędzy front-endem i back-endem.

Źródło: opennet.ru

Dodaj komentarz