Envoyé par Stéphane Le Calme
Pour situer les lecteurs dans le contexte, le développeur Ophir Lojkine est revenu sur le billet qu'il a co-écrit avec Yurii Rashkovskii au sujet du modèle d’architecture logicielle à trois niveaux (base de données, backend et frontend), souvent utilisé pour développer des applications web. Ils ont expliqué que ce modèle impose aux développeurs de nombreuses tâches fastidieuses et répétitives, qui les empêchent de se concentrer sur l’innovation et la création de nouvelles fonctionnalités pour les utilisateurs.
Pour apporter plus d'éclaircissements sur les points éventuellement mal compris, il s'est proposé de rédiger ce message.
Pour apporter plus d'éclaircissements sur les points éventuellement mal compris, il s'est proposé de rédiger ce message.
Je suis Ophir Lojkine, le contributeur principal du serveur d'application open-source SQLPage, et co-auteur de l'article original "Repeating Yourself Thrice Doesn’t Turn You Into a 3x Developer", dont la traduction a été publiée ici. Mon ami Yurii, qui a partagé notre article, est originaire d'Ukraine. Initialement, nous avions donc rédigé l'article en anglais, mais je profite de cette opportunité pour apporter quelques éclaircissements, étant francophone.
En bref, l'article visait à examiner le modèle conventionnel de découpage d'applications en trois éléments distincts :
- une interface graphique (frontend),
- un serveur applicatif (backend),
- et une base de données.
Dans de nombreux projets, cela se traduit par trois implémentations distinctes du modèle de données de l'application :
- D'abord, en SQL, sous la forme de tables et de clefs,
- Ensuite, dans des langages côté serveur comme Java, Python, ou PHP, pour créer une API facilitant l'accès à la base de données,
- Enfin, en JavaScript ou en TypeScript pour mettre en œuvre la manipulation des données dans l'interface utilisateur.
Il faut noter que l'on parle ici de trois couches physiquement distinctes, dont le code est généralement exécuté sur des machines séparées. On ne parle pas de la manière dont le code est structuré à l'intérieur de chaque couche, que ce soit une architecture Modèle-Vue-Contrôleur ou une autre.
Ce modèle en trois couches présente plusieurs avantages: la spécialisation des programmeurs, la possibilité de travailler en parallèle, la facilitation du développement de projets complexes, et une exploitation optimale des capacités de l'infrastructure sur laquelle chaque couche est déployée : navigateur web, serveur applicatif et base de données.
Néanmoins, dans les projets d'envergure, on constate souvent une certaine redondance du code entre les différentes couches, ainsi qu'une part non négligeable de code dédiée à la communication entre celles-ci. Pour les petites équipes ou les projets gérés par une seule personne, cela devient un inconvénient majeur.
Heureusement, plusieurs approches permettent de résoudre ce problème :
- Pour les applications axées principalement sur une interface graphique sophistiquée, on peut abandonner presque complètement le développement côté serveur et exposer directement les données au frontend. Les solutions open-source disponibles dans ce domaine sont notamment Supabase, PocketBase ou Hasura.
- Pour les applications avec une logique métier prédominante, les frameworks web traditionnels résolvent ce problème en centralisant le contrôle du frontend et de la base de données dans le code backend. Une solution commune implique l'utilisation d'un ORM et d'un système de templating au lieu d'une application javascript dédiée. Ces frameworks sont nombreux, on peut notamment citer Django, Ruby on Rails, ou Symphony.
- Pour les applications plus simples, il est possible de s'abstraire à la fois du backend et du frontend en adoptant une approche database-first. Cette alternative, bien que moins répandue, s'avère puissante et permet de tirer parti des capacités modernes souvent sous-exploitées des bases de données relationnelles. L'objectif de l'article initial était de présenter cette approche moins connue.
- SQLPage est un représentant de cette dernière catégorie, qui permet de concevoir une application web complète en SQL. Cela peut entraîner une perte de contrôle sur l'apparence visuelle précise de l'application, laquelle adoptera une apparence "standardisée". En revanche, cela se traduit par des gains significatifs en termes de vitesse de développement, de simplicité et de performances. Cette solution ne vise pas à concurrencer les frameworks classiques, mais plutôt à s'intégrer plus tôt dans le cycle de vie d'un projet. Elle permet ainsi de développer rapidement une structure de données adaptée à l'application, et d'itérer dessus tout en bénéficiant d'un retour visuel sur le résultat final en continu. Ensuite, lorsque l'application prend de l'ampleur, il est aisé d'ajouter un frontend et un backend classiques au-dessus de la base de données existante, sans devoir recommencer à zéro.
Quelle que soit l'approche choisie, une solide compréhension de la structure conventionnelle en trois couches, ainsi qu'une perspective éclairée sur les défis qu'elle engendre et les solutions envisageables, facilite la prise de décision et l'évolution du projet avec les technologies les mieux adaptées.
