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.
[...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par Nb
