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.
   

   View Slide

2. Meteor est un framework et environnement de développement d’applications web très ambitieux.
   Version 1.0 en octobre 2014.
   

   View Slide

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).
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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.
   

   View Slide

10. Data on the Wire
    
    [ ]
    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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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 .
    

    View Slide

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 .
    

    View Slide

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 .
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide