Merci pour cet article très intéressant. Je me suis posé récemment le même type de questions en cherchant un backend léger et sûr (du point de vue typage) pour des frontends écrits en Elm. Et en étudiant des architectures de backend, j'avais l'impression qu'entre la BD et la partie ORM du backend, il y a souvent beaucoup de redite.
Je suis alors tombé sur des projets (l'un en haskell) PostgREST et (l'autre en JS) Graphile, selon que l'on préfère les architectures REST ou GraphQL.
Je ne connaissais pas cette solution purement SQL, mais je trouve intéressant d'explorer les capacités de gestion des données directement par le SGBD, plutôt qu'en faisant (ou refaisant) les choses côté backend. Forcément, l'approche a ses limites : il faut souvent recourir à des notions de workers ou autre pour certaines actions... Mais le SGBD est bien souvent capable de réaliser des optimisations difficilement envisageables avec une couche ORM, pour peu qu'on décrive précisément ce qu'on souhaite faire.
J'apprécie beaucoup le côté déclaratif de SQL, qui sous-traite (généralement de manière assez efficace) au moteur du SGBD le soin de trouver le meilleur schéma d'exécution. Et, quand ce n'est pas le cas, c'est une très bonne occasion de se poser quelques questions sur la représentation/normalisation de nos données, et de réfléchir à l'utilité de créer tel ou tel index, vue matérialisée, etc.
Bref, quel est alors le lien avec le langage Elm, aucun, sinon un jeu de mot franco-anglophone qui me démangeait pour le titre de mon commentaire.
# Morts aux ORM, vive ELM
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Écrire une appli web en une journée avec SQLPage. Évalué à 6.
Merci pour cet article très intéressant. Je me suis posé récemment le même type de questions en cherchant un backend léger et sûr (du point de vue typage) pour des frontends écrits en Elm. Et en étudiant des architectures de backend, j'avais l'impression qu'entre la BD et la partie ORM du backend, il y a souvent beaucoup de redite.
Je suis alors tombé sur des projets (l'un en haskell) PostgREST et (l'autre en JS) Graphile, selon que l'on préfère les architectures REST ou GraphQL.
Je ne connaissais pas cette solution purement SQL, mais je trouve intéressant d'explorer les capacités de gestion des données directement par le SGBD, plutôt qu'en faisant (ou refaisant) les choses côté backend. Forcément, l'approche a ses limites : il faut souvent recourir à des notions de workers ou autre pour certaines actions... Mais le SGBD est bien souvent capable de réaliser des optimisations difficilement envisageables avec une couche ORM, pour peu qu'on décrive précisément ce qu'on souhaite faire.
J'apprécie beaucoup le côté déclaratif de SQL, qui sous-traite (généralement de manière assez efficace) au moteur du SGBD le soin de trouver le meilleur schéma d'exécution. Et, quand ce n'est pas le cas, c'est une très bonne occasion de se poser quelques questions sur la représentation/normalisation de nos données, et de réfléchir à l'utilité de créer tel ou tel index, vue matérialisée, etc.
Bref, quel est alors le lien avec le langage Elm, aucun, sinon un jeu de mot franco-anglophone qui me démangeait pour le titre de mon commentaire.