2 pièce(s) jointe(s)
3 solutions au problème des 3 couches : éliminer la complexité accidentelle et la duplication des efforts
Pourquoi il faut repenser l’architecture logicielle pour les développeurs solo et les petites équipes,
Yurii Rashkovskii estime que le modèle à trois niveaux freine le développement d’applications web
Dans un billet, Yurii Rashkovskii, un développeur et entrepreneur, a critiqué le modèle d’architecture logicielle à trois niveaux (base de données, backend et frontend), qui est souvent utilisé pour développer des applications web. Il affirme 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.
Yurii Rashkovskii a donné l’exemple d’ajouter une catégorie à chaque article de blog, qui semble être une chose simple à faire, mais qui nécessite en réalité de modifier le schéma de la base de données, les définitions des structures de données, les requêtes, les validations, les composants d’affichage, les tests et la synchronisation entre les trois couches. Il souligne que chaque couche et leur intégration occupent beaucoup de temps et d’énergie aux développeurs, qui doivent souvent répéter les mêmes opérations dans des langages et des environnements différents.
Il souligne également que ce modèle entraîne des inefficacités pour les utilisateurs finaux, qui doivent subir des temps de chargement plus longs et des fonctionnalités limitées. Il suggère qu’il faut repenser l’architecture logicielle pour la rendre plus simple et plus efficace.
Il suggère de repenser l’architecture logicielle pour la rendre plus simple et plus efficace. Il propose d’éliminer les couches intermédiaires inutiles et de réduire le nombre d’opérations à effectuer pour ajouter une nouvelle fonctionnalité. Il affirme que cela permettrait aux développeurs de se libérer des contraintes du modèle à trois niveaux et de se concentrer sur la valeur ajoutée pour les utilisateurs.
La perspective de Yurii Rashkovskii
Trois est un nombre magique. C'est le nombre de choses que nous pouvons garder à l'esprit sans perdre notre concentration. Donc, logiquement, une architecture logicielle à trois niveaux (base de données, backend et frontend) est un excellent modèle.
N'est-ce pas ? Nous le pensions aussi.
Alors pourquoi la création d'une fonctionnalité prend-elle autant de temps ?
En tant qu'ingénieurs, responsables techniques et développeurs, nous nous retrouvons souvent embourbés dans les complexités de la « plomberie » des applications.
Le modèle à trois niveaux impose aux développeurs un éventail de trivialités chronophages. Du mélange incessant d'octets entre les trois couches à la définition fastidieuse des structures de données trois fois, nous luttons contre la surcharge de synchronisation entre différentes bases de code tout en nous efforçant d'optimiser les performances, de gérer les modifications de schéma de base de données et de maintenir la cohérence des données.
Cela nous laisse aspirer à plus de temps pour innover et créer de nouvelles fonctionnalités intéressantes pour nos utilisateurs.
Maintenant, c'est logique : nous avons perdu de vue que même dans une architecture claire à 3 niveaux, il y a plus de trois choses à considérer. Nous, développeurs solo et petites équipes, devons toujours réserver un espace mental aux questions non techniques, telles que les utilisateurs, leurs besoins et la communication. Et même dans le domaine technique, avoir trois couches bien séparées nous oblige encore à penser à deux autres choses : la communication et la synchronisation entre les couches consécutives.
En regardant l'architecture à trois niveaux, nous pouvons voir comment chaque niveau et leur intégration nous occupent. Disons que vous avez une petite application de blog et que vous souhaitez ajouter une « catégorie » à chaque article de blog. Cela ressemble à une chose simple à ajouter. Mais si vous suivez toutes les bonnes pratiques typiques du développement web moderne, voici ce que vous devrez probablement faire :
- Écrivez une migration de schéma de base de données qui crée la nouvelle structure de catégorie de publication dans la base de données. Éventuellement, écrivez une migration "vers le bas" qui la supprime pour pouvoir annuler vos modifications rapidement si nécessaire.
- Mettez à jour vos définitions de structure Go, vos classes Java ou toutes les définitions de structure spécifiques au langage backend que vous utilisez, en conservant idéalement la compatibilité avec l'ancien et le nouveau schéma de base de données. Écrivez des tests unitaires backend pour les fonctions qui gèrent cette nouvelle structure de données.
- Écrivez de nouvelles requêtes de base de données et documentez les modifications dans vos réponses API.
- Mettez à jour les types TypeScript dans votre interface pour ajouter le nouveau champ, tout en conservant la possibilité d'analyser les réponses du backend avec et sans le champ. Écrivez des tests unitaires pour cette logique.
- Mettez à jour vos composants React pour afficher la catégorie de la publication.
- Assurez-vous que la validation des données pour la catégorie est cohérente sur toutes les couches.
- Rédigez un test d'intégration pour vous assurer que le nouveau code sur chacune des trois couches fonctionne correctement avec le reste du système.
- Synchronisez le déploiement des mises à jour entre le schéma de base de données, le backend et le frontend. Si plusieurs équipes travaillent sur le projet, assurez-vous qu'elles sont toutes sur la même longueur d'onde quant au moment et à la manière dont le déploiement aura lieu.
En fin de compte, ce qui n'est qu'une minuscule ligne de texte en haut des articles de blog pour les utilisateurs devient une tâche ardue, représentant des dizaines d'heures de travail d'ingénierie à mettre en œuvre.
Cette inefficacité s'étend aux utilisateurs finaux. Mélanger des octets entre plusieurs couches a un coût : latence du réseau, sérialisation et désérialisation des données, etc. Difficile de convaincre les gens qu'il est normal de charger un post sur Reddit, qui ne contient pas plus de quelques octets d'informations utiles, pour prendre des dizaines de secondes sur leur connexion 3G de vacances. Il est également difficile d'expliquer pourquoi nous ne pouvons pas faire quelque chose d'insignifiant pour l'utilisateur car cela prendrait trop de ressources.
Comment en est-on arrivé à l'architecture à trois niveaux ?
Yurii explique que ce modèle est né de la volonté d’optimiser la division du travail et de réduire la complexité des applications web, en permettant d’atteindre l’excellence dans chaque fonction spécialisée. Il reconnaît que ce modèle peut être adapté aux grandes organisations avec des équipes spécialisées, mais qu’il est contre-productif dans les petits contextes. Il souligne également que ce modèle entraîne des cycles de livraison plus longs à cause du surcoût de synchronisation et de communication entre les différentes parties du système.
Citation:
Envoyé par Yurii Rashkovskii
La spécialisation est excellente lorsque vous avez un tapis roulant. Cela implique que vos entrées et sorties sont stables, prévisibles et que votre timing est défini. Les petites organisations et les développeurs individuels peuvent ne pas avoir un tel luxe. Au lieu de cela, ils peuvent bénéficier de la capacité de réagir et de s'adapter plus rapidement. Ainsi, plus leur cycle d'expédition est court, mieux c'est.
Il a rappelé les solutions alternatives que les développeurs ont adoptées pour atténuer les problèmes du modèle à trois niveaux. Il cite notamment :
- Les outils no-code : des outils comme Budibase qui permettent de construire rapidement une application complète sans avoir à écrire de code. Mais ces outils sont souvent inflexibles et difficiles à maintenir sur le long terme. Ils ne sont pas adaptés aux applications qui doivent évoluer et grandir dans le futur sans avoir à être réécrites entièrement. Ils ne permettent pas non plus de bénéficier des avantages des logiciels modernes de gestion de version. De plus, peu d'outils no-code sont intéressés par le fait de faciliter la sortie de leur plateforme.
- Le backend as a service (BaaS) : des services comme Firebase qui fournissent des backends pré-faits et standardisés, qui suppriment une grande partie du travail de duplication sur la base de données et le backend et qui accélèrent considérablement le développement des applications. Cependant, ces services sont souvent conçus pour retenir leurs utilisateurs captifs. Ils rendent le développement local difficile. Ils rendent l'application moins autonome et plus coûteuse à héberger, déployer et maintenir. Beaucoup de ces BaaS finissent par être abandonnés ou rachetés, obligeant tout le monde à réécrire leur code pour utiliser autre chose. Et même quand tout se passe bien avec le fournisseur, il faut quand même gérer la synchronisation entre le frontend et le BaaS.
- Les serveurs web database-over-HTTP : des outils comme PostgREST et Hasura GraphQL qui exposent une base de données sur HTTP. Ils réduisent énormément le travail des développeurs sur le backend, tout en étant assez légers, faciles et peu coûteux à déployer. Mais ils ne résolvent qu'une partie du problème. Leur objectif n'est pas d'être une approche suffisante pour construire une application complète, et ils nécessitent toujours de passer du temps à synchroniser le code du frontend et la structure de la base de données. On ne peut pas faire grand-chose de plus pour répondre à une requête web que de représenter le contenu de la base de données tel qu'il est, sans traitement, mais en JSON.
Mais Yurii n'est pas satisfait des solutions existantes
Citation:
Nous considérons toutes les solutions mentionnées ci-dessus comme des pas dans la bonne direction, mais nous ne sommes toujours pas satisfaits de l'état des outils de développement rapide d'applications. Nous pensons qu'il est non seulement possible, mais même probable que dans un avenir proche, la création d'une application complète prête pour la production demandera dix fois moins d'efforts qu'aujourd'hui. Et plutôt que d'attendre que l'outillage du futur arrive, nous nous unissons et créons ces outils aujourd'hui, pour faire de cette vision une réalité. Nous ne prétendons pas encore avoir trouvé la réponse définitive au problème du triple travail, mais les projets sur lesquels nous travaillons réduisent déjà considérablement le temps qu'il faut pour passer d'une idée à une application Web fonctionnelle aujourd'hui sans sacrifier la facilité du développement collaboratif et la rapidité de déploiement.
Il a cité notamment un outil sur lequel le développeur Ophir Lojkine travaille : « Ophir travaille sur SQLPage, un cadre de développement d'applications rapide basé sur SQL qui rend la création d'applications Web graphiques aussi simple que l'écriture d'une requête de base de données. SQLPage offre une solution indépendante de la base de données sans aucune dépendance. Avec SQL comme base, vous pouvez créer une application Web complète en une seule journée ».
Et Omnigres, un outil sur lequel lui-même il travaille : « conçu pour des applications plus importantes, Omnigres simplifie le développement d'une logique backend complexe qui s'exécute directement dans une base de données Postgres. Il transforme Postgres en une plate-forme d'application back-end complète ».
Source : billet Yurii Rashkovskii
Et vous ?
:fleche: Quelle lecture en faites-vous ?
:fleche: Que pensez-vous u modèle d’architecture logicielle à trois niveaux ? Quels sont les avantages et les inconvénients selon vous ?
:fleche: Avez-vous déjà utilisé des outils no-code, BaaS ou database-over-HTTP pour développer des applications web ? Si oui, quels sont vos retours d’expérience ?
:fleche: Quelles sont les caractéristiques que vous recherchez dans un outil de développement rapide d’applications ? Quels sont les outils que vous utilisez ou que vous aimeriez utiliser ?
:fleche: Que pensez-vous des projets SQLPage et Omnigres présentés par les auteurs ? Quelles sont les questions ou les suggestions que vous leur feriez ?
Comment voyez-vous l’évolution de l’architecture logicielle dans le futur ? Quels sont les défis et les opportunités que vous anticipez ?
1 pièce(s) jointe(s)
3 solutions au problème des 3 couches : éliminer la complexité accidentelle et la duplication des efforts
Trois solutions au problème des trois couches : le développeur Ophir Lojkine propose d'éliminer la complexité accidentelle et la duplication des efforts
en choisissant la technologie adaptée à chaque problème
Citation:
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.
Bonjour à tous,
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.
Pièce jointe 642333
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.
