Discussion :

[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 ?