par John Vandivier

REMARQUE: Mai 2018: Lire de TypeORM à LoopBack: Une rétrospective pour une perspective mise à jour!

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Cet article passe en revue les solutions de Mappage relationnel Objet (ORM) dans l’écosystème JavaScript et identifie une solution idéale en fonction d’exigences spécifiques.

Qu’est-ce qu’un ORM et pourquoi est-il si important ?

Les solutions ORM sont utiles pour faciliter le développement d’API basées sur les données. Les utilisateurs ont des besoins concrets qui animent le modèle de données d’une application. Dans le développement hérité, cette architecture de données est généralement implémentée et contrôlée en version à l’aide de scripts de base de données tels que des scripts SQL. Une bibliothèque distincte est ensuite utilisée pour que l’application serveur exécute des actions CRUD sur la base de données.

Les ORM fonctionnent comme une API de haut niveau pour exécuter CRUD, et de nos jours, les ORM de qualité nous permettent également d’initialiser les données via du code. La manipulation de données complexes, le nettoyage, etc., est souvent plus facile dans le code. Bien qu’il existe des outils d’extraction, de transformation et de chargement (ETL) dédiés, les mêmes tâches ETL peuvent être facilement implémentées dans ORM.

La mise en œuvre de l’extraction, de la transformation et du chargement avec du code permet à un système d’intégrer plus facilement des données provenant de sources très différentes. Les bases de données SQL de plusieurs saveurs, les données NoSQL, les données du système de fichiers et les données tierces peuvent toutes être intégrées dans un seul langage avec un ORM JavaScript.

Enfin, le contrôle des données orienté code permet également à un système de mettre en œuvre l’utilisation des données au moment de l’exécution ou dans le processus de construction, et d’adapter l’utilisation de manière flexible pendant le processus de développement selon les besoins.

Pour reformuler, les ORM améliorent la productivité des développeurs en fournissant une API de haut niveau, dans un seul langage, avec des fonctionnalités qui nécessiteraient traditionnellement plusieurs outils et ensembles de compétences différents. Moins de besoins en compétences, d’outils et d’heures nécessaires facilite la marge du projet. Les exigences imprévues et le calendrier du projet sont mieux préparés grâce à une configuration flexible des données de génération et d’exécution.

Capacités ORM préférées

Le contexte particulier du projet menant à cette révision ORM nécessite la mise en œuvre d’une application JavaScript universelle de pointe, de type CMS.

Les frameworks JavaScript universels de pointe sont disponibles en 3 versions : Angular, React et Vue. C’est-à-dire Angular Universal, Next et Nuxt.

Node prend en charge nativement les opérations du système de fichiers, de sorte que les exigences en matière de données du système de gestion de contenu correspondent à une préférence pour une prise en charge étendue des bases de données. Au total, les exigences suivantes sont prises en compte:

1. Prise en charge de Mongo et MySQL, avec une préférence pour la prise en charge d’options supplémentaires
2. Intégration avec Webpack
3. Intégration avec Express
4. Succès minimal des performances au moment de l’exécution
5. Syntaxe intuitive
6. Fonctionnalités supplémentaires
7. Ratio étoile/émission élevé de Github
8. Maintenu activement sans échec de génération ou dépendances obsolètes

Les candidats et les résultats

Chaque candidat a reçu une note comprise entre 0 et 10 pour chaque capacité préférée. Un score de 5 signifie acceptable. La moyenne pour une colonne peut être supérieure ou inférieure à 5. Par exemple, un ORM prenant en charge plusieurs bases de données NoSQL et ne prenant en charge aucune base de données SQL recevra un score compris entre 2 et 4. 0 indique l’absence totale d’une fonctionnalité.

Un cri spécial pour joi, pg et knex. Ces bibliothèques ne sont pas des ORM complets, mais elles sont excellentes dans ce qu’elles font. Si vous n’avez pas besoin d’un ORM complet, jetez un coup d’œil et voyez s’ils peuvent répondre à votre besoin.

Conclusion

Les totaux reflètent l’utilité globale de chaque solution. Les 5 premiers résultats étaient les suivants :

1. Loopback
2. Ligne de flottaison
3. Mangouste
4. TypeORM
5. Sequelize

Une combinaison de besoins spécifiques au projet, de facteurs omis et de préférences personnelles mène aux 3 premiers choix.

La ligne de flottaison est fortement intégrée à la structure des voiles et Mongoose ne supporte que MongoDB.

Sequelize et NodeORM2 sont limités au SQL et manquent de génération d’API.

En raison de la syntaxe TypeScript, TypeORM s’intègre bien avec un projet Angular.

En tant que développeur, je recommande de prototyper plus d’une solution de premier plan pour identifier le vrai gagnant. Les 3 meilleures solutions, qui sont toutes des candidats au prototypage, incluent:

1. Loopback
2. TypeORM
3. Caminte

J’ai soumis ces informations à d’autres développeurs du projet, et en tant qu’équipe, nous avons décidé d’essayer TypeORM en premier. Revenez plus tard pour la rétrospective!