meteorjs

Les applications web ré-inventées

(v 0.7.0.1)

Twitter: @Rebolon

GitHub: http://github.com/Rebolon

Lead-Dev chez Peaks

Avant tout

Fermez les yeux
Respirez un grand coup
Oubliez NodeJS
Oubliez Angular
Acceptez la différence
Ouvrez les yeux

On peut démarrer !

CHIFFRES

Angular : 01/2010 - 635 contrib - 972 issues - 16192 repo
Ember : 04/2011 - 322 contrib - 141 issues - 4008 repo
Meteor : 11/2011 - 98 contrib - 330 issues - 4771 repo

tendances google

Au 06/02/2014

Meteor C'est quoi ?

Un exemple est plus parlant

http://lyonjs.meteor.com

LES origineS Du Web

(enfin, pas tout à fait quand même)

TECHNOS

Server-side : CGI, ASP, PHP, JEE, ...
Client-side : HTML, Javascript, CSS, ...

Principe

HTTP Request
Process server-side
HTTP Response
Process client-side (dom rendering, js processing)

AvantageS

Ca marche, et plutôt bien
Traitement côté serveur = charge client légère

Inconvénients

La génération de l'affichage se fait côté serveur
1 requête = 1 réponse avec tout dedans (enfin presque)
La réponse est difficilement adaptée à chaque type de client (poste fixe / smartphone / tablette / ...) et le responsive Design ne résoud que partiellement ce problème

Et ça fait 15 ans qu'on fonctionne comme ça

(enfin presque)

2005-2007

Légère évolution

(avec le fameux web 2.0)

XML Http Request

Wouahou, j'ai trouvé un truc dans le navigateur, on va l'appeler WEB 2.0 !

Le client embarque une couche JS pour communiquer avec le serveur (parce qu'en natif, XML HTTP Request, c'est pénible)
On transfère moins de données sur le réseau
On fait beaucoup plus de requêtes HTTP
On fait de plus en plus de JS

Problèmes

Certains renvoie du HTML [no comment]
Pas de standard sur la façon de structurer son appli JS

Résultats

Problème de maintenances
Pas de test
Code difficilement réutilisable

Et,

Ca donne pas envie

Bienvenue en 201X

Javascript Frameworks

Client-side

Angular
Ember
...

Server-side

Express
"Vanilla" NodeJS

BOTH-side

Derby
SocketStream
TowerJS
Meteor
SailJs
...

Et il est où JQuery ?

Principes

Le server envoie le framework au client et un DOM light
Le client exécute l'application
L'application démarre les listeners et construit l'affichage
L'application va faire des appels serveur
Le serveur ne renvoi que des données (JSON)
L'application reconstruit les templates requis

Avantages

Application plus structurée (arbo de fichier, gestion des événements...)
Bande passante requise très légère
L'application Js peut être cachée par le navigateur (le serveur indique au démarrage si une nouvelle version est disponible via un manifest)
Potentiellement les données peuvent être cachées
Réduit les problèmes de latence et de ré-exécution du JS sur le mobile (single-page-webApp)

Inconvénients

Application événementielle qui change donc les habitudes de travail d'une équipe de développeur web classique
Souvent :

programmation événementielle = spaghettis de callbacks

Le poste client travaille beaucoup (processeur et mémoire)

Et Puis

Faire faire du JS à un dèv ça donne ça :

Mais alors, Pourquoi MeteorJS ?

http://blog.discourse.org/

Jeff Atwood: co fondateur de StackOverflow

Meteor

Framework client et serveur
API cohérente entre client et serveur
Back-End sur NodeJS
Programmation Reactive
Linux, Mac et Windows (enfin presque)
IE7+, FF, Chrome, Opera (mobile), mais mieux vaut utiliser les dernières versions
Architecturé en package (bootstrap, accounts, backbone, amplify...)
Industrialisé (déploiement, packaging, package repository...)
Et SIMPLE !

Attention

Toujours en beta (0.7.0.1)
Très jeune (juste 2 ans)

Mais

C'est vraiment cool
Développement très rapide
Code est très structuré
Communauté très active :

De plus en plus de conférence autour de MeteorJs (Berlin, Hambourg, Amsterdam, London, USA ...)
Nombreux projets : MySql, PostgreSql, AngularJs, LoadBalancer, Clustering, DataCache, Audit de code
Très bonne littérature sur le sujet

Et

Derrière Meteor se trouve une petite équipe américaine
Ils viennent presque tous du MIT
Certains sont enseignants au MIT ou dans d'autres campus
Levé de fonds en juillet 2012

Au final, c'est un peu comme Sensio avec Symfony, mais avec plus d'argent et une vrai Révolution en ligne de mire

L'équipe au complet ici

Inconvénients

MongoDb only (des alternatives non officielles existent mais souvent non réactives)
Fibers mandatories
Pas de web-components (ça devrait arriver)

Concrètement

Installation

curl https://install.meteor.com | /bin/sh

Création de l'appli

 meteor create lyonJS && cd $_

Ca y est !

En dèveloppement :

Instance Mongo automatique
Instance Node automatique

Mais encore

je veux ajouter bootstrap :

 meteor add bootstrap

Liste des packages disponibles en natif

(coffeescript, underscore, ...)

authentification

meteor add accounts-basemeteor add accounts-uimeteor add accounts-password

// et oumeteor add accounts-facebookmeteor add accounts-twitter
meteor add accounts-github
meteor add accounts-google
meteor add accounts-meetup
meteor add accounts-weibo

[step0]

Et alors, On continue ?

Organisation du code

Quick and dirty : tout dans un fichier js + méthode Meteor.isClient / isServer [master]

Better way : des répertoires séparés (client / server / public / autres) [step1]

Yeoman est ton ami

npm install -g meteorite
npm install -g yo
npm install -g generator-meteor
mkdir your-new-project && cd $_
yo meteor[...]meteor update && meteor

Et voilà une belle structure Meteor, toute prête

TempLATE Handlebar

<body>
  {{> error}}  {{> list}}
</body>
<template name="error">
  {{getError}}
</template>
<template name="list">
  <h1>Votez pour un sujet</h1> {{loginButtons}}
  <ol id="listSubjects"> 
  {{#each subjects}}
    <li>{{> subject}}</li>
  {{/each}}</ol>
  {{#unless subjects}} Aucun sujet en cours.{{/unless}}
</template>

HeLpers

 if (Meteor.isClient) { // useless if code in client folder
  Template.error.helpers({
    getError: function () {
	return Session.get('error');
    }
  });
}

Réactivité

Au niveau local : les Session, et le package Deps

 
Session.set('error','Arrgh erreur interne inconnue');

test sur http://lyonjs.meteor.com et la console

Au niveau online : DDP (Collections, Streams)

 
Subjects = new Meteor.Collection('my-subjects');Subjects.insert({label: "LyonJS like Meteor"});

Persistence

MongoDB (serveur) et le package MiniMongo (client)

Subjects = new Meteor.Collection('my-subjects');

Subjects.insert({label: "LyonJS like Meteor"});
Subjects.update(myId, {$set: {aNewField: itsValue}});
Subjects.remove({_id: oneId});
Subjects.find().forEach(function(item) {console.log(item);});

Disponible côté Client Et/Ou Serveur

Evenements

 Template.list.events({
    'focus #fldNewSubject' : function funcCleanEror() {
	Session.set('error', '');
    },        'click #btnNewSubject': function funcDisplayLog() {        Subjects.insert({label: whatEverYouWant});    });

Evénements disponibles:

focus, click, keyX, mouseX ... + selector

MethodEs

 Meteor.methods({
     rmSubject: function funcRmSubject(id) {
         var user = Meteor.user(),
	     subject = Subjects.findOne({_id: id});

         if (this.isSimulation) console.log('client-side only');
         if (!isAdmin())
             return new Meteor.error(403, 'Suppression de sujet réservé aux admins.');
	 if (!subject)
              return new Meteor.error(404, 'Sujet non trouvé, suppression impossible');

	 return Subjects.remove(id);     }
});

Et ce code peut être commun au client et serveur : gain de temps pour le controle de vos formulaires

Latency Compensation

MiniMongo
isSimulation dans Meteor.Methods

Test fonctionnel

Projet Laika

// installationsudo npm install -g laika
// nouvelle instance de MongoDb
mongod --smallfiles --noprealloc --nojournal
// installer phantomJssudo npm install -g phantomjs

Déploiement EN TEST

Pour déployer son application sur http://lyonjs.meteor.com

 meteor deploy lyonjs

Si vous avez plus simple,
je suis preneur

Déploiement en Prod

Utiliser Phusion Passenger : tuto ici

Ou pour déployer son application sur son serveur node

 meteor bundle lft

Setter

les variables d'environnements

MONGO_URL
ROOT_UL

Et après ?

Node a son Npm, Meteor a Meteorite (sera intégré bientôt)

npm install -g meteorite

Et remplacez la commande "meteor" par "mrt"

Fibers

C'est la base de Meteor côté serveur,

mais on peut ne pas s'en soucier

Développer "synchronous way" mais "non-blocking"
Garder donc l'event-loop fonctionnel

Plus d'infos ici

Synchrone ou Asynchrone ?

API

Meteor.Collection.[insert/update/remove] : au choix
Meteor.methods : asynchrone sur le client, au choix sur le serveur

Tools

Fibers/Futures
_wrapAsync

Développer facilement

Avec Nitrous.io et leur "parts"

Créez-vous un compte Nitrous.io, puis

parts install meteor

Ca y est vous avez un environnement opérationnel

Amélioration de notre appli

Ajout de la sécurité [step2]

 mrt remove insecure// Et gérer la collection avec les méthodes Allow / Deny

Gestion du publish / subscribe [step3]

 mrt remove autopublish

Utilisation d'un Router : tuto ici [step4]

 mrt add iron-router

Ajout de fast-render [step4.1]

 mrt add fast-render

TESTER NOTRE APPLI

Faire un package LyonJS

mkdir monApp/packages/lyonJS && cd $_touch package.js smart.json lyonJS.js lyonJStests.js

Le tester :

cd monApp/packages/lyonJSmeteor test-packages ./

Tester la réactivité avec Laika

[step5]

Alternative à notre appli

Ne plus passer par Mini-mongo mais par les "methods"

 // remplacer les insert/delete/update client-side par :Meteor.call('addSubject', [params]);Meteor.call('rmSubject', [params]);
Meteor.call('voteUpSubject', [params]);
Meteor.call('voteDownSubject', [params]);

[step6]

Meteor en 2014

Meteor.UI : le nouveau moteur de rendu

Galaxy : un hébergement professionnel

La v1.0.0

Et peut être

Déploiement multi-fournisseur

Mini-Sql ?

Meteor pour tout ?

Potentiellement oui, mais :

Moins bien adapté aux sites statiques
Architecture node moins adapté au traitement processeur lourd (quoique ici l'auteur dit le contraire : Go)
Inconvénient de la dépendance à Mongo, surtout pour vos projets existants