Comment passer des informations sur toute la stack d'un appel d'API en NodeJS ?

[Cyril Lakech]

Bonjour à tous,

C'est déjà la rentrée ! Et j'ai besoin de votre point de vue SVP.

On utilise NodeJS pour nos API avec Express mais la question est générale pour toute stack NodeJS.

On souhaite pouvoir faire transiter un identifiant de requête quand un appel d'API survient, un correlationId comme on dit.

Ce correlationId permet de suivre dans les logs (kibana/etc.) les différents traitements liés à un appel d'API.

1/ Dans un midddleware on génère/récupère un correlationID unique pour la requête d'API en cours

2/ On le passe au premier service qui le trace avec des infos dans les logs

3/ Le premier service passe ce correlationID aux autres services qu'il appelle

4/ Les services suivants font de même

5/ etc...

Dans les logs on peut voir l'activité liée à cette requête en filtrant sur ce correlationID

12:15:01 correlationID1234 ServiceA de traitement de la requête: OK

12:15:01 correlationID1234 ServiceB d'envoie d'email: OK

12:15:01 correlationID1234 ServiceC de sauvegarde: OK

12:15:01 correlationID1234 ServiceD de recyclage des déchets: OK

...

Est-ce que vous avez déjà eu ce besoin et comment l'avez vous développé ?

Actuellement, on se balade avec un object de contexte qui contient de correlationId entre tous les appels, c'est assez fastidieux comme vous pouvez l'imaginez. Ce n'est pas facilement scalable.

On sait qu'on peut le faire avec les ProxyES6, les décorateurs dans NodeJS 8, des sessions, l'api domain NodeJS (deprecated), avec de la génération de code, https://datahero.com/blog/2014/05/22/node-js-preserving-data-across-async-callbacks/ etc... Il existe plusieurs implémentation possible mais toutes celles qu'on a exploré ont des limitations jusqu'à présent. On compte sur les décorateurs dans NodeJS 8 pour nous simplifier la tâche.

Bref, est-ce que vous avez un avis sur une bonne pratique d'implémentation pour passer des informations à tous les traitements qui vont s'executer lors d'un appel d'API par exemple ?

Bonne journée

Cyril

[Cyril Lakech]

Des pistes sérieuses:

Node <8: https://www.npmjs.com/package/continuation-local-storage

Node >=8: https://www.npmjs.com/package/cls-hooked avec asynchooks https://nodejs.org/api/async_hooks.html (experimental)

[Cyril Lakech]

Hello,

Pour info j'ai mis des notes et un exemple basé sur async_hooks et cls-hooked sur ce sujet sur github : https://clakech.github.io/cls-hooked-sample/ ;-)

Bye

[Jb Pionnier]

Salut Cyril,

Tu as des pistes.. c'est cool.

Maintenant, je me demande quel est l'utilité de faire ca ?
Ca va te générer un tas de log.

N'est il pas possible d'avoir la même info avec un APM du style New Relic (en plus d'avoir le temps passé dans chaque méthode)

Si tu souhaite en revanche connaître / sauvegarder / historiser chaque état de ton application.. peut être que l'event sourcing est ton ami (l'event store devient ton fichier de log... reporting etc) ?

On en reparle autour d'une mousse :-)

[Cyril Lakech]

Merci pour ta réponse,

Yes, on utilise Dynatrace ;) On est en train de le mettre à jour et il semble qu'on va avoir des nouveautés côté NodeJS justement, on espère que ca nous aidera aussi sur ce sujet.

Avoir un correlationId qui transit dans les logs entre les différents traitement est un besoin assez répandu qui aide pour l'exploitation: https://www.google.fr/search?q=log+correlation+ID&oq=log+correlation+ID&aqs=chrome..69i57j0l5.3167j0j7&sourceid=chrome&ie=UTF-8 Mais c'est clair qu'on peut le challenger si on réussit à trouver une autre approche plus satisfaisante.

PS: Tiens Tiens l'event sourcing en JS ca me rappelle quelque chose ;) #devoxxFrance merci pour le rappel.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "ChtiJS".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse chtijs+un...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

Cyril Lakech