Génération de stub javascript avec un Schema JSON

Version imprimable

16/02/2016, 18h24
yolepro

Génération de stub javascript avec un Schema JSON

Bonjour,

Nous sommes entrain de mettre en place une application AngularJS qui va consommer des services JSON.
Afin de pouvoir simplifier les développements et également la gouvernance des services, nous souhaitons donc utiliser une approche "Contract first" : c'est à dire de se mettre d'accord sur la description du service (Schema JSON) avant de commencer à développer.
Nous voulons donc trouver un moyen comme en Java (avec par exemple jax-ws generate) de pouvoir à partir du Shéma JSON générer des stub Javascript (objets vides avec les accesseurs).

J'ai cherché sur internet des modules capable de faire cela mais sans succès.

Auriez-vous une idée?

Merci pour votre retour.
16/02/2016, 23h21
slim

Salut!

Vous voudriez en fait faire du mapping de données côté client... C'est un vaste sujet, mais la seule chose que je voudrais dire est que je n'aime pas beaucoup l'idée de faire un "hibernate like" côté client...
C'est très lourd à gérer. Un framework propose cela (EmberJs) avec EmberData. Je sais pas comment les gars ont fait pour penser un framework pareil mais c'est beaucoup plus complexe à gérer que Angular et difficile à maintenir, surtout quand tu utilise le mapping de données. Ce n'est pas pour rien qu'il est classé bon dernier.
Je pense qu'il faut considérer les objets que tu reçois du serveur comme des VO (value object) ou DTO. Tes objets peuvent ne pas avoir la même constitution que tes entités côté serveur.
Regarde du côté du service $resource. Il supporte de base toutes les opérations standards et permet l'ajout très facilement de méthode custom.
Si tu veux des exemples, n'hésite pas.
17/02/2016, 09h26
yolepro

Bonjour slim et merci pour ta réponse rapide.

Je suis bien d'accord que le but n'est pas de faire un hibernate like. Par ailleurs cela ne risque pas d'arriver puisque la couche métier dans les back-ends.
Par contre, en cible il faudra appeler à minima une 30ene de service REST qui chacun d'eux aura potentiellement un cycle de vie différent. C'est pour cette raison que nous souhaitons mettre en place une couche de type POJO afin de découpler les appels de service avec la logique de controleur et d'ecran. De plus je voudrais automatiser cette création sur la base du JSON Shéma qui sera fourni par une autre application afin d'accélérer le travail de notre coté.

Entre temps, j'ai vu un projet Github qui pourrait répondre à notre besoin, je vous ferais un retour : https://github.com/tomarad/JSON-Schema-Instantiator

Toujours ouvert à la discussion malgré tout,

Merci.
17/02/2016, 10h33
Marco46

Citation:

C'est pour cette raison que nous souhaitons mettre en place une couche de type POJO afin de découpler les appels de service avec la logique de controleur et d'ecran

EDIT précision : Quand je parle de service, je ne parle pas de service web sinon c'est précisé, je parle des services angular (le composant de module).

Les contrôleurs ne doivent pas contenir de logique. Si tu écris un "if" dans un contrôleur c'est qu'il y a quelque chose que tu fais mal.
La place de la logique est dans les services et les services doivent être testés unitairement.
Le contrôleur est le constructeur du scope d'une vue. Point final. Il n'est rien d'autre qu'un espace de publication de données et de méthodes.

Quand tu as besoin d'avoir de la logique dans une vue, tu implémentes un service dont tu publies l'instance (ou les fonctions nécessaire) dans le view model.

C'est d'ailleurs pour ça que tu ne trouveras que peu de librairie ou de solution pour faire ce que tu veux dans le monde angular, parce que c'est tout simplement inutile dans le cas standard (flux back/front = application/json).

Le seul cas où ça peut être utile d'écrire une couche modèle au sens strict (des pojo donc) c'est lorsque le flux entre le front et le back n'est pas du json et donc n'est pas sérialisable facilement. Par exemple en XML. Là ça a du sens parce qu'il faut se taper l'écriture du parsing ce qui peut impliquer pas mal de règles et de logique à écrire.

Mais sur du json c'est une pure perte de temps.

Je pense que vous abordez votre webapp sous un mauvais angle, je serais curieux de connaitre vos règles de bonnes pratiques.

Citation:

Envoyé par yolepro

Par contre, en cible il faudra appeler à minima une 30ene de service REST qui chacun d'eux aura potentiellement un cycle de vie différent.

Je ne comprends pas trop "un cycle de vie différent". Des services qui pourront potentiellement évoluer... ? C'est normal. D'ailleurs, toute ton application évoluera, côté serveur et client.
et dans ce cas, je ne comprends pas la nécessité de mettre en place ce que vous voulez faire.

Citation:

Envoyé par yolepro

C'est pour cette raison que nous souhaitons mettre en place une couche de type POJO afin de découpler les appels de service avec la logique de contrôleur et d’écran.

tu parle de quels contrôleurs ? REST ou client ? (Je sais que c'est du REST dont tu parle mais je voulais souligner ce point). Il ne faudrait pas réduire ton "application" côté client à un ou des "écran".
Côté client tu aura aussi (en tous cas avec AngularJS 1.x) des contrôleurs, des services "métier" (qui appelleront tes controleurs REST) et qui te permettront d'instancier tes entités.

EDIT: après relecture de cette phrase (citation ci-dessus) et de la réponse de Marco, j'avoue que je la comprends pas trop... :)

Exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 angular.module('myApp').factory('Entite', entiteModel); entiteModel.$inject = ['$resource']; function entiteModel($resource) { return $resource('api/entites/:id', {}, { 'query': { method: 'GET', isArray: true}, 'get': { method: 'GET', transformResponse: function (data) { data = angular.fromJson(data); return data; } }, 'update': { method:'PUT' } }); }
Avec ceci, tu pourra simplement injecter Entite et faire un new Entite();Tu n'as absolument pas besoin d'un outil pour instancier tes objets !

Citation:

Envoyé par yolepro

De plus je voudrais automatiser cette création sur la base du JSON Schéma qui sera fourni par une autre application afin d'accélérer le travail de notre coté.

une autre application côté serveur ? Si oui, et bien ça sera d'autres services REST exposés et que ton application cliente appellera. Je ne vois pas où est le problème.

17/02/2016, 13h58
yolepro

Encore une fois merci à vous deux pour votre retour,

Pour information, je ne suis pas un spécialiste de ce type de techno (javascript), je suis plus habitué à une gouvernance de service SOAP / MQ / Flat file.
Concernant les ambiguités de wording, effectivement le mapping entre le service REST (exposé par le back-end) et l'application AngularJS doit se faire dans une couche spécifique coté AngularJS que nous pouvons appeler "service Angular" si tu veux, elle contiendra donc toute la logique "métier" (je le mets entre guillemet car il ne sagit pas de règle métier à proprement parler mais de composition, orchestration et / ou formattage, les vrais règles métiers étant dans les Back-ends).

Citation:

Envoyé par Marco46

Le seul cas où ça peut être utile d'écrire une couche modèle au sens strict (des pojo donc) c'est lorsque le flux entre le front et le back n'est pas du json et donc n'est pas sérialisable facilement. Par exemple en XML. Là ça a du sens parce qu'il faut se taper l'écriture du parsing ce qui peut impliquer pas mal de règles et de logique à écrire.

Au contraire, ta remarque ne fait que renforcer mon idée, le JSON étant plus permissive au niveau des types la ou XML l'est moins (e.g: date, integer, float, duration, datetime,...) il faut une couche intermediaire qui se charge de transformer dans un format et des patterns valides et compréhensible par les back-ends.
17/02/2016, 15h11
Marco46

Citation:

Envoyé par yolepro

Au contraire, ta remarque ne fait que renforcer mon idée, le JSON étant plus permissive au niveau des types la ou XML l'est moins (e.g: date, integer, float, duration, datetime,...) il faut une couche intermediaire qui se charge de transformer dans un format et des patterns valides et compréhensible par les back-ends.

J'étais un inconditionnel du XML et des XSD il fut un temps ... Jusqu'à ce que je découvre la simplicité salvatrice du json :ave:

Au final tu te rends compte que les checks sur les formulaires couplés aux checks sur le back suffisent à sécuriser (au sens de "éviter les erreurs") et qu'à l'usage tu as très peu d'erreur qui arrivent jusqu'au back. En gros le XML et le XSD c'est super top sur le papier, c'est hyper rigoureux, mais au final c'est une belle arme qui coute cher et qui ne sert pas ou très très peu.

Donc si tu peux te passer du XML (si tu as le choix du type de flux sur ton back) je te conseille de passer au json. Il y a d'autres avantages à l'usage des json (taille des flux, performances bien supérieures, sérialisation native, ...).

Pour ce qui est du format des data à envoyer au back depuis le front et vice et versa c'est un débat complexe qui dépend de beaucoup de paramètres.
Par exemple, est-ce que tes webservices sont conçus pour être des endpoints génériques ou bien sont-ils dédiés à ce front là en particulier.
La réponse à cette simple question affecte énormément la future complexité du front dans les deux sens du flux (GET et POST/PUT).
Cela affecte également de façon majeure la conception de tes webservices.
En gros ça se résume à : "Est-ce que mes webservices doivent représenter une abstraction de mon domaine métier ou doivent-ils être conçu pour faciliter le développement du frontend ?". Remarque que tes webservices de bases peuvent parfaitement être une abstraction de ton métier et en parallèle tu pourras avoir une surcouche qui se spécialise sur ton front.
Bref, c'est compliqué :mrgreen:

Dans ton message il y a également le sujet entre le raffinage des données et le formatage des données (c'est mon vocabulaire perso il y a certainement mieux et plus précis). Il y a une nuance importante.
Raffiner les données ça veut dire que je prends 2 ou plus données en provenance du back et j'en compose une nouvelle avant de la publier dans une vue.
Formater une donnée ça veut dire prendre une donnée et modifier son format. Donc il ne s'agit pas de créer une nouvelle donnée, ni de modifier une existante, mais simplement de changer la manière dont elle est affichée. Ca c'est le rôle des filter en angular.
Ca semble simple en apparence mais pas tant que ça à l'usage pour beaucoup de devs.
La réponse à la question précédente a un impact majeur sur le raffinage des données.
17/02/2016, 17h35
yolepro

Ta réponse est très clair,

Si je résume avec mes mots, les API Angular permettent de simplifier fortement le mapping avec les responses JSON donc dans l'absolus, il n'y a pas de besoin d'une couche intermediaire car elle ne ferait pas gagner de temps.
Les composants de type Filter d'AngularJS permettent de faire du consistency check (validation de surface) sur les différents formats possible ce qui évite d'avoir à effectuer ses validations dans la couche de service. Dans ce cas, seul les consistency check coté back-end devront être fait (il faut les faire dans tous les cas).

Concernant les services REST que nous souhaitons exposés, ils auront voccation à être utilisable par plusieurs applications et non spécifique par application (même si la plupart sera très certainement spécifique).