To ORM or not to ORM?

[borgue95]

N'utilitzem un, o no?

Avantatges:

• Ens abstraiem de la base de dades que utilitzem
• Redueix el nombre d'errors
• Suporta consultes personalitzades
• Tècniques contra la injecció d'SQL quan s'utilitzen dades de l'usuari
• Migracions senzilles

Desavantatges:

• Si s'elimina o es canvia de nom una entitat, no queda reflectit a la base de dades; queda una taula perduda sense ús o se'n crea una de nova amb el nou nom, deixant-ne una d'òrfena.
• Limitacions d'emmagatzematge pels tipus més reduïts de dades
• Possibles problemes de rendiment
• No pot competir amb consultes complicades envers SQL
• Baixada de productivitat pels desenvolupadors
• Es perd el sentit de què s'està fent amb una consulta ORM envers una d'SQL

A veure, ara anant al nostre projecte.

Llegint crítiques per internet, un ORM és genial per projectes petits i senzills perquè de seguida es tenen els accessos a la base de dades. Un ORM sí que permet fer consultes complexes, però s'ha d'acabar mirant quina consulta SQL genera, si és correcte, etc. Cosa que desvirtua l'ús d'un ORM pel fet d'haver de revisar codi SQL.

La nostra web, em temo jo, tindrà consultes prou complexes. Els tipus de dades que hem escollit ja estan lligats a PostgreSQL. Sabent que tu (@albertms10) et sents més còmode i que jo també m'hi sento picant consultes SQL, no veig l'avantatge d'utilitzar un ORM.

Tanmateix, hi ha dues coses que em preocupen, ja que no he treballat prou amb SQL: la protecció contra injeccions i les migracions.

En Python, tal com ho faig ara en alguns projectes, hi ha un binding entre SQLite i Python, de manera que puc realitzar una crida i em retorna les dades en una llista de diccionaris. Això sí, aquest binding no és pas un ORM; és només un connector per utilitzar la base de dades des del codi i no des d'una consola. Si això està disponible per NextJS, seria genial.

Pel que fa a la protecció contra injecció de codi SQL, haurem d'investigar com fer-ho manualment o si hi ha alguna llibreria que ens permet utilitzar les dades de l'usuari sense patir. I pel que fa a les migracions (canvis en l'esquema de la base de dades), no sé com es fan; fins ara m'ha anat bé fer cirurgia, obrint la base de dades, fent un alter table, i seguir endavant. De tot plegat no tindrem, pròpiament dit, releases. És un producte que evoluciona i no té sentit que es quedi estancat en un estat. Així que no crec que sigui un problema massa gran.

Seguim pensant

[borgue95]

Load balancing dels ORM (caching, etc). Un tema interessant que de moment podem no tenir en compte. L'afluència d'usuaris a la web serà baixa. Tant de bo ens hi hàgim de posar.

[borgue95]

Pel que fa a l'accés directe, cito algunes referències per a una futura investigació:

• https://www.reddit.com/r/nextjs/comments/11acgp1/where_should_i_setup_my_database_connections/
• https://github.com/vercel/next.js/tree/canary/examples/with-postgres (lib/db.ts)

[albertms10]

Pel que fa a la protecció contra injecció de codi SQL, haurem d'investigar com fer-ho manualment o si hi ha alguna llibreria que ens permet utilitzar les dades de l'usuari sense patir.

Sobre la injecció de codi de l'usuari no patiria pas, ja que si decidim fer-ho a la mateixa infrastructura de Next.js, podem (o més ben dit, hauríem de) dependre de ts-postgres, una llibreria ben completa, mantinguda i documentada.

Tanmateix, comparteixo parer pel que fa a la resta de punts: sense ORM, sense migracions. I anem veient si ens hi sentim còmodes.

[borgue95]

Resolem el següent:

Not to ORM.

Utilitzarem el que es diu a https://github.com/acorgue/web/issues/9#issuecomment-2062522800.