Meteor

Vidéo : https://www.youtube.com/watch?v=kyBLLqyduvE

Meteor est un framework tout en JavaScript pour construire des applications web. Il est souvent connu pour la facilité avec laquelle il permet de construire des applications temps-réel. Mais ce n'est qu'une partie de l'histoire…

Dans cette session, j'expliquerai ce qu'est et n'est pas la réactivité.
Je reviendrai sur les isopacks, qui rendent possible l'uniformisation des APIs entre côtés client et serveur, donnant ainsi un sens au partage du langage.
J'évoquerai DDP, le « REST des websockets ».
Je présenterai ce que j'ai aimé et ce qui n'a pas marché.

En bref, je partagerai avec vous l'expérience accumulée dans le contexte assez extrême de la modernisation du gouvernement français par la construction d'applications web au sein des Startups d'État.

Transcript

1. Matti Schneider Tech : @matti_sg France : @matti_sg_fr Les termes soulignés dans le texte signifient qu’il faut passer à la slide suivante. Presenté le 12 juin 2015 à RivieraDEV, Sophia-Antipolis (FR). CC-BY-NC-SA You can quote, reuse and remix this presentation as long as you cite me, but you may not make money out of it, including from training classes. If you include parts of this work in yours, you must make your own work available to the public for reuse too. Also, it would be nice from you to let me know about it :) If you want to use this material otherwise, please contact me.
2. Meteor est un framework et environnement de développement d’applications web très ambitieux. Version 1.0 en octobre 2014.
3. Démo : application de réponse collaborative à des amendements à un projet de loi proposés par les députés. Accessible sur https://fiches-demo.meteor.com (test@test.com / herpaderp).
4. One Language Meteor permet d’écrire tant les composants serveur que client d’une application web dans un seul langage de programmation. Quel langage ? JavaScript, évidemment. Pas nouveau, ça fait longtemps que la promesse existe.
5. One Language Meteor permet d’écrire tant les composants serveur que client d’une application web dans un seul langage de programmation. Quel langage ? JavaScript, évidemment. Pas nouveau, ça fait longtemps que la promesse existe.
6. One Language ≠ Mais même si on utilise le même langage, la réalité est que ce qu’on peut faire est très différent : les API Node et celle du DOM n’ont pas grand-chose à voir. Le fantasme de tout écrire dans un seul langage se heurte à la bibliothèque standard. Ce problème n’étant pas nouveau, il est possible d’écrire du code isomorphe (qui s’exécute à la fois côté client et serveur de la même manière) indépendamment de Meteor, par exemple avec Browserify et les versions client des modules core de Node. Meteor vient rajouter un mécanisme de chargement qui uniformise l’inclusion de fichiers et le mécanisme d’exécution : tout le code est chargé dans le runtime, qu’il s’agisse du navigateur ou de Node, la majeure partie de l’API est isomorphe, et des primitives (Meteor.isClient, Meteor.isServer) permettent de faire la disjonction dans le cas où le code doit s’appliquer différemment dans les deux environnements. Au passage, compile aussi vers mobile (comme client) via Cordova. Le composant Meteor : https://www.meteor.com/isobuild
7. One Language ≠ Mais même si on utilise le même langage, la réalité est que ce qu’on peut faire est très différent : les API Node et celle du DOM n’ont pas grand-chose à voir. Le fantasme de tout écrire dans un seul langage se heurte à la bibliothèque standard. Ce problème n’étant pas nouveau, il est possible d’écrire du code isomorphe (qui s’exécute à la fois côté client et serveur de la même manière) indépendamment de Meteor, par exemple avec Browserify et les versions client des modules core de Node. Meteor vient rajouter un mécanisme de chargement qui uniformise l’inclusion de fichiers et le mécanisme d’exécution : tout le code est chargé dans le runtime, qu’il s’agisse du navigateur ou de Node, la majeure partie de l’API est isomorphe, et des primitives (Meteor.isClient, Meteor.isServer) permettent de faire la disjonction dans le cas où le code doit s’appliquer différemment dans les deux environnements. Au passage, compile aussi vers mobile (comme client) via Cordova. Le composant Meteor : https://www.meteor.com/isobuild
8. One Language ≠ Mais même si on utilise le même langage, la réalité est que ce qu’on peut faire est très différent : les API Node et celle du DOM n’ont pas grand-chose à voir. Le fantasme de tout écrire dans un seul langage se heurte à la bibliothèque standard. Ce problème n’étant pas nouveau, il est possible d’écrire du code isomorphe (qui s’exécute à la fois côté client et serveur de la même manière) indépendamment de Meteor, par exemple avec Browserify et les versions client des modules core de Node. Meteor vient rajouter un mécanisme de chargement qui uniformise l’inclusion de fichiers et le mécanisme d’exécution : tout le code est chargé dans le runtime, qu’il s’agisse du navigateur ou de Node, la majeure partie de l’API est isomorphe, et des primitives (Meteor.isClient, Meteor.isServer) permettent de faire la disjonction dans le cas où le code doit s’appliquer différemment dans les deux environnements. Au passage, compile aussi vers mobile (comme client) via Cordova. Le composant Meteor : https://www.meteor.com/isobuild
9. Data on the Wire [ ] Même si on a un seul langage, il faut tout de même transférer de l’information entre le client et le serveur.
10. Data on the Wire <html> [ ] Rappelez-vous : on a commencé par envoyer l’information sous la forme de pages complètes. Puis on a déplacé le rendu des vues sur le client, et on a utilisé des architectures RESTful pour interagir avec le serveur. Très bien pour des échanges directs, mais moyen pour du temps-réel : pas de notification du serveur, beaucoup d’allers-retours. DDP (Distributed Data Protocol) : messages en JSON sur du websocket (en réalité, tout canal de communicaiton bidirectionnel, websocket optionnel, mais meilleure implémentation actuelle). Permet de faire du RPC et de la synchronisation de données. Exemple : RPC. Autres types de messages (sub, added, changed, removed…) pour des événements sur un jeu de données. Le composant Meteor : https://www.meteor.com/ddp Introduction avec diagrammes de séquence : https://meteorhacks.com/introduction-to-ddp Spec : https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP.md
11. Data on the Wire [ ] REST Rappelez-vous : on a commencé par envoyer l’information sous la forme de pages complètes. Puis on a déplacé le rendu des vues sur le client, et on a utilisé des architectures RESTful pour interagir avec le serveur. Très bien pour des échanges directs, mais moyen pour du temps-réel : pas de notification du serveur, beaucoup d’allers-retours. DDP (Distributed Data Protocol) : messages en JSON sur du websocket (en réalité, tout canal de communicaiton bidirectionnel, websocket optionnel, mais meilleure implémentation actuelle). Permet de faire du RPC et de la synchronisation de données. Exemple : RPC. Autres types de messages (sub, added, changed, removed…) pour des événements sur un jeu de données. Le composant Meteor : https://www.meteor.com/ddp Introduction avec diagrammes de séquence : https://meteorhacks.com/introduction-to-ddp Spec : https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP.md
12. Data on the Wire [ ] DDP Rappelez-vous : on a commencé par envoyer l’information sous la forme de pages complètes. Puis on a déplacé le rendu des vues sur le client, et on a utilisé des architectures RESTful pour interagir avec le serveur. Très bien pour des échanges directs, mais moyen pour du temps-réel : pas de notification du serveur, beaucoup d’allers-retours. DDP (Distributed Data Protocol) : messages en JSON sur du websocket (en réalité, tout canal de communicaiton bidirectionnel, websocket optionnel, mais meilleure implémentation actuelle). Permet de faire du RPC et de la synchronisation de données. Exemple : RPC. Autres types de messages (sub, added, changed, removed…) pour des événements sur un jeu de données. Le composant Meteor : https://www.meteor.com/ddp Introduction avec diagrammes de séquence : https://meteorhacks.com/introduction-to-ddp Spec : https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP.md
13. Data on the Wire [ ] DDP {"msg":"method", "method": "haveFun", "params": ["RivieraDEV"], "id": "someId"} {"msg":"result", "id": "someId" "result": true} Rappelez-vous : on a commencé par envoyer l’information sous la forme de pages complètes. Puis on a déplacé le rendu des vues sur le client, et on a utilisé des architectures RESTful pour interagir avec le serveur. Très bien pour des échanges directs, mais moyen pour du temps-réel : pas de notification du serveur, beaucoup d’allers-retours. DDP (Distributed Data Protocol) : messages en JSON sur du websocket (en réalité, tout canal de communicaiton bidirectionnel, websocket optionnel, mais meilleure implémentation actuelle). Permet de faire du RPC et de la synchronisation de données. Exemple : RPC. Autres types de messages (sub, added, changed, removed…) pour des événements sur un jeu de données. Le composant Meteor : https://www.meteor.com/ddp Introduction avec diagrammes de séquence : https://meteorhacks.com/introduction-to-ddp Spec : https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP.md
14. Database Everywhere Mais en réalité, dans l’immense majorité des cas, que veut-on échanger ? Des informations de synchronisation d’une base de données commune. Meteor rend ce type d’échange trivial : une API commune d’accès à la base de données, avec une couche d’abstraction. Une implémentation côté client de MongoDB, MiniMongo. Des connecteurs pour d’autres bases de données sont en cours, notamment Redis et Postgre. Les composants Meteor : https://www.meteor.com/livequery et https://www.meteor.com/mini-databases
15. Database Everywhere collection.insert(doc) Mais en réalité, dans l’immense majorité des cas, que veut-on échanger ? Des informations de synchronisation d’une base de données commune. Meteor rend ce type d’échange trivial : une API commune d’accès à la base de données, avec une couche d’abstraction. Une implémentation côté client de MongoDB, MiniMongo. Des connecteurs pour d’autres bases de données sont en cours, notamment Redis et Postgre. Les composants Meteor : https://www.meteor.com/livequery et https://www.meteor.com/mini-databases
16. Database Everywhere collection.insert(doc) Mais en réalité, dans l’immense majorité des cas, que veut-on échanger ? Des informations de synchronisation d’une base de données commune. Meteor rend ce type d’échange trivial : une API commune d’accès à la base de données, avec une couche d’abstraction. Une implémentation côté client de MongoDB, MiniMongo. Des connecteurs pour d’autres bases de données sont en cours, notamment Redis et Postgre. Les composants Meteor : https://www.meteor.com/livequery et https://www.meteor.com/mini-databases
17. Database Everywhere minimongo collection.insert(doc) Mais en réalité, dans l’immense majorité des cas, que veut-on échanger ? Des informations de synchronisation d’une base de données commune. Meteor rend ce type d’échange trivial : une API commune d’accès à la base de données, avec une couche d’abstraction. Une implémentation côté client de MongoDB, MiniMongo. Des connecteurs pour d’autres bases de données sont en cours, notamment Redis et Postgre. Les composants Meteor : https://www.meteor.com/livequery et https://www.meteor.com/mini-databases
18. Latency Compensation DDP permet d’aller plus vite que REST (socket), donc plus rapide (connexion établie, fenêtre TCP ouverte), mais il reste encore l’aller-retour serveur, temps incompressible. Compensation de latence : une extension du « rendu optimiste ». On simule sur le client ce qui sera fait sur le serveur, en supposant qu’aucune erreur ou réécriture n’aura lieu. Dans le cas où la valeur ne correspondrait pas, elle est corrigée dès le retour du serveur. Donne une sensation de très fortes performances. Composant Meteor : https://www.meteor.com/full-stack-db-drivers
19. Latency Compensation DDP permet d’aller plus vite que REST (socket), donc plus rapide (connexion établie, fenêtre TCP ouverte), mais il reste encore l’aller-retour serveur, temps incompressible. Compensation de latence : une extension du « rendu optimiste ». On simule sur le client ce qui sera fait sur le serveur, en supposant qu’aucune erreur ou réécriture n’aura lieu. Dans le cas où la valeur ne correspondrait pas, elle est corrigée dès le retour du serveur. Donne une sensation de très fortes performances. Composant Meteor : https://www.meteor.com/full-stack-db-drivers
20. Full Stack Reactivity Réactivité : pas un nouveau concept. Autre type d’explicitation d’une condition d’exécution d’un bloc de code. Autres implémentations : appel de méthode, événements. Par rapport à ces concepts alternatifs, il y a décalage de la responsabilité. Réactivité : le code exécutant explicite ses dépendances, plus clair, tout est au même endroit. Facilité en JS par les fermetures, rendu possible par les améliorations de performance du runtime. Le composant Meteor : https://www.meteor.com/tracker
21. Full Stack Reactivity Code ! https://github.com/sgmap/fiches-de-banc/blob/9df2f062fac6db665dd16937fa266c10d01c2975/client/views/common/footer.html#L3 https://github.com/sgmap/fiches-de-banc/blob/9df2f062fac6db665dd16937fa266c10d01c2975/client/views/common/footer.js#L4-L6
22. Embrace the Ecosystem Philosophie. Libre, intégrable avec d’autres éléments. En fait, une pile toute intégrée très puissante, mais surtout un assemblage de concepts déployables indépendamment, et remplaçables. Une métrique évidemment mauvaise : beaucoup de paquets pour la jeunesse du produit, mais l’immense majorité n’a aucun intérêt et est du bruit (au passage, le registre public Meteor a namespacé dès le début, contrairement à NPM, cf https://github.com/npm/npm/issues/798). Pour comparaison, classement par nombre de
    sur GitHub en juin 2015 : Meteor (10ème) : 25592
    ; Rails (9ème) : 26483
    ; Angular (3ème) : 39610
    ; Bootstrap (1er) : 82043
    .
23. Embrace the Ecosystem React, Polymer… Redis, Postgre… REST Événements Grunt, Gulp… Redis, Postgre… Philosophie. Libre, intégrable avec d’autres éléments. En fait, une pile toute intégrée très puissante, mais surtout un assemblage de concepts déployables indépendamment, et remplaçables. Une métrique évidemment mauvaise : beaucoup de paquets pour la jeunesse du produit, mais l’immense majorité n’a aucun intérêt et est du bruit (au passage, le registre public Meteor a namespacé dès le début, contrairement à NPM, cf https://github.com/npm/npm/issues/798). Pour comparaison, classement par nombre de
    sur GitHub en juin 2015 : Meteor (10ème) : 25592
    ; Rails (9ème) : 26483
    ; Angular (3ème) : 39610
    ; Bootstrap (1er) : 82043
    .
24. Embrace the Ecosystem React, Polymer… Redis, Postgre… REST Événements Grunt, Gulp… 5744 paquets Redis, Postgre… Philosophie. Libre, intégrable avec d’autres éléments. En fait, une pile toute intégrée très puissante, mais surtout un assemblage de concepts déployables indépendamment, et remplaçables. Une métrique évidemment mauvaise : beaucoup de paquets pour la jeunesse du produit, mais l’immense majorité n’a aucun intérêt et est du bruit (au passage, le registre public Meteor a namespacé dès le début, contrairement à NPM, cf https://github.com/npm/npm/issues/798). Pour comparaison, classement par nombre de
    sur GitHub en juin 2015 : Meteor (10ème) : 25592
    ; Rails (9ème) : 26483
    ; Angular (3ème) : 39610
    ; Bootstrap (1er) : 82043
    .
25. Simplicity Equals Productivity Philosophie. La prise en main donne vraiment cette impression, et la plupart des choses sont réellement simples. Cependant, le framework est encore jeune et il y a donc plusieurs petites incohérences. Et on paie évidemment toujours la magie d’une manière ou d’une autre… Référence sur la taille de ~/.meteor : https://github.com/meteor/meteor/issues/3614
26. Simplicity Equals Productivity Philosophie. La prise en main donne vraiment cette impression, et la plupart des choses sont réellement simples. Cependant, le framework est encore jeune et il y a donc plusieurs petites incohérences. Et on paie évidemment toujours la magie d’une manière ou d’une autre… Référence sur la taille de ~/.meteor : https://github.com/meteor/meteor/issues/3614
27. Simplicity Equals Productivity meteor add sgmap:assemblee-nationale Philosophie. La prise en main donne vraiment cette impression, et la plupart des choses sont réellement simples. Cependant, le framework est encore jeune et il y a donc plusieurs petites incohérences. Et on paie évidemment toujours la magie d’une manière ou d’une autre… Référence sur la taille de ~/.meteor : https://github.com/meteor/meteor/issues/3614
28. Simplicity Equals Productivity meteor add sgmap:assemblee-nationale Philosophie. La prise en main donne vraiment cette impression, et la plupart des choses sont réellement simples. Cependant, le framework est encore jeune et il y a donc plusieurs petites incohérences. Et on paie évidemment toujours la magie d’une manière ou d’une autre… Référence sur la taille de ~/.meteor : https://github.com/meteor/meteor/issues/3614
29. • Merci à Vianney Lecroart. • Icônes depuis Noun Project : Database CC-BY Leonardo Schneider, Server CC-BY Konstantin Velichko, Street CC-BY Mister Pixel, Paper CC-BY Tom Schott Merci ! Des questions ? Tech : @matti_sg France : @matti_sg_fr