Chapitre 2.4Les liens entre frontend et backend

Le front et le back vivent une longue histoire d'amour pleine de rebondissements.

Revenons en 2009 pour mieux comprendre l'évolution de leur relation.

Deux mondes bien séparés

À cette époque, il y a une claire distinction entre les langages et technologies front-end, exécutés par le navigateur, et ceux du back-end, exécutés sur les serveurs. Le front-end est composé du trio HTML, CSS et JavaScript (JS). Le back-end est plus hétérogène, le marché est partagé par les gros langages :

• PHP : ultra-dominant, il fait tourner environ 75% des sites web, notamment grâce aux outils de gestion de contenu WordPress, Drupal, Joomla...
• Java : très présent dans les entreprises pour créer des applications robustes.
• C# : privilégié dans l'écosystème Microsoft.
• Ruby : à la mode dans les startups. Il est plein de promesses et popularise des bonnes pratiques.
• Python : en pleine croissance, mais reste minoritaire.

En 2009, quand un utilisateur ouvre un site web, sa requête passe d'abord par le back-end. Il récupère les données, exécute la logique métier et c'est lui qui génère à la volée le code front-end avant de le retourner au navigateur.

Le front-end est donc entièrement construit côté serveur, à chaque chargement de page.

Le JavaScript, lui, ne sert qu'à saupoudrer un peu de vie sur une page déjà toute faite : un menu qui se déroule, un carrousel d'images, un message d'erreur sous un champ mal rempli.

Mais cette année-là, un petit nouveau s'apprête à casser cette harmonie.

L'arrivée de Node.js

Node.js est une technologie ouvrant les portes du back-end au langage JavaScript. Elle est présentée en novembre 2009 par un développeur américain, Ryan Dahl, lors d'une conférence berlinoise.

À ce moment-là, Dahl n'est personne dans le milieu. Il a abandonné une thèse de mathématiques quelques années plus tôt, vécu en Amérique du Sud et enchaîné les missions de développement web en indépendant. Au fil de ces missions, il s'est spécialisé dans les serveurs web, ces programmes qui reçoivent les demandes des visiteurs. Le JavaScript, lui, ne l'intéresse pas particulièrement, il ne le découvrira comme solution qu'après avoir cerné son problème.

Son point de départ n'a rien d'un grand projet de conquête. Dahl s'agace d'un détail : à l'époque, afficher une barre de progression pendant l'envoi d'un fichier relève du bricolage. Pour savoir où en est le transfert, il faudrait que le serveur puisse dire "j'ai reçu un quart du fichier, puis la moitié" pendant que l'envoi se poursuit. Or il ne sait pas faire deux choses à la fois : il encaisse le fichier en entier, sans dire un mot, et ne reprend la parole qu'une fois le travail terminé. En creusant, Dahl remonte à la cause. Imagine un restaurant où chaque table se voit attribuer un serveur qui reste planté devant elle du début à la fin du repas. Il prend la commande, la transmet en cuisine, puis attend là, sans rien faire, que les plats soient prêts. C'est ainsi que fonctionnent les serveurs web de l'époque. Mille visiteurs en même temps, c'est mille employés payés à patienter.

Il propose l'inverse : un seul serveur en salle, mais qui ne reste jamais planté devant une table. Il prend la commande, passe à la table suivante, et revient quand la cuisine l'appelle. C'est justement le fonctionnement du JavaScript dans le navigateur.

Restait un obstacle pratique. Le JavaScript vivait enfermé dans les navigateurs, où il était par ailleurs réputé lent. En 2008, Google publie en logiciel libre le moteur JavaScript de son navigateur Chrome. N'importe qui peut désormais le récupérer et le glisser dans son propre programme. C'est la pièce qu'il manquait à Dahl pour créer son serveur web en JavaScript. Après quelques mois de développement, il sort une première version de Node.js au printemps 2009.

Le projet n'intéresse alors à peu près personne. Or son idée ne vaut rien sans la communauté JavaScript, ce sont ces développeurs qui devront l'adopter, écrire les briques manquantes et lui trouver des usages. C'est pour donner de la visibilité à Node.js qu'il monte sur scène à Berlin quelques mois plus tard.

Son discours porte principalement sur le serveur et ses performances. Node.js est une technologie taillée pour encaisser un très grand nombre de visiteurs simultanés sans multiplier les machines.

La communauté, elle, y voit rapidement un autre bénéfice : un seul langage à maîtriser pour faire à la fois du front et du back.

Node.js a déclenché une explosion de popularité pour JavaScript.

L'essor d'un nouvel écosystème

À cette époque, le JavaScript est encore à son âge de bronze. Le langage traîne des syntaxes étranges, chaque navigateur l'interprète à sa façon, et il manque cruellement de bibliothèques, ces briques toutes faites qui évitent de tout réécrire. Node.js lui ouvre un territoire immense, et la décennie qui suit voit se construire tout un écosystème pour l'occuper.

Le langage lui-même se modernise, version après version, en gommant ses vieilles bizarreries. Des surcouches apparaissent, dont TypeScript, la plus répandue aujourd'hui. Elle ajoute au JavaScript la possibilité de déclarer la nature de chaque donnée, ce qui permet de repérer une bonne partie des erreurs avant même d'exécuter le programme.

Surtout, la communauté se met à partager son travail dans un immense catalogue public, où chacun publie ses briques et pioche dans celles des autres. Ce catalogue est devenu le réflexe de tout développeur, au point qu'un projet récent s'appuie sur des centaines, parfois des milliers de briques écrites par des inconnus.

Cet écosystème a aussi son revers pour les équipes. Autour de 2015, les outils se succèdent à un rythme épuisant, chaque année apportant sa nouvelle façon de faire qui prétend remplacer la précédente. Le milieu a même un nom pour ça, la "JavaScript fatigue". Les choses se sont assagies depuis, quelques outils solides ayant fini par s'imposer, mais le rythme reste soutenu.

Un front-end devenu autonome

Toutes ces évolutions ont profondément changé la manière de concevoir les applications web. Le front-end fonctionne désormais comme une vraie application, capable de charger dynamiquement son contenu. La navigation est plus fluide, sans rechargement de page.

Cette approche porte un nom, l'application monopage, ou SPA pour "single page application". Le navigateur charge l'application une fois pour toutes, et celle-ci ne recharge plus jamais la page. Elle va chercher les données dont elle a besoin et remplace à la volée les parties de l'écran qui changent. Portée par des outils comme Angular, React ou Vue, cette manière de faire s'est imposée dans les années 2010 au point de devenir le réflexe par défaut, y compris sur des sites qui n'en avaient pas l'usage.

Cette autonomie se paie sur deux points, et tous deux se jouent avant même que le visiteur ait vu quoi que ce soit.

• Le premier chargement : le navigateur reçoit une page vide, télécharge le code de l'application, l'exécute, et c'est seulement là qu'elle réclame ses données. Rien ne s'affiche avant la fin de cette chaîne, alors qu'une page fabriquée côté serveur arrive déjà remplie.
• Le référencement : pendant des années, les moteurs de recherche ont reçu cette même page vide, le contenu n'arrivant qu'après l'exécution du JavaScript. Beaucoup de sites très soignés se sont retrouvés invisibles sur Google.

D'où un retour de balancier. Depuis quelques années, de nombreux gros sites refont le chemin en sens inverse et fabriquent à nouveau leurs pages côté serveur, sans renoncer pour autant à l'application. Le serveur envoie une page déjà remplie, immédiatement lisible et indexable, puis l'application prend le relais dans le navigateur pour la suite de la navigation. Les outils qui portent cet entre-deux dominent aujourd'hui les nouveaux projets.

L'application monopage n'est pas morte pour autant, elle a retrouvé son terrain. Elle reste le bon choix pour un outil métier ou un tableau de bord, derrière une page de connexion, là où le référencement n'a aucun sens et où l'application sert des heures durant. Le débat porte sur les sites de contenu ouverts au public.

Des projets sans back-end dédié

Le front-end est devenu si autonome qu'il est aujourd'hui fréquent de lancer un projet sans back-end dédié. Quand les règles métier sont limitées et que l'application repose essentiellement sur du contenu, elle peut s'adresser directement à des services tiers, chacun spécialisé dans son domaine :

• Un service de gestion de contenu pour les textes et les images.
• Un prestataire pour les comptes utilisateurs et la connexion.
• Un partenaire de paiement pour les commandes.
• Un outil d'envoi d'emails pour les notifications.

Une petite équipe met en ligne en quelques semaines ce qui demandait des mois, sans jamais écrire la moindre ligne de back-end. C'est parfait pour valider une idée ou lancer un site de contenu.

Ce back-end n'a pas disparu pour autant, il est devenu celui de quelqu'un d'autre. Tu échanges du temps de développement contre un abonnement mensuel, une dépendance à des prestataires et des règles métier éparpillées entre plusieurs services.

Tant que tes besoins ressemblent à ce que ces services savent faire, tout va très vite. Le jour où tu en sors, il n'existe plus aucun endroit où poser ta règle, puisque aucun prestataire ne voit l'ensemble du tableau.

Le front-end et le back-end n'ont pas échangé leurs rôles, chacun tient toujours le sien. C'est leur relation qui s'est transformée en quinze ans, et elle continuera d'évoluer. Retiens surtout que la façon dont ils travaillent ensemble n'a plus rien d'automatique, elle se décide projet par projet.