Non, il ne s'agit pas de parler de l'organisation de la terrasse d'un bar comme le suggère le titre.
Cette question divise le monde de l'ingénierie logicielle depuis toujours.
Il faut choisir son camp. C'est la question rituelle dans un meet-up de développeurs : plutôt client ou serveur ? Plutôt front ou back ?
Mais c'est quoi cette question ?
C'est une question d'architecture.
Le front-end, c'est la partie visible du logiciel qui s'anime sur nos PC et nos smartphones. C’est beau, ça communique, ça pétille.
Le back-end, c'est la salle des machines du navire. Des mecs tout sales et transpirant dans cet enfer mécanique s'occupent de la base de données, des algorithmes, des traitements compliqués.
Entre les deux, un réseau filaire ou non, dont le débit est aléatoire.
La performance ressentie d'une application s'envisage donc sous ces 3 aspects. Si c'est lent, il y a 3 causes possibles :
- le serveur met trop de temps à répondre. Il a du mal à servir les pages à tous les clients connectés simultanément,
- le réseau est lent. Trop de données transitent entre le serveur et le client alors que le débit est limité.
- le client est dépassé. Votre PC est obsolète (= il a 2 ans) ou votre smartphone est celui que vous avez ressorti de la boite à chaussure.
Observez l'inter-dépendance de ces 3 acteurs.
Moins le client travaille, plus le serveur doit allouer des ressources pour construire une réponse “prête à l'affichage”.
Dans un cas extrême (mais qui existe), le serveur va jusqu'à construire l'image graphique à afficher sur le client, dont le rôle se réduit à gérer son écran+clavier+souris. Ça rappellera des souvenirs à ceux qui on développé des trucs sur des terminaux X.
D'un autre côté, plus le client travaille, moins le serveur est chargé car il se contente de transmettre des données “brutes” sans aucun traitement hormis la vérification de l'autorisation d'accès.
Là, ça rappellera aussi des souvenirs à ceux qui ont pratiqué les L4G (moi c'était NSDK). Oui, avant le web, on était tous à un moment conquis par les langages de 4e génération - rien que le nom fait rêver - qui permettaient de coder des outils sympas sur des PC en allant interroger des bases de données SQL distantes.
Notons au passage que l'ambition des L4G (formulée par James Martin en 1982) était de permettre à des développeurs non professionnels de faire leurs propres applications. Juste au cas ou certains imaginent que le no-code est une idée nouvelle.
La charge du réseau varie plus ou moins aléatoirement entre ces deux configurations. Mais globalement, on peut estimer qu’un déséquilibre entre client et serveur conduit à transmettre des données plus détaillées, donc plus volumineuses.
Ainsi, en fonction du placement du code entre le back-end et le front-end, on peut schématiser une charge du serveur/client/réseau qui se traduit ainsi :
Alors là, on se dit qu'il y a un optimum et que le mieux est de répartir équitablement les traitements.
Au milieu.
fifty-fifty.
Equilibré.
Et bien je pense que ce n'est pas le bon endroit.
Faire un choix
En répartissant le code de part et d'autre, on a une architecture qui cumule tous les défauts :
- une partie du code est loin de l'utilisateur, ça fait une application ramollie qui ne réagit pas promptement aux sollicitations de l'utilisateurs (le temps de faire les allers/retours via le réseau),
- les performances se dégradent coté serveur lorsque le nombre d'utilisateurs augmentent, alors que ça passe à l’échelle naturellement côté client (1 client en + —> 1 CPU en +)
- sur des navigateurs anciens ou des smartphones un peu obsolètes ça fonctionne mal.
En fait, c'est un peu le syndrome de “l’application Wordpress”. En tartinant du code un peu des 2 côtés avec des thèmes et des plugins, on obtient une appli moyenne.
Mieux vaut faire un choix assumé, guidé par le contexte d'utilisation de la web-app.
Si votre objectif est de développer un e-commerce ou un site de contenu à fort traffic, alors une bonne partie du contenu est public et ne dépend pas du profil de l'utilisateur. La meilleure architecture est de générer le site statique hors ligne et de placer la gestion des commandes sur le serveur. Dans le contexte d'un grand nombre d'utilisateurs sur des devices hétérogènes, mieux vaut miser sur le backend.
En revanche, pour un SaaS avec quelques centaines d'utilisateurs sur desktops/laptops, je préfère aller aussi loin que possible côté front-end.
Bien entendu, cette souplesse de placement d'un traitement est difficile dans les équipes dont l'organisation sépare explicitement les développeurs front et back.
Mais cette séparation est-elle encore d’actualité ? A-t-on encore les artistes de l’UI sur le pont et les forçats du backend dans les entrailles ?
J’observe que c’est moins fréquent. Ça ne signifie pas que tout le monde sait tout faire, mais que les équipes s’organisent autrement.
L'essor des frameworks backend en Javascript et les initiatives visant à effacer la frontière entre le client et le serveur pourraient enfoncer le clou.
En revanche, j'ai l'impression qu'une nouvelle répartition se dessine entre le hors ligne et le en ligne.
Entre ceux qui codent des générateurs, et ceux qui codent des interactions. Entre ceux qui entraînent des modèles, et ceux qui les mettent en production pour délivrer des prédictions.
Et que la question ne soit plus “front ou back ?”, mais plutôt “live ou off-line ?”
