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.

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 :

1. 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.
2. 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.
3. 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

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