Aujourd'hui, je vous propose de lire un retour d'expérience sur un framework NodeJS sympathique et plein de tentacules : Sails.
Pour un projet, j'ai dû choisir un framework NodeJS et j'ai eu envie d'essayer Sails js. Quelques mois plus tard, je vous propose de revenir sur les points "remarquables" du framework.

En quelques mots, sachez qu'il s'agit d'un framework VMC aux inspirations assez proches de Rails et construit entièrement en Javascript. Complet sans trop en faire, il avait de bons arguments pour me donner envie de l'essayer.

Pourquoi Sails ?

Pour ma part, le choix de ce framework a été decide par plusieurs facteurs. 

Tout d'abord, le fait qu'il me laisse choisir ma base de données sans m'imposer MongoDB a été un très bon point. Même si le NoSQL peut avoir des avantages pour certains projets, j'aime est souple sur le point et être capable de m'adapter à mes besoins et pas aux contraintes de dépendance de mes outils.

Trouvez un webdesigner disponible

Trouvez gratuitement le prochain talent qui réalisera votre projet ou rejoindra votre équipe.

Ensuite, son aspect strict et rangé m'a beaucoup plus et immédiatement rappelle Rails et l'écosystème Ruby.

Enfin, la documentation en apparence complète m'a rassuré. Ce point était malheureusement un piège et j'ai du lire pas mal de code pour m'en tirer, mais cela fait partie des raisons qui m'ont poussé vers ce choix.

Si vous êtes a la recherche d'un framework très structuré pour Node Js, et que vous n'avez pas un besoin de performance extrême (je n'ai pas eu de problème sur ce point, mais j'ai lu quelques articles se plaignant de la vitesse de Sails), Sails vous plairont peut-être à vous aussi.

Mon avis sur le Framework

Pour une fois, je vais mettre ma conclusion tout en haut de l'article, pour nuancer un peu le reste de l'article. À la relecture, je me trouve un peu dur avec ce framework qui l'un dans l'autre m'a beaucoup plus

Bien sur, la documentation n'est clairement pas nécessaire, et il faut s'attendre à tomber dans des pièges de temps à autre tendu par cette dernière mais n'est-ce pas le cas de toutes les documentations de l'écosystème Javascript ? Les ressources sortent et évoluent trop vite pour que les documentations suivent, ce qui est inacceptable mais malheureusement commun dans cette communauté.

L'ORM me pose quelques soucis, mais il est certainement possible de le remplacer, tout comme il est possible de créer ou adapter une administration existant pour remplacer l'expérience très désagréable qu'a été Sails hook Admin panel.

Au final, beaucoup de choses m'ont dérangée dans ce framework, c'est vrai, mais je sais déjà que je le réutiliserais sur le prochain projet nécessitant Node Js. Je vous encourage donc à l'essayer pour vous faire un avis par vous-même.

L'aspect général du framework

Rien à redire sur ce point, Sail est très intelligemment organisé, et très agréable à manipuler. Fournis avec des standards qui plairont au plus grand monde (Javascript op coffee, scss ou sass, ejs), il ne nécessitera pas de configuration sur ce point pour la plupart d'entre vous (Personnellement j'ai choisi de remplacer ejs par Jade Pug).

L'application est organisée en 4 grands dossiers principaux : config (pour les routes, les initializers, …), views, assets et enfin api (models, controllers, policies, …). Pour ce qui est des fichiers, beaucoup d'informations passent par leur nom, ce qui force une certaine rigueur de nommage bienvenue.

Les assets sont pris en charge par une configuration Grunt simple à comprendre et à modifier, mais malheureusement trop peu documentée à mon gout.

L'ORM : Waterline

Disons le tout de suite, Waterline n'est pas un excellent ORM. Certaines idées sont très intéressantes mais trop peu documentées, et certains points sont simplement vraiment trop restrictifs à comparer à d'autres ORM.

Une des idées intéressantes se situe au niveau de la modification de la base de données. La plupart des ORM fonctionnent avec des fichiers de migration à écrire soi-même ou générer avec un outil, mais Waterline a pris une position bien plus radicale : A chacun démarrage de l'application en développement, l'ORM modifie le schéma de base de données pour correspondre aux models. 

Évidemment, c'est plus "simple" comme ça et même assez agréable à manipuler, mais ce fonctionnement pose pour moi d'assez gros problèmes, comme par exemple des pertes de données quand on travaille en équipe. Dommage que les développeurs n'aient pas opté pour une solution entre-deux, où il aurait été possible de générer des fichiers de migrations en fonction des modifications apportées aux models.

Ensuite, petit point ennuyeux a déclaré, Waterline est obligatoirement asynchrone. Là où la plupart des ORM en Javascript proposent des appels sync ou async, nous n'avons pas cette liberté avec Waterline. Ce point n'est néanmoins pas très grave et une simple lib comme "async" regle très bien ce besoin.

Enfin, et c'est le point le plus "grave" pour moi : chainer les models est extrêmement complexe. Prenons un exemple simple : un modèle "Artist" a une liaison "has_many" sur un modèle "Album", qui à lui un "has_many" sur "Song". Il sera impossible de faire quelque chose approchant "Artist.find({id: 1}). albums[0].songs" (ce code est évidemment non fonctionnel, c'est une illustration). La seule solution sera de rechercher les albums ayant la bonne valeur de artist_id, puis d'accéder à l'artiste et aux chansons depuis là.

Ce point peut sembler anecdotique, mais sachez bien qu'à l'utilisation, il se retrouve totalement contre-intuitif et nous met parfois dans des situations bien plus complexes que mon exemple. 

Les controlleurs

Rien de particulier à dire sur ce point, si vous avez déjà manipuée express vous ne serez absolument pas perdu. Seul petit reproche, il n'est pas possible d'exécuter des filters avant ou après plusieurs actions d'un ou plusieurs controllers. Nous sommes donc oblige à utiliser des policies pour cette tache, ce qui n'est pas leur rôle.

Les routes

Rien d'exceptionnel ici, mais le minimum syndical est fourni. Je ne m'attarde donc pas sur ce point.

Les policies

Les policies sont une idée intéressante, sorte de before action pour ceux d'entre vous qui ont déjà manipulese Rails. Leur rôle est sans être de gérer les différentes autorisations nécessaires pour accéder à une page (l'utilisateur et connecte, la ressource lui est accessible, …), et cette organisation est vraiment intéressante. Seul problème, ces policies sont les seuls moyens à notre disposition pour exécuter du code avant chaque action, et il est donc vraiment tentant de les utiliser de manière un peu moins organisée.

Une interface d'administration ?

En cas d'un projet en Ruby, je sais que j'aurais accès à une administration de qualité que je choisisse Rails (Rails Admin) ou que je choisisse Padrino (Padrino Admin). C'est donc avec stupeur que j'ai découvert qu'il n'existe RIEN de satisfaisant pour Sails (Ou pour express en général, soyons réaliste). La seule solution agnostique et simple à mettre en place que j'ai trouvée et Sails Hook Admin Panel, mais attendez-vous à bricoler : la pagination est défectueuse, les checkboxes ne marchent pas, et j'en passe.

Ce point est peut-être ma plus grosse déception sur le Framework.