Et si on codait des appli web ultra-dynamiques...sans une ligne de JS?

Ludwine Probst : Bonjour à tous et à toutes et bienvenue. Vous écoutez les podcasts Human Coders. Dans chaque épisode, j’invite un ou une développeuse pour parler de techno, de pratiques de développement ou tout simplement de sujets en lien avec l’informatique. Au programme également, des parcours de devs qui, j’espère, vous inspireront.

Je retrouve aujourd’hui Nicolas Blanco pour parler de développement web. Dans cet épisode, Nicolas revient sur les avantages et les inconvénients des modèles d’architecture SPA et MPA, mais nous présente surtout la philosophie de la librairie LiveView. Cette dernière fait le pari d’apporter plus de réactivité à des architectures dites classiques. Je n’en dis pas plus, je vous laisse découvrir tout cela avec Nicolas. Bonjour Nicolas.

Nicolas Blanco : Bonjour.

Ludwine Probst : Avant de commencer, est-ce que tu peux te présenter rapidement ?

Nicolas Blanco : Je suis un ingénieur web indépendant. Depuis plusieurs années, je travaille dans des startups et des plus gros groupes. Ma passion, c’est vraiment d’accompagner les entrepreneurs du web, de leurs idées jusqu’à la création de leurs prototypes ou de leur Minimum Viable Product (MVP).

Ludwine Probst : À côté de ça, tu t’es intéressé au MPA et au SPA. Pour ceux qui ne connaissent pas, est-ce que tu peux rappeler ce que c’est ?

Comprendre les architectures MPA et SPA

Nicolas Blanco : MPA et SPA sont vraiment des concepts d’architecture d’applications web. C’est un domaine qui m’intéresse beaucoup parce que ce sont des questions qu’on se pose au tout début d’un projet, lorsqu’on veut démarrer et se mettre concrètement dans la technique.

Le MPA, ce qu’on appelle les Multi-Page Applications, c’est la manière traditionnelle de créer une application web. Ce n’est jamais tout blanc ou tout noir, donc ce n’est jamais une application complètement MPA ou totalement SPA. Généralement, quand on parle de Multi-Page Application, c’est une application où la majorité de la vue, le markup HTML, est générée côté serveur. C’est le serveur qui fait sa petite popote dans son coin, qui génère l’intégralité du markup HTML, donc de la vue, qu’il envoie au client. La page est ensuite rendue dans le navigateur.

Quand on parle d’une application SPA, Single-Page Application, on parle vraiment d’une application où la majorité du code HTML est générée côté client, principalement via JavaScript.

Ludwine Probst : Pour le SPA, tu as des exemples concrets ? C’est Gmail par exemple ?

Nicolas Blanco : Un exemple qui va parler à la majorité des gens qui nous écoutent, c’est le fil d'actualité de Facebook. Quand vous chargez le feed de Facebook, vous pouvez rester sur la page un certain laps de temps et vous allez voir les différentes sections se mettre à jour : le nombre de likes qui augmente, les commentaires qui apparaissent en quasi-temps réel. C’est vraiment un exemple de Single-Page Application.

Mais là où on rejoint ce que j’ai dit sur le fait que ce n’est jamais totalement MPA ou SPA, c’est que même sur Facebook, lorsque vous passez sur d'autres sections, ce sont des liens classiques et la page se recharge. D'autres applications qui sont SPA, ce sont Google Maps ou la suite Google (Google Docs, Google Drive). On a là des fonctionnalités qui se rapprochent plus des applications natives : drag and drop, composition de page, etc.

Ludwine Probst : Quel est l'avantage d'avoir une architecture SPA ?

Nicolas Blanco : Cela permet vraiment d’avoir une interface très réactive qui se rapproche des applications natives que l’on pourrait avoir sur son ordinateur ou son smartphone. Ça permet d’utiliser à fond certaines fonctionnalités comme le drag and drop ou des fonctionnalités plus "offline", même si ce sont des fonctionnalités encore très peu utilisées pour les applications web.

Les limites et les problématiques des SPA

Ludwine Probst : Tu viens d'énoncer quelques avantages du SPA, mais est-ce qu'il y a quand même des limites à cette architecture ?

Nicolas Blanco : Les limites, c’est principalement une problématique de gestion de la synchronisation entre les différents composants de l’interface graphique qui sont, dans les applications SPA, générés dynamiquement via un framework JavaScript. Aujourd’hui, on a vraiment trois frameworks JavaScript qui sont les plus utilisés : Vue.js, React et Angular de Google.

C’est principalement ça la problématique lorsqu’on développe une application SPA : comment être sûr que les composants soient toujours synchronisés avec les données côté serveur. Une autre problématique survient lorsqu'il y a une mise à jour de données : être sûr que l’intégralité des composants soit synchronisée. Lorsqu'on utilise des frameworks web complexes comme React, on se retrouve rapidement avec un arbre, une architecture de composants qui peut être très importante. Comment être sûr que lorsqu'un composant parent est mis à jour, tous ses composants fils le soient aussi ?

Ludwine Probst : Ça veut dire que tu ne peux pas forcément le faire en SPA ? Rien ne vient t'aider à le faire aujourd'hui ?

Nicolas Blanco : C’est une problématique pour laquelle des solutions existent. Des librairies et des frameworks comme Redux, ou de nouveaux frameworks comme React Relay, permettent en même temps de simplifier la communication avec le serveur. Dans le cas de React Relay, cela permet de gérer tout l’aspect communication entre l’application SPA et le serveur, et de gérer cette problématique de synchronisation et de mise à jour des composants.

Lorsqu’on est dans des applications SPA, on communique généralement avec le serveur via une API, la plupart du temps en JSON. C'est aussi un des avantages du SPA : lorsqu’on crée une application SPA, on peut généralement réutiliser les mêmes points d’entrée d’API pour une application native mobile. Si vous voulez créer une application mobile, vous allez pouvoir réutiliser l’API que vous utilisez pour votre Single-Page Application.

Ludwine Probst : Comment ça marche pour la synchronisation dans le cas des architectures traditionnelles MPA ?

Nicolas Blanco : Dans les architectures traditionnelles où les pages sont générées statiquement côté serveur, on n’a qu'une seule application côté serveur. L’intégralité de l’état de l’application reste généralement côté serveur. Les sessions sont gérées via des mécanismes simples comme les cookies, directement transférés par le navigateur au serveur pour garder la session (utilisateur logué, etc.).

Dans des applications de type Single-Page Application, on se retrouve avec deux applications à gérer : l'application côté serveur (le backend) et le frontend qui est lui aussi une application totalement séparée. On doit synchroniser ces deux applications et les faire communiquer entre elles. On est sur des mécanismes de gestion de session différents, on va plus utiliser des tokens comme le JWT (JSON Web Token), exactement le même style de mécanisme qu’on utilise dans des applications mobiles.

Choisir entre SPA et MPA

Ludwine Probst : Supposons que demain je veuille créer une application web. Comment savoir si je dois partir sur du Single-Page Application ou sur une architecture classique ?

Nicolas Blanco : Mon opinion, c’est que les applications SPA sont vraiment destinées à créer des applications web complexes qui doivent être, de base, très réactives. Le SPA est plus adapté pour la création de logiciels internes, des back-offices d’administration complexes où l'on doit mettre à jour des graphiques, par exemple. Ce sont des applications qui ont besoin de fonctionnalités proches du natif : drag and drop, édition de texte, composition de page, comme des logiciels de gestion de contenu.

Par "complexe", j'entends des applications où les informations de ta page doivent vraiment se comporter de manière réactive et en quasi temps réel selon les informations reçues du serveur.

La problématique lorsqu’on démarre un projet web, c’est que si on décide de partir sur du SPA, on doit forcément créer le projet avec deux applications distinctes. On aura le côté front et toujours le côté serveur (backend, bases de données). Cela complexifie de base le prototypage d’un projet. Surtout que l’aspect "tooling" entre ces deux architectures est généralement totalement différent. Sur des applications SPA, on est sur des frameworks de vue JavaScript gérés avec Node.js, alors que côté serveur, on est sur des frameworks backend classiques (PHP, Java, etc.) qui génèrent du code HTML. On doit aussi réfléchir dès le début à cet aspect communication entre les deux applications.

Ludwine Probst : Si je décide de partir sur une architecture SPA, est-ce que je peux switcher facilement vers du MPA plus tard ou est-ce que c’est trop tard ?

Nicolas Blanco : Je pense que ce sera complexe. C’est plutôt l’inverse en fait : on commence par une application en MPA et progressivement, on a envie d’utiliser des frameworks JavaScript qui, eux, deviennent de plus en plus complexes comme Vue, React ou Angular. La problématique de ces frameworks de vue, c’est qu’ils incitent de plus en plus à passer sur une architecture SPA parce qu'ils veulent gérer tout l’aspect génération du markup HTML.

Après, chaque projet web est différent. Comme je l'ai dit, ce n'est jamais tout blanc ou tout noir. On peut avoir des applications un peu plus hybrides où une partie de l’application est en SPA. Si tu veux créer un back-office d’administration avec des graphiques de statistiques qui se mettent à jour, tu peux imaginer que ton back-office sera sur une architecture SPA, alors que d’autres parties de l’application seront plus traditionnelles en MPA. Mais il y a toujours cette problématique : ce sont des architectures assez différentes en termes d’outils et de technologies, et il faut les faire communiquer entre elles.

L'alternative avec Phoenix LiveView

Ludwine Probst : Par rapport au SPA, l’un des problèmes est donc d’avoir deux applications séparées, ce qui rend les choses plus complexes. Je crois que LiveView vient aider pour cela. Est-ce que tu peux nous expliquer ce que c’est ?

Nicolas Blanco : Les applications web deviennent de plus en plus complexes et vouloir démarrer tout de suite sur une architecture de type SPA complexifie énormément le développement et le prototypage. C’est pour cela qu'un certain nombre de librairies et de technologies ont été développées pour permettre de rester sur une architecture MPA classique, tout en ayant la possibilité d’avoir certaines fonctionnalités réactives du SPA : mise à jour en temps réel de composants de la page, sans forcément devoir passer sur une architecture SPA et générer totalement la vue via des frameworks JavaScript.

Un exemple de librairie qui a été libérée il y a quelques semaines est LiveView. Elle est écrite en langage Elixir, un langage fonctionnel très sympathique, très inspiré de Ruby et de Python. Cette librairie permet de rester sur une approche de type MPA tout en ayant des fonctionnalités dynamiques. L’avantage de LiveView, c’est que tout l’état de la page et des composants reste côté serveur. On n’a pas cet aspect de synchronisation des composants de vue avec le serveur que l’on a dans des applications SPA. Tout l’état des composants, leurs attributs, les données qu’ils contiennent, restent toujours côté serveur. LiveView gère la communication entre le client et le serveur via WebSockets.

Ludwine Probst : C’est facile à mettre en place ? Ça s'intègre avec n'importe quelle techno ?

Nicolas Blanco : Non, LiveView est une librairie en Elixir faite pour le framework web Phoenix. Le framework Phoenix est un peu l’équivalent de Ruby on Rails dans l’écosystème Elixir. C’est un framework MVC très semblable à Rails côté serveur.

L’avantage d’une librairie comme LiveView, c’est que ça permet d’éviter de devoir créer une application SPA avec toutes les problématiques que ça impose. En termes de fonctionnalités, quand on crée une nouvelle application web, on ne veut pas forcément créer quelque chose d’aussi complexe qu’un Google Maps. On veut juste, par exemple, valider des formulaires sans recharger la page. Si on veut un formulaire d’inscription d’utilisateur et qu’on veut valider que l’utilisateur a bien rempli son prénom, son nom, et mis une adresse email correcte, c’est un cas concret. Pour valider que l’adresse email n’a pas déjà été utilisée, c’est très lourd de devoir mettre en place des frameworks de vue type React ou Vue juste pour ça. Avec une librairie du type LiveView, on peut mettre en place ce genre de fonctionnalités très rapidement.

Ludwine Probst : Est-ce que c’est compatible avec d'autres technos si j'ai un projet en Ruby on Rails ou Django par exemple ?

Nicolas Blanco : Malheureusement non. Cette librairie est pour l’instant spécifique au framework Phoenix. Mais l’architecture et la philosophie derrière pourraient être portées dans le futur à d’autres frameworks web classiques côté serveur. Certains utilisateurs commencent déjà à essayer de porter cette philosophie de création de composants de vue côté serveur, en gardant l’état côté serveur et en les mettant à jour côté client via une connexion WebSocket.

Pourquoi cela fonctionne bien avec le framework web Phoenix ? C'est parce que de base, Phoenix gère très bien tout ce qui est connexion concurrente, parallèle et WebSockets. Ce sont des fonctionnalités déjà très bien gérées par le framework. C’est pour cela, je pense, que ce type de librairie est apparu en premier sur ce framework web.

On peut lancer un appel aux développeurs qui auraient envie de porter cette philosophie vers d’autres frameworks web. Si vous êtes développeur Ruby on Rails, Django, Java, PHP, etc., c’est une philosophie qui peut vous parler. J’incite tous les développeurs backend à aller tester cette librairie et le framework Phoenix si vous ne l’avez pas déjà fait, et pourquoi pas essayer de porter cette philosophie sur votre framework web de prédilection.

Ludwine Probst : On va finir sur cet appel. Si vous êtes développeur ou développeuse web, peut-être que la philosophie de LiveView vous a intéressés. Encore merci à Nicolas pour toutes ces informations. J’espère que cet épisode vous a plu. N’hésitez pas à venir en discuter sur notre blog, blog.humancoders.com, et à nous suivre sur les réseaux sociaux Twitter et LinkedIn. Je vous dis à très bientôt dans un nouvel épisode.