Le framework web Pusa a été publié avec une mise en œuvre d'un concept qui déplace la logique du frontend, souvent réalisée dans le navigateur à l'aide de JavaScript, vers le backend - la gestion du navigateur et des éléments DOM, ainsi que la logique métier, se font côté serveur. Le code JavaScript exécuté dans le navigateur est remplacé par une couche universelle qui appelle des gestionnaires situés sur le backend. Il n'est pas nécessaire de développer en JavaScript pour le frontend. L'implémentation de référence de Pusa est écrite en PHP et est distribuée sous la licence GPLv3. En plus de PHP, la technologie peut être mise en œuvre dans n'importe quel autre langage, y compris JavaScript/Node.js, Java, Python, Go et Ruby.
Pusa définit un protocole d'échange basé sur un ensemble minimaliste de commandes. Lors du chargement de la page, le navigateur charge le contenu de base du DOM et le noyau JavaScript de Pusa-Front. Pusa-Front envoie des événements du navigateur (tels que click, blur, focus et keypress) et des paramètres de requête (élément ayant déclenché l'événement, ses attributs, URL, etc.) au gestionnaire serveur Pusa-Back via des requêtes Ajax. Sur la base des données reçues, Pusa-Back détermine le contrôleur, exécute la charge utile et génère un ensemble de commandes de réponse. Après avoir reçu la réponse à la requête, Pusa-Front exécute les commandes, modifiant le contenu du DOM et l'environnement du navigateur.
L'état du frontend est formé mais non contrôlé par le backend, ce qui rend le développement pour Pusa similaire à du code pour une carte graphique ou Canvas, où le résultat de l'exécution n'est pas contrôlé par le développeur. Pour créer des applications interactives basées sur Canvas et onmousemove, il est prévu de charger et d'utiliser des scripts JavaScript supplémentaires côté client. Parmi les inconvénients de cette méthode, on note également le transfert d'une partie de la charge du frontend vers le backend et l'augmentation de la fréquence des échanges de données. serveur.
Parmi les avantages, on note : l'exclusion de la nécessité d'avoir des développeurs JavaScript pour le frontend, un code client stable et compact (11 Ko), l'inaccessibilité du code principal côté frontend, l'absence de besoin de sérialisation REST et d'outils comme gRPC, ainsi que l'exclusion des problèmes de synchronisation de la gestion des requêtes entre le frontend et le backend.
Source : opennet.ru
