StrongLoop : Créer un repo REST en quelques lignes

A ce jour, il existe beaucoup de moyens d’arriver à nos fins, et malgré tout, sur certains standards, on se pose encore la question de comment fait-on pour ne pas le faire à la main.
Et malgré tout, la tentation est là, de repartir sur une habitude ancestrale de vouloir réinventer la roue, mais en moins bien.

Strongloop existe depuis 2013, et a créé une certaine émulation autour de son produit phare “LoopBack“, à tel point que IBM s’est décidé de racheter cette entreprise en 2015.
La communauté a frissonné à ce moment là, car généralement, le produit est assimilé, et disparait de la communauté pour apparaître dans les produits internes de l’acheteur.
Strongloop existe toujours, et continue son développement, même si IBM y a imposé son empreinte, le principal reste ouvert et open source.

Strongloop propose 3 produits:

  • Loopback qui permet de monter très rapidement un back end REST
  • Strongops, produit orienté monitoring
  • StrongNode, produit orienté nodejs, debugging, clustering, et gestion de repo NPM privé

Je m’intéresserai à LoopBack aujourd’hui.

 

Loopback

 

Mettre en place un backend REST, et notamment exposer des services est un travail relativement fastidieux, et surtout d’un intérêt médiocre pour un développeur.
Exposer des services CRUD, sont des tâches répétitives qu’on aimerait pouvoir déléguer.
Loopback se charge de créer un serveur nodejs avec des services REST mappés sur vos modèles.
La force de loopback c’est que vous pouvez soit:

  • Créer votre modèle en partant ex nihilo,
  • Explorer un modèle stocké en base de données (mysql, mongodb, …).

Création de nouveaux modèles (tables)

 

Le plus simple est de vous montrer la création de vos modèles.
En quelques lignes de commandes, vous aurez plusieurs tables, et les API REST permettant d’y accéder.

Installons Strongloop

 

Créons notre première application

 

Créons une datasource inMemory, cela suffira pour l’instant pour la démo, les données ne seront pas persistantes mais seront conservées tant que l’application tourne.

 

Créons notre première table client.

 

Créons notre table fournisseur.

Vous retrouverez alors dans votre projet, un répertoire common, qui contient la définition de vos modèles, ils sont en json, et facile à visualiser.

 

Pour persister, il suffit de déclarer une datasource dans loopback via cette commande.

 

La commande vous propose d’ailleurs d’installer le connecteur qui va bien à ce moment là.
Si vos modèles sont déjà créés, il suffit d’aller les modifier cette fois ci dans le répertoire serveur, et d’indiquer le nom de la datasource que vous avez déclarée.

 

Accéder à vos APIs

 

Lançons le serveur.

Accédons à l’url d’exploration http://localhost:3000/explorer

 

Vous retrouvez vos modèles, et pour chaque modèle, vous avez la liste des API accessibles.
L’explorer expose non seulement les opérations élémentaires, mais vous guide vers des opérations standards avec une description facilitant leur utilisation.

En cliquant sur une opération, vous récupérer le détails de l’opération (schéma en entrée, en sortie), et surtout vous avez l’opportunité de tester vos APIs sans aide extérieure.

 

L’opération findOne est peut être la plus délicate à utiliser car la syntaxe du discriminant n’est pas la plus aisée, malgré tout, elle reste bien documentée, mais demandera pour la plupart d’entre vous, une phase d’expérimentation via l’explorer.

 

Modèles existants

 

Dans le cas, où vous avez déjà une base de données, ou qu’elle a été générée par script ou un ORM, loopback fournit un outil d’exploration de votre base de données.
C’est un outil graphique, et vous permet de sélectionner les tables et les champs qui vous intéressent.
Il crée alors les modèles loopback correspondant, et de la même manière en lançant votre serveur, les API REST sont accessibles et attaquent en direct votre base de données préférée.

C’est un petit tour de passe-passe, qui vous permet, sur de vieilles applications, pas forcément adaptées à la “transformation digitale”, de pouvoir exposer à moindres frais des services REST pour d’autres systèmes.
Attention, il n’est pas toujours désirable de pouvoir attaquer la base en direct, et des contrôles/règles de gestion existant dans l’ancien système ne sont pas redescendus dans ces services.

Mais rien ne vous empêche d’ajouter la couche de validation, et de contrôle nécessaire à sécuriser l’accès à votre référentiel.

NB : IBM a retiré l’outil ARC au profit de API CONNECT qui nécessite de posséder un identifiant BLUEMIX.

 

Gestion des Relations entre modèles

 

Si on reprend, le modèle créé tout à l’heure, on voit qu’à la fin du json, loopback apporte un attribut relation qui est vide par défaut.
C’est dans cet attribut que vous pouvez indiquer le type de relation contraignant votre modèle, en ajoutant une foreign key par exemple !

 

Désormais, dans l’explorer vous pouvez voir que depuis le client, vous pouvez en récupérer le fournisseur.

 

Mise en place de validateur

 

Vous pouvez ajouter des clauses de validation de la même manière que les relations au sein du modèle. Soit des validations simples de type contrôle qu’une valeur est comprise dans une liste de valeur prédéfinie, ou des contrôles plus complexes faisant appel à des appels externes par exemple.

 

Testons au travers de l’explorer la gestion d’erreur si jamais nous essayons d’insérer une donnée non prévue.

 

Sécurité

 

Dans le fichier modèle, vous retrouvez également un champ “ACL” (Access control list), une terminologie plutôt standard.
Vous pouvez appliquer une acl de manière globale en passant par la ligne de commande.

 

Ou aller dans chaque modèle et préciser la sécurité que vous voulez mettre en place.

 

En reprenant l’exemple du backend créé pour servir un système plus ancien, et lui permettre de se rendre accessible à des applications dites “digitales”, il est possible par ce biais de rendre inaccessible certaines données en mode public, ou de restreindre l’accès aux données en lecture seule par exemple.
La configuration est aisée, unitaire, et permet une grande souplesse pour atteindre les conditions de sécurité désirées.

 

Conclusion

Le monde js propose des alternatives légères, rapides à implémenter, et avec de très bonnes performances.
Strongloop fait partie des briques qui permettent d’industrialiser le développement, pour rester concentré sur le coeur de métier, et non pas le développement de services basiques.
J’encourage fortement à le prendre en compte lorsque vous voulez créer un backoffice REST.

Pour information, IBM au travers de Bluemix, permet de déployer du strongloop sur ses serveurs. Amazon propose également ce service.
Ce n’est pas anodin, et c’est une reconnaissance de la valeur du produit.

Pascal Ogil

Leave a Reply

Your email address will not be published. Required fields are marked *