Waarom ORM niet je beste gok zou moeten zijn

Toen ik een paar jaar geleden begon met programmeren, was ORM als het levensbloed van softwareprojecten. De omgeving benadrukte de nauwe koppeling tussen de codebasis en de ORM-laag. Er kan worden gezegd dat ik werd opgeleid om niet aan projecten zonder een ORM te denken.

Maar toen ik ervaring en diepere kennis van specifieke projecten opdeed, realiseerde ik me dat de meeste verbeteringen uiteindelijk het punt bereiken waarop de stroom het ORM-raamwerk binnenging. Toen vroeg ik me af: wat als dit project geen ORM had?

Ik begon na te denken over de problemen die ORM had geïntroduceerd:

  • Je kunt je code niet optimaliseren, zelfs als je echt die extra snelheid nodig hebt; ORM-code leeft in een eigen land.
  • Zicht op wat er gebeurt is minimaal.
  • De documentatie is meestal enorm en gefragmenteerd waardoor het moeilijk is om naar details te zoeken.

Dit klinkt misschien als kleine problemen, maar ze schaden de productiviteit aanzienlijk. Afgezien hiervan realiseerde ik me dat het ORM-ecosysteem los staat van de reguliere webontwikkeling met zijn eigen problemen en beperkingen. ORM's brengen over het algemeen onnodige complexiteit met zich mee en bieden "lekkende abstractie" over database-interacties. Ze hebben soms een steile leercurve en ontwikkelaars hebben de neiging ze te behandelen als een blackbox.

Ik heb ontwikkelaars verschillende benaderingen zien nemen om het ORM-probleem aan te pakken. Sommigen verwijderen ORM-frameworks volledig, wat vaak een enorme taak is, afhankelijk van de complexiteit van het project. Sommigen accepteren ORM en passen code in hun project aan; ze zijn klaar om in te leveren op de prestaties en geven niet om de extra complexiteit. Velen van hen kiezen het gouden pad waar ze de ORM blijven gebruiken, maar nieuwe of complexe zoekopdrachten zijn uitgesloten. Sommigen van hen maken eigenlijk hun eigen kaartlaag die specifiek is voor het project en volgens de behoefte.

Tot nu toe heb ik gewerkt met Hibernate (Java) en Mongoose (ORM-framework in Node voor MongoDB). Toen ik bij een Node-project kwam dat Mongoose al als ORM gebruikte, had ik de monumentale taak om bijna het hele project te refactoren. Eerst dacht ik erover om het ORM-raamwerk helemaal te verwijderen. Maar mijn collega's zouden niet tevreden zijn zonder cijfers die me steunen. Dus ik benchmarkde de vraagtijd met en zonder Mongoose. Hier zijn de resultaten.

Ze hebben me verrast. Ik had een prestatieverbetering verwacht als ik Mongoose niet gebruikte, maar niet in die mate. Met deze gegevens in de hand was de keuze duidelijk: ORM was uit. Een paar maanden later vroeg een collega me of ze Sequelize of Pg moesten gebruiken om toegang te krijgen tot een Postgres-database. Omdat ik besefte dat Sequelize een ORM was, gaf ik mijn stem aan Pg, maar vroeg hem om de twee te benchmarken. Ik wilde controleren of de ORM-haat gerechtvaardigd was en toen de cijfers eenmaal terugkwamen, bleek dat het inderdaad volledig gerechtvaardigd was.

Raad eens met welke bibliotheek hij verder ging.

Een ding om te onthouden is dat toen we ORM's opgaven, Mongoose of Sequelize, we wisten wat het was dat we opgaven. Specifiek schema-controle, vooraf gebouwde methoden, abstracties etc. waren de voordelen van het gebruik van een ORM-framework. Een grote zorg was het ontbreken van schema-controle (wanneer geen ORM's worden gebruikt), iets dat zou kunnen leiden tot slechte gegevensinvoer in de DB. Om dit te omzeilen hebben we Joi gebruikt, wat onze taak eenvoudiger maakte en de prestaties intact hield. Voor andere delen moesten we een paar regels extra code schrijven, maar het was het waard. Beter dat dan bij elke zoekopdracht tientallen milliseconden (soms zelfs seconden) verliezen.

Ik probeer geen ORM's te bashen en ze zijn echt goed voor beginners en kleinschalige projecten. Maar wanneer uw project schaalt naar een groot aantal query's en documenten, kunnen ORM's een knelpunt worden. Beschouw ze als de oorlog in Vietnam, je moet beslissen wanneer je terugtrekt en wegloopt, anders is grote schade onvermijdelijk.