On Wednesday 13th of November, we organized with the Node.js Paris group a new meetup in our office in Paris around Javascript! It was a real success with nearly 70 people who attended the event to exchange views on Micro Services, CPU Profiling WebSocket, TypeScript.

1. 1
Paris Node.JS & Voodoo
Chapter 7 / Conference 03
Novembre 2019
2019

2. 2
Qui est Node.JS ?

3. 3
Programme
❏ Présentation Voodoo 5”
❏ Sacha CLERC-RENAUD : Monolith vers Micro services, en 2 ans qu'avons nous appris. 20"
❏ Vincent Vallet : Déclencher des actions en temps réel sur la production. 20"
❏ 10” Break
❏ Yohan Lasorsa : Oups, j'ai mis du TypeScript dans mon appli Node.js ! 20”
❏ COCKTAIL DINATOIRE!

4. 4
Qui sommes nous ?
2.6 milliard
de téléchargements
300 millions
d’utilisateurs actifs mensuels
plus d’1 milliard
d’événements par heure
15 To et des milliards de
requêtes par jour
Leader dans le secteur des jeux
mobiles hyper casual
International :
Berlin, Barcelone, Amsterdam, UK
à venir Montréal …
*200 salariés*
3 BU Opérationnels :
- Growth & Engineering
- Apps
- Gaming
● Website : www.voodoo.io
● Pour postuler : jobs@voodoo.io /
via le site
● Contact : stephanie@voodoo.io
● Voodoo Talks Tech
Next event : DotJS Paris @ Voodoo,
le 4 décembre 2019

5. Monolithe vers
micro services
Retour d’expérience

6. Introduction
Sacha Clerc-Renaud
Développeur Backend Node.js depuis 2012

7. Contexte
Au départ plutôt food que tech

9. Contexte

10. Stratégie
● Découpage par domaine métier
● Nouvelle fonctionnalité = refacto en micro service

11. Contraintes
Continuer à délivrer de la valeur.

12. Contraintes
Downtime autorisée pendant les heures creuses.

13. Go micro services !!

14. Situation initiale

15. Maîtriser les dépendances NPM
● Sécurité accrue
● Peu de migrations à gérer
● Stack cohérente entre service
● Plus rapide à installer

16. Orchestration
● Déploiements faciles
● Rollback rapide
● Rolling update
● Mise à l’échelle

17. Orchestration
Un commit pour deploy
Un commit pour rollback

18. Monitoring
● Logger les requêtes
● Localiser l’erreur
● Avoir des alertes

19. Mettre en place une gateway

20. Mettre en place une gateway
● Abstraire les services
● Rollback du pauvre

21. Une gateway par plateforme

22. Ajouter des micro services

23. Partager la DB entre les micro services
Pour :
● Gains de temps
● Requêtes facile
Contre :
● Single point of failure
● Couplage entre service

24. Partager la DB entre les micro services

25. Mise en place d’un template
Pour :
● Facilite la creation de MS
● Code plus homogène
Contre :
● Difficile d’avoir un template générique qui couvre tous les use cases
● Nécessite d’avoir un peu stabilisé les techno choisies.

26. Ce qu’on ferait différemment aujourd’hui
● Séparer certaines DB plus tôt
● Regrouper certains services
● Avoir un correlation ID dans nos logs
● Des dashboards & metrics par MS
● Avoir une map des dépendances entre MS (calls & events)

27. Est-ce que ça a marché ?

28. En résumé
En 2 ans : Environs 100 microservices

29. En résumé
● Partager les DB est une bonne idée
● Un commit pour deploy/rollback
● Exploitez la flexibilité des gateways
Mail: sachacr@gmail.com
Twitter: @Sasqwach

30. 30
Vincent Vallet : Déclencher des actions en temps réel sur la
production.
Description :
Comment communiquer avec les instances (même en production) pour
déclencher des diagnostiques, des profiling CPU ou même des actions
fonctionnelles ? On verra comment construire une architecture à base de
WebSocket pour répondre à ce besoin et récupérer des données sur l'état
de santé de vos applications.

31. Real time actions on
production

32. Hello!
Vincent Vallet
NodeJs & performance evangelist
@Vince_Vallet
32

33. What / Why
… technical actions vs functional actions!
1

34. What?
Instance
Instance
Monitoring
system
Real time
action
system

35. Why?
- Be proactive
- Get immediate information about runtime
- Make your system independent of monitoring solutions
- Cost saving?

36. Architecture
WebSocket, Node.js and message queue
2

37. Instance
Instance
.
.
.
Productio
n
WS
ServerWS
Server
Message
queue API
NodeHealth
UI
NoSql
Message
queue
WS
1. connect
2. save
3. read
4. Send action5. Send to all
queues
6. Read queue
7. Send message

38. Ready for production?
Performance, security, scalability ...
3

39. Scalability
Do not scale on CPU or memory!
Scaling based on number of open Web Socket!

40. Security
Use authentication system based on Json Web Token !

41. Instance
Instance
.
.
.
Productio
n
WS
ServerWS
Server
Message
queue API
NodeHealth
UI
NoSql
Message
queue
WS
1. Connect
+
JWT

42. const WebSocket = require('ws')
const ws = new WebSocket
'ws://localhost:8000',{
headers : {
token: "myTokenHere"
}
}
const WebSocketServer = require('ws').Server
const ws = new WebSocketServer({
verifyClient: (info, cb) => {
const token = info.req.headers.token
if (!token)
cb(false, 401, 'Unauthorized')
else {
jwt.verify(token, 'secret-key', (err, decoded) => {
if (err) {
cb(false, 401, 'Unauthorized')
} else {
info.req.user = decoded
cb(true)
}
})
}
}
})

43. Broken connections
Auto close broken connections: on client and server side!

44. const WebSocket = require('ws')
const ws = new WebSocket('ws://localhost:8000')
function heartbeat = {
clearTimeout(this.pingTimeout)
this.pingTimeout = setTimeout(function () {
ws.terminate()
}, 30000 + 1000)
}
ws.on(‘open’, heartbeat)
ws.on(‘ping’, heartbeat)
ws.on(‘close’, function () {
clearTimeout(this.pingTimeout)
})
const WebSocket = require('ws')
const wss = new WebSocketServer()
const heartbeat = () => {this.isAlive = true}
wss.on(‘connection’, (ws) => {
ws.isAlive = true
ws.on(‘pong’, heartbeat)
})
const interval = setInterval(() => {
wss.clients.forEach((ws) => {
if (ws.isAlive === false) return ws.terminate()
ws.isAlive = false
})
}, 30000)

45. Automatic connection
Case 1: your instance has restarted => simple WS connection
Case 2: your WSS has restarted / crashed, then enable automatic
reconnection from client!

46. Instance
Instance
.
.
.
Productio
n
WS
ServerWS
Server
Message
queue API
NodeHealth
UI
NoSql
Message
queue
WS
1. connect
Automatic
reconnection on
client side

47. const WebSocket = require('ws')
const connectToWSS = () => {
const ws = new WebSocket('ws://localhost:8000')
ws.on(‘close’, function () {
ws.terminate()
clearTimeout(this.pingTimeout)
connectToWSS()
})
ws.on(‘error’, function () {
ws.terminate()
})
}
connectToWSS()

48. Performance
WS are not CPU consuming, it’s idle most of the time.
Be careful of action you trigger on your system!

49. Thanks!
Any questions?
You can find me at:
◇ @Vince_Vallet
◇ wallet77@gmail.com
49

50. Credits
◇ https://nodejs.org/api/inspector.html
◇ https://chromedevtools.github.io/devtools-protocol/v8
◇ https://www.youtube.com/watch?v=IdR6N9B-S1E
◇ https://github.com/websockets/ws/blob/HEAD/doc/ws.md
◇ http://iostreamer.me/ws/node.js/jwt/2016/05/08/websockets_
authentication.html
50

51. 51
Yohan Lasorsa : Oups, j'ai mis du TypeScript dans mon appli Node.js !
Description :
Et si on faisait une petite appli Node.js, from scratch... en TypeScript?
A travers un live coding de 20min, nous allons voir ensemble que rajouter du
TypeScript à une application Node.js se fait finalement avec très peu de
contraintes, avec pour bénéfices tout ce qui découle de TypeScript.
Du workflow de dev jusqu'au packaging de librairie (en incluant les types bien
sûr ;-)), tout y passe! Après cela, plus d'excuse pour ne pas s'y mettre...