Frontend controlé par un backend, retour d'experience?


#1

Bonjour,

Est ce que l’un de vous à déjà essayé de créer une application web où le frontend est (completement) controlé par le backend. Je m’explique:

  • Les events DOM sont envoyés au serveur (via websocket)
  • Sur reception de l’event, le backend fait son taff et recalcul la page entiere
  • Lorsque le frontend reçoit du nouveau code pour la page, il remplace le DOM par le nouveau code HTML

L’objectif étant de limiter au maximum la quantité de Javascript à écrire.

Qu’est ce que vous en pensez?

C’est dans l’optique de créer une appllication utilisé sur un reseau local.


#2

On me dit usine à gaz dans l’oreillette.


#3

Tu ne précises pas pourquoi tu veux faire ça.

Regarde du côté de Meteor je dirais. Ca ne fait pas ce que tu décris, mais synchronise le front et le back via une websocket.


#4

Ah oui j’ai oublié le besoin. C’est pour eviter d’avoir à coder en Javascript. Je vais mettre à jour le post.


#5

Largement expérimenté par le passé, dans l’ère pre-Ajax.
C’était pas toujours idéal.


#6

Ça se rapproche pas mal de ce que proposent des solutions de type pjax : https://github.com/MoOx/pjax


#7

Comment ça pas toujours idéal? Est ce que tu peux donner des exemples de bug ou contrainte que vous avez rencontrer.

On m’a dit que JSF faisait ce genre de chose.


#8

Bonjour,

J’ai travaillé avec JSF, ou pour être plus précis, un framework interne utilisant JSF. J’étais très insatisfait de l’expérience utilisateur que ce framework proposait.

La raison est très simple :

  1. Je fais une action dans mon navigateur (ex: clic, perte de focus d’un champ, etc.)
  2. Ça envoie sur le réseau, donc j’attends… parfois longtemps (+5s)…
  3. Je peux de nouveau faire une action et repartir à l’étape 1.

Quand tu as 10 opérations, autant dire que tu as envie d’aller autre part.

Le problème que nous avions était de deux ordres:

  • Performance de la partie java (on l’améliorait petit à petit)
  • Réseau (on ne pouvait rien y faire)

De même, les composants utilisés étaient très limités et il n’était pas possible d’être un minimum créatif, car ces composants avaient été écrit en partie en JS (à un moment, c’est obligé, hors langages spécifiques) et que la culture de l’entreprise était anti-JS. Là, c’est plus un travers que cette architecture peut fournir qu’une fatalité.

Excepté si ton objectif est uniquement de faire un contrôle au niveau de l’envoi de formulaire et navigation, ton architecture peut être intéressante pour une appli (hors tout public). Mais si c’est pour avoir des cas où tu doit générer une mise à jour de la page parce que le premier <select> limite les résultats du deuxième <select>, je te déconseille vraiment de le faire.

Je n’ai parlé que de la partie expérience utilisateur. J’ai aussi été déçu de la partie développement, mais je pense que c’est aussi une question de conception et qu’il est possible d’avoir quelque chose de correct (selon langage, framework, etc.).

Je suis cependant curieux de lire un retour d’expérience positif et de comment ces challenges énoncés ont été traités.


#9

En ce qui concerne le SSR j’ai testé ça il y a pas longtemps :

Couple Vue + NodeAtlas

Vue + NodeAtlas : de l’art du SSR ou Rendu Côte Serveur avec JavaScript
https://blog.lesieur.name/ssr-ou-du-rendu-cote-serveur-a-l-aide-de-javascript-avec-vue-et-nodeatlas/

  • Génération HTML Serverside
  • Reprise côté client pour être dynamique
  • Échange Websocket Client-Serveur pour maintenir à jour le tout afin qu’un nouvel onglet ouvert récupère un SSR à jour.

Ce qui donne :

Bingo !

  • Vue est fonctionnel côté serveur
    • Votre document est valide W3C,
    • Votre document est complètement SEO indexable (avec les formulaires retirés de la source),
  • Vue est fonctionnel côté client (avec les formulaires inclus dans le DOM de ce côté),
  • Vous n’avez écrit qu’une seule fois le code pour le rendu client et serveur. »

L’article explique le truc de A à Z et tu as un repos de test si ça t’intéresse.

Je suis entrain de faire un repos dans lequel je vais faire un chat + streaming audio/video avec Vue + NodeAtlas et tester avec des sous composants et le lien que je peux faire entre le « routeur front » et « routeur back ».

Je rendrais mon verdict à la fin de ses tests ;)


#10

Je confirme que JSF 2.x et ses librairies de composants font exactement le boulot. Et c’est l’objectif puisque ce sont des frameworks orientés composants avec du rendu côté serveur.
Ce n’est clairement pas le plus réactif et cela pose pas mal de problème “stateful”. Bah oui ta requête ne donne pas l’état des composants voisins donc soit il faut les inclure dans la requête, soit garder les infos côté serveur.

Je ne sais pas si cette problématique est spécifique aux frameworks orientés composants côté serveur mais sinon tu peux également regarder du côté de GWT/Vaadin.

Bien sûr on reste sur une stack “Java” mais en dehors de moins de Javascript, on a pas trop de précision sur l’environnement. J’aurais tendance à dire si vous avez des lacunes en JS autant s’y mettre pour de bon et Météor fera l’affaire et/ou utiliser des langages plus structurés qui transpilent en JS : Typescript, Elm, Ceylon, Kotlin, etc.


#11

C’est pas trop un problème de lacune c’est plus histoire de garder le compétence de l’équipe autour d’une seul stack.

Merci pour ton retour.


#12

Ce que j’ai voulu dire c’est que si tu veux éviter d’écrire du JS alors tu repars sur le modèle ‘full template’, sans ajax …

C’est loin d’être idéal aujourd’hui, on ne souhaite pas provoquer un chargement de page à chaque changement d’état.
Si tu voulais dire que tu veux générer le JS par un outils tiers, effectivement des technos exist(ai?)ent …
Ignorer le JS aujourd’hui, au vu de la popularité et du retour sur investissement qu’il procure me parait être un argument non valable.

A tel point que l’ont voit plutôt l’inverse, JS coté backend (pour l’API surtout). Ce qui d’ailleurs était la raison d’être de Livescript, le premier nom de JS.


#13

Petit “déterrage” pour apporter une opinion personnelle :

Je pense qu’un dérivé arrive sur le web dans les prochains temps. Je ne vois pas de raison pour laquelle ils ne le feraient pas … Du coup, le SSR … A ne pas enterrer trop vite je pense.


#14

J’ai fait un proto en python de cette idee et c’est une mauvaise idée.

  • D’une part c’est lent à cause de l’aller/retour sur le réseau. Peut être que avec les websocket ça peux passer sur un réseau local mais AMA c’est mort pour tout autre application même type back office

  • Le drag and drop était ni supporte ni supportable par le prototype. Dans le sens où les event du drag doivent répondre très rapidement pour fonctionner. En gros, c’est trop lent le réseau même en local.

  • Ça nécessite encore de connaître les API web. Mais ça on pourra pas y couper… Même si certains dev veulent retrouver un truc qui ressemble à l api qt. C’est pas mon objectif.

Je essayé de trouver une solution fullstack python pour faire du développement Web en fait. Et je pense qu on pourra pas faire ça sans Web assembly et ecmscripten. . Donc au final, on aura un gros blob de Javascript à parser et intrepreter (la vm python) et le code de l’app. Même si c’est assez rapide à la utilisation, le premier chargement va prendre du temps. Après ça peux passer dans certains cas genre les app métier (cf. Excel, Gmail, inbox qui mettent toutes du temps à démarrer)

J’ai essayé de compiler le python direct en JavaScript. Cette fois, le premier chargement est relativement rapide mais par contre il est pas possible d implémenter les exceptions python à l’aide des exceptions JavaScript donc la seule solution que je vois c’est faire la même chose que fait GNU Guile en utilisant la méthode qui s’appelle “Continuation Passing Style”. Je ne sait pas encore comment bien implementer async et await.

J’ai essayé transcrypt, c’est pas “good enough”. Exemple il ne supporte pas complètement la sémantique des paramètres python.

La route est longue mais la voie est libre ☺