Discussion :

[Stéphane le calme]

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.

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

Et vous ?

Quelle lecture en faites-vous ?
Que pensez-vous u modèle d’architecture logicielle à trois niveaux ? Quels sont les avantages et les inconvénients selon vous ?
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 ?
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 ?
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 ?

[Nb]

Vu qu il croie que les applications en couches (peut importe le nombre) ont émergé pour gerer la complexité des appli web et bien je pense qu il a encore du chemin à parcourir.

[psykokarl]

L'architecture trois couches répond tout simplement à une problématique redondante en développement logiciel. Lorsque l'on bosse avec deux briques logicielles différentes, il faut faire du code "glu" pour qu'elles fonctionnent ensemble.

Si on reprend l'exemple du web suscité, on a :

• un server/client HTTP qui lit la requête HTTP.
• un server/client SQL qui lit de la requete SQL.

Il faut donc écrire du code "HTTP2SQL/SQL2HTTP" dans le langage de son choix. Une manière d'aborder le problème et de le découper en trois parties (ou couches).

• conversion du HTTP vers mon langage
• ajustement dans le cas ou il n'y a pas de "bijection" entre la partie HTTP et la partie SQL
• conversion de mon langage vers le SQL

Ces couches étant parcourues dans un sens ou dans l'autre en fonction de si on traite une demande ou de si on génère une réponse.

Que pensez-vous des projets SQLPage et Omnigres présentés par les auteurs ?

Ils peuvent avoir leur utilité dans le scope couvert par leurs applications. Dès que l'on abordera des cas d'utilisation non prévu ou tout simplement que l'on aura besoin de faire glu avec d'autres protocoles que HTTP ou SQL, les limites seront atteintes.

[foetus]

Vu qu il croie que les applications en couches (peut importe le nombre) ont émergé pour gerer la complexité des appli web et bien je pense qu il a encore du chemin à parcourir.

L'architecture trois couches répond tout simplement à une problématique redondante en développement logiciel. Lorsque l'on bosse avec deux briques logicielles différentes, il faut faire du code "glu" pour qu'elles fonctionnent ensemble.

Sérieusement:

Le modèle MVC, Modèle-Vue-Contrôleur existe depuis 1990 (wiki me dit 1980) … je parle du modèle *théorique* (parce que les variantes il en existe pleins)
Avec 1 application Web, contrôleur s'appelle + ou - "Business Layer", ORM pour la glue et la vue c'est le "front" (avec pleins de termes DAL, DAO, DTO, …)
Après je ne sais plus où se trouve le module pour parser les requêtes/ chemins/ …

Parce que l'avantage du MVC, c'est l'abstraction et chacun travaille séparément (il faut juste *normer* les échanges):

• La vue et le contrôleur reçoivent/ font faire stocker des données, mais ils s'en fichent que ta base soit SQL ou NoSQL, soit en local ou en ligne, … qu'il y a même 1 base.
• Le modèle lui reçoit ou stocke des données, mais il s'en fiche s'il les donne à 1 "front-end" ou 1 application mobile Android/ iPhone
• ...

[psykokarl]

Sérieusement:

Oui sérieusement...

Déjà pour commencer il ne faut pas confondre architecture à couche et architecture MVC.
Le MVC permet d'implémenter une architecture à couche mais ce n'est pas le seul pattern à le permettre. Le MVVM et les architectures dit à micro-service le peuvent également.
Le MVC n'a pas été créer pour le web à la base mais pour des applications graphiques. A l'origine l'architecture web est sans état. Puis on a essayé de calquer le MVC dessus avec les possibilités offerte par le bases de données et les techno front. Puis ça a été remis partiellement en cause avec l'émergence du REST et des architectures distribuées types microservices, AUTH2, etc.

Le Business lawyer est une architecture orienté business. On ne fait pas que du e-commerce sur le web. Il n'y a pas besoin d'implémenter règle métier pour un blog ou pour un jeux vidéo.

Après je ne sais plus où se trouve le module pour parser les requêtes/ chemins/ …

Dans une architecture MVC, c'est géré par le contrôleur. On peut cela dit faire gérer la chose par un "middleware" voir pourquoi par un service. On sort alors du MVC mais on reste dans reste dans l'architecture à couche.

[Anordem]

...Le modèle MVC, Modèle-Vue-Contrôleur existe depuis 1990 (wiki me dit 1980)...

Je pense que tu es hors sujet. L'article parle d'architecture 3-tiers, ce qui n'a rien à voir avec le pattern MVC. Certes aujourd'hui la frontière est floue entre les couches, vu que les SGBD proposent maintenant des API directement utilisables par une application front, au détriment de la couche métier qui disparaît dans des fonctionnalités CRUD. Mais on ne peut pas parler d'architecture n-tier avec MVC. Cela ne s'applique pas au même problème, ni au même contexte.

L'auteur expose un problème pour venter la supériorité de son produit. Bref, rien de nouveau dans le monde merveilleux de l'IT...

[psykokarl]

L'auteur expose un problème pour venter la supériorité de son produit. Bref, rien de nouveau dans le monde merveilleux de l'IT...

En fait l'auteur cite le projet d'un autre développeur, à savoir Ophir Lojkine. Le nom m'est assez familier vu que j'ai forker/améliorer son projet de conversion odt to html ... il fut un temps. Il semblerait qu'il soit passé sur Rust.
Enfin bref, ici n'est pas le lieu ou parler technique

[walfrat]

Sérieusement:

Le modèle MVC, Modèle-Vue-Contrôleur existe depuis 1990 (wiki me dit 1980) … je parle du modèle *théorique* (parce que les variantes il en existe pleins)
Avec 1 application Web, contrôleur s'appelle + ou - "Business Layer", ORM pour la glue et la vue c'est le "front" (avec pleins de termes DAL, DAO, DTO, …)
Après je ne sais plus où se trouve le module pour parser les requêtes/ chemins/ …

Parce que l'avantage du MVC, c'est l'abstraction et chacun travaille séparément (il faut juste *normer* les échanges):

• La vue et le contrôleur reçoivent/ font faire stocker des données, mais ils s'en fichent que ta base soit SQL ou NoSQL, soit en local ou en ligne, … qu'il y a même 1 base.
• Le modèle lui reçoit ou stocke des données, mais il s'en fiche s'il les donne à 1 "front-end" ou 1 application mobile Android/ iPhone
• ...

En vrai je pense que c'est un peu plus compliqué :

• Si tu prend la bonne vielle page php sans JS, ta vue c'est le HTML que tu pisses, ton contrleur, c'est tes if etc, et ton model c'est ton modèle logique ou / et physique
• Si tu prend un site Web en mode plus récent ou des données sont chargés via JS puis le HTML est construit : tu as forcément une vue serveur (modèle de données) et une vue client (IHM). Même si ton MVC n'est pas bien séparé.

Pour moi le sujet est donc vraiment sur le fait d'avoir trois composant "physique" : frontend/backend/stockage physique.

Oui ça inclus de la redondance et quand tu te tape tout solo c'est casse couille d'écrire potentiellement trois/quatre fois le même modèle de façon différente : après rien ne t'y oblige, j'ai déjà fait une appli Web avec comme modèle de données mon entité ORM, cela passait car je n'avais pas de complexité par dessus qui faisais que j'avais besoin d'un modèle séparé.

Si tu fais des trucs de plus petites envergures, tant que tu stockes le moindre trucs distants, je comprend pas comment t'es censé te passe du backend et du stockage physique. En revanche tu peux simplifier :

• Est-ce que t'as vraiment besoin d'une base de données SQL ? Est ce qu'un reddis vite fait ne fait pas l'affaire ?
• Tu peux choisir de plutôt que tout bien séparer et abstraire, avec toute la redondance que cela implique, rester sur des éléments plus simples, mais en revanche plus inter-dépendant du moindre changement que tu feras.

D'ailleurs si on veut encore parler histoire, il fut un temps ou l'on faisait des clients lourds directement connecté au SGBD central, à priori la pratique n'existe plus que dans les applis legacy de l'époque. On a depuis systématiquement mis un serveur devant la BDD. N'étant pas de l'époque je connais pas le fin mot de l'histoire mais j'imagine qu'il y a une bonne raison à cela.

Il y a quelque chose qui m'interpelle : le gars lui-même dit qu'il n'existe aujourd'hui aucune solution satisfaisante. De fait, j'ai l'impression que c'est juste une façon élégante de râler.

Enfin si je prend le paragraphe suivant :

É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.

Moi ce que je vois la dedans, c'est avant tout des éléments auxquels tu peux pas échapper, sauf générateur de code, mais je préfère largement le taper moi-même, sinon je vis des éléments qui sont simplements ce qu'on fait quand on fait un truc professionnels, qui doit être donc bien gérer et stable quand tu déplois.

En vrai t'es pas "obligé" de faire comme ça, pour obtenir un retour utilisateur sur une nouvelle innovation. Tu peux chercher des utilisateurs qui acceptent de passer du temps sur des versions alphas/betas, donc pas mature, qui permet déjà de voir/tester des fonctionnalités que t'as pas encore "durci" (test unitaire, validation de formulaire stricte, migration de schéma up/down blindé etc etc). Et évidemment tu le ferais sur des instances de sites dédiés aux tests. Mais ça suppose que tu as une communauté d'utilisateurs suffisamment engagés qui accepte de consacré du temps à discuter activement des devs en cours voir des idées avant même que des devs commencent. StackExchange est un bon exemple, avec les limites que ça imposes, il y a plein de discussions sur ce qui vaut le coup ou pas, mais aussi plein d'éléments qui sortent tellement longtemps après parce que l'équipe de développement/validation ne peut pas tout faire et que quand tu sors un truc en prod sur un truc aussi énorme, il faut forcément blinder, et ça prend beauuuucoup de temps.

En bref : si t'es trop petit, tu auras pas la communauté ni le budget illimité pour faire que innover, si t'es trop gros, ton service est tellement utilisé par tellement de personne, que tu peux dois blinder, et donc ça limite ce que tu peux ajouter.

Autre exemple pertinent : Google, ils en ont sorti plein de trucs "innovant" tous n'ont pas marché (c'est normal) mais faut avoir des reins solides pour se permettre de sortir des sites web complets au grand public et "voir si ça trouve son public".

[AoCannaille]

Le MVC rend plus facilement maintenable les application pour les évolution qui ne concernent qu'une seule couche, et complexifie celles qui en impactent plus.

J'ai l'impression que ce développeur essaye de justifier maladroitement le droit de faire du quick and dirty.

C'est lui qui voit, ce sont ses applications.

[walfrat]

Les trois couches répondent à trois problème différents :

• frontend : présenter à un utilisateur les données et les permettre de les manipuler
• backend : logique applicative, authentification, sécurité etc.
• base de données : modèle de sauvegarde physique de stockage de nos données.

A partir du moment où ce que tu fournis comme site web/application n'est pas censé sauvegardé les données en local mais à distance ,il faut forcément ces trois composants, et franchement je vois pas où est le problème avec ça.

Pour moi ce qui complexifie tout ça c'est que quand tu fais un truc pour un client, il va t'ouvrir sa suite Word son Gmail et va te dire qu'il veut un truc qui est aussi bien fait, du drag & drop, du copier/coller (et le Workflow des données dans tout ça??) etcetc. Côté backend, il faut que ce soit sécurisé, que tu supportes le SSO etc etc, côté BDD : bah surtout bien gérer les transactions et garder de bonnes perfs + migrations de schema.

Ah oui et faut que tout soit "reversible", et inclus dans le cout de base, c'est pas drôle sinon.

[Zulut]

L'auteur cherche à remplacer/améliorer le modèle courant 3 tiers et je trouve ça plutôt cool. Pour ma part, ce que ça m'inspire:

- le modèle n-tiers est déjà nickel pour moi, ajouter une fonctionnalité ne me demande pas plus d'efforts qu'avec du no-code ou autre, au regard de la valeur ajoutée par celle-ci

- c'est vrai que ça augmenterait la cohérence d'avoir par exemple des "component" regroupant les 3(ou n) aspects d'une fonctionnalité, à l'image des composants mvc, webcomponent, etc... M'enfin c'est un vieux sujet, et il y a déjà beaucoup de framework promettant de simplifier le code. On arrive dans l'effet de mode...

[Nym4x]

L’architecture MVC n’est pas 3 tiers (data, business et présentation pouvant inclure MVC). Le MVC et 3 tiers sont faits pour des web applications exposant potentiellement une api et non pour des blogs ou de simples sites. Pour les cas plus simples comme un blog il existe wordpress, drupal et d’autres modèles comme MVVM ou asp.net Razor Pages.

[yahiko]

J'ai quand même l'impression que cela fait un moment que l'industrie du logiciel a conscience du tort qu'à fait le modèle MVC aux applications.
La Clean Architecture est une solution élégante et relativement efficace du point de vue de la mise en œuvre, et répond à la fois à la problématique du couplage et de la redondance du modèle tel qu'évoqué dans l'article.
Dommage que l'auteur n'en parle pas et que pour palier les inconvénients du MVC, il sous-entend utiliser la méthode R.A.C.H.E.

[Zulut]

Je trouve que cette approche Database-first a l'avantage de la simplicité, souvent gage de qualité. Elle permet un développement rapide sur une seule couche. Pour autant, l'idée d'un mapping automatique s'appuyant sur du sql est ancien et plus ou moins abandonné (voir Access), ce qui me fait me poser la question : est-ce judicieux de s'appuyer sur du sql?

L'inconvénient que je vois est le manque d'evolutivité, maintenabilite et reutilisabilité par rapport à une approche objet (design patterns VS stockage des fichiers SQL...)

Ne serait il pas envisageable d'avoir une approche object-first simplifiée au maximum? avec par exemple uniquement des pojo java accompagnés de mappings ou annotations simples (style orm et gui)? L'avantage évident serait un meilleur design, tout en permettant un développement rapide sur une seule couche (objet).

Cependant, je suis d'accord pour dire que l'approche database first est plus concise car elle évite d'avoir une couche intermédiaire objet.

Au final, les 2 approches me plaisent bien même si, dans un context d'application simple, j'ai tout de meme une légère préférence pour celle qui me permet une plus grande créativité (car on sait jamais, l'application simple peut grandir! &#128513

[psykokarl]

L'inconvénient que je vois est le manque d'evolutivité, maintenabilite et reutilisabilité par rapport à une approche objet (design patterns VS stockage des fichiers SQL...)

L’inconvénient vient principalement du manque de connaissance du langage SQL et de la confusion générale entre le langage (le SQL) et le moteur de stockage/recherche qui tourne en arrière plan (qui pourrait être n'importe quoi). Niveau évolutivité, maintenabilité, évolutivité, le SQL propose avant tout de restituer les données demandées, sous la forme demandée. Le SQL est quasiment le langage le langage de mapping ultime.
Le problème du SQL est qu'il ne permet pas réellement de choisir l'algo de stockage et/ou de recherche et encore moins de le créer. Les techniques d'optimisation de recherches sont peu élégantes, ce qui ne manquera pas d'en rebuter. Les algos qui tournent en arrière fond ne sont pas forcément pertinent pour le type d'utilisation souhaité. Cela explique intérêts pour les SGBD non relationnel.

[walfrat]

Et bien tout d'abord, merci pour ce retour de message, on se voit bien confirmer que le MVC n'était pas le sujet central de la discussion.

Je pense qu'il y a un petit manque de recul déjà sur pourquoi une grosse majorité fait comme cela aujourd'hui ? A savoir trois couches chacunes une part de développement importante malgré le découpage en responsabilité.

Je veux dire par là : faire une application avec une IHM légère, c'est ce qu'on faisait dans les années 2000 avec principalement du PHP qui pissait du HTML.

Je vois plusieurs éléments de réponses :

• Des exigences accrus en matières d'ergonomies
• Des exigences accrus en termes de temps de réponses de l'application
• Des exigences accrus en termes de sécurité
• Les gros : GAFAM, Deezer , Spotifity qui y vont tous de leur bonne recommandant sur comment ils ont fait.

Sur l'ergonomie : cela limite l'utilisation d'application type PHP/HTML/CSS et peu de JS comme à l'époque car il faut des composant graphiques beaucoup plus riche.
Sur les temps de réponses : cela tend à diminuer le volume globale d'échange entre le client et le serveur a profit d'une API plus riche et détaillée pour chaque opération, ce qui fait donc "grossir" le code du client et du serveur.
Sur la sécurité : cela complexifie et fait encore une fois gonfler le code a tous les niveaux.
Les gros : Les conseils qu'ils donnent sont réel et efficaces, mais il faut comprendre qu'ils font des sites web pour des millions de personnes, et donc pour cela, il faut encore potentiellement complexifier et grossir le code du client/serveur pour le supporter correctement.

Pour savoir quoi faire ou pas, il faut donc déjà que le développeur comprenne quel sont les exigences sur son applications: s'il y a un gros besoin en ergonomies, il n’échapperas sans doute pas à un frontend riche.
Sur le côté performance, beaucoup de conseils de ces dernières années sont tournés vers le mobile, si tu en fais, c'est cool t'as plein de conseils lié à ça, si ton projet n'est clairement pas adressés aux mobiles, il faut faire la part des choses pour ne pas complexifier le code inutilement.

Là où je coince sur les solutions avancés dans cet article c'est notamment sur les exigences de sécurités : si on considère que la "petite équipe" ou "développeur seul" va devoir faire un site web exposé sur internet, tu vas forcément te retrouver avec une couches d'authentification/sécurité et d'ergonomies (parce que tu peux pas vraiment faire un truc style années 90 en termes d'ergonomies aujourd'hui pour les utilisateur) et du coup tel que c'est exposé ici dans l'article je ne vois que la catégorie des applis avec du templating côté serveur qui peut faire potentiellement l'économie d'un frontend riche.

[psykokarl]

Là où je coince sur les solutions avancés dans cet article c'est notamment sur les exigences de sécurités : si on considère que la "petite équipe" ou "développeur seul" va devoir faire un site web exposé sur internet, tu vas forcément te retrouver avec une couches d'authentification/sécurité et d'ergonomies (parce que tu peux pas vraiment faire un truc style années 90 en termes d'ergonomies aujourd'hui pour les utilisateur) et du coup tel que c'est exposé ici dans l'article je ne vois que la catégorie des applis avec du templating côté serveur qui peut faire potentiellement l'économie d'un frontend riche.

Je vois la chose comme une interface graphique SQL, un peu comme le propose un phpMyAdmin, mais d'avantage orienté utilisateur final que administrateur :

• une interface graphique plus sexy, légèrement customisable.
• des droits d’accès en lecture/écriture géré par le SGBD
• utilisation systématique de vue/tables virtuelles
• utilisation systématique de procédure stockées
• génération de code automatique niveau back : repository, DTO avec les types basés sur le schema bdd (nom procédure stockée, nom de table, type des colonnes, etc => donc pas de redondance).
• proposition d'une api qui va bien.
• etc...

Il y a matière a faire pas mal de chose. Les questions que je me poserai tourneraient d'avantage de la scalabilité, de la gestion des requetes en asynchrone, etc, qui devront probablement être géré par le backend de toute façon.
La techno est présentée comme un outil pour développeur solo, ou une très petite équipe. Je ne vois pas le développeur solo créer un site à fort traffic. Ça peut faire le boulot pour un outil interne, pas forcément en ligne, si il fait fait bien ce qu'on lui demande.
Il y a même moyen que le projet soit repris pour des sites à fort traffic dans un second temps. Si l'aspect bdd est gérée de façon optimale des outils backend seront développés pour gérer les limitations de l'outil.

[gayepej]

Les questions que je me poserai tourneraient d'avantage de la scalabilité, de la gestion des requêtes en asynchrone, etc, qui devront probablement être géré par le backend de toute façon.

Pour le passage à l'échelle, il y a plusieurs aspects à prendre en compte:

• La performance. Pour cela, il n'y a pas vraiment à s'inquiéter. SQLPage est écrit en rust, et on peut compter sur un gain de performance d'au moins ~10x par rapport à quelque chose écrit à la main en python, par exemple. SQLPage propose en plus une version serverless, pour un passage à l'échelle horizontal quasiment infini à très faible coût.
• La sécurité et la gestion des permissions. La plupart des questions de sécurité de base ne se posent pas vraiment avec SQLPage, et on peut utiliser le composant authentification pour gérer les permissions.
• La gestion de la complexité. Ici, je conseillerais de passer sur d'autres technologies progressivement, en gardant la même base de données, au fur et à mesure que les besoins en interface graphique et en logique métier se complexifient et deviennent difficile à gérer en SQL avec les composants fournis par SQLPage. Comme l'outil n'impose pas de structure de base de données, il joue très bien avec n'importe quel autre backend qui se connecte à la même base de données. Et pour le frontend, on peut commencer par développer un composant react à l'intérieur de SQLPage avant de migrer vers un front entièrement en javascript, par exemple.

[Aspartame]

Et Omnigres, un outil sur lequel lui-même il travaille

...

ceci explique cela non ?