Retour d'expérience

Projet

  • Application mobile avec prise de photo, devis, et commande en ligne
  • Evolution avec l'apparition du site internet

Déroulement

  • Prototypage très rapide avec Meteor
  • Intégration plus délicate
  • Ré-orientation du projet avec un site mobile pour sortir le projet plus vite

Risques

  • Evolution de Meteor
  • Google
  • Méconnaissance de l'univers mobile

Alors

Boilerplate

  • Maison : hébergé sur le github de MeteorLyon

Templating

  • Blaze car peu de besoin technique
  • Souscription au niveau du template

 

Simple et rapide

Mais

Manque d'outils (helpers, syntaxe and/or...)

Routing

  • FlowRouter (pas de souscription du coup)

Google

  • getUserMedia sur HTTPS en cours de projet -> obligation d'avoir un serveur avec https
  • MediaStream en cours de projet -> caméra front utilisé par défaut
  • obligation d'avoir tout en HTTPS quand on fait un POST/GET HTTP depuis du HTTPS (ex. quand le user est sur le site de la banque)

Paiement mobile

  • sur site c'est facile, dans le mobile tu galèreras un peu
  • peu de retour d'XP sur du Atos SIPS + mobile

 

pourtant j'aurais bien aimé faire du Stripe ou du BrainTree

mdg:camera

  • incompatible avec les nouvelles contraintes de Google
  • pas assez flexible, simple pour démarrer, mais obligation de le ré-écrire pour en faire ce que l'on veut

 

Du coup faut mettre les mains dedans, et soit en refaire un, soit le modifier

Cordova

  • pb de configuration entre client et serveur :
    • meteor run --mobile-server http://myServerIP:myServerPort
    • build --server=http://myServerIP:myServerPort
  • nginx en frontal : penser à la redirection des websockets, et on a plus besoin du myServerPort
  • debugger : vérifier la variable globale __meteor_runtime_config__ qui contient les variables d'env et notamment DDP_CONNECTION_URI
  • android : build facile, mais il ne faut pas oublier de signer l'apk (euh c'est quoi un javaKeyStore ?)
  • debug, pas si évident que ça n'en a l'air (euh, pourquoi l'émulateur Android il ne se lance pas ?)

Cordova 2

  • emulateur, préférez OSx ou Windows car ils bénéficient de l'accélération intel, du coup l'émulateur est utilisable, sinon... (Donc faites un virtual device sous processeur Intel et pas ARM)
  • debug bis, Vive Chrome://inspect (pas avec crosswalk)
  • build, bien nettoyer votre repertoire de build avant, car ça peut foirer et vous laisser croire que c'est ok (enfin pas vraiment en fait)
  • crosswalk : attention il ne build pas au même endroit que le build traditionnel ! (buildTrad/build/outputs/apk/...

Mutualisation de code

server/client et donc ausi entre les applications mobile/desktop/admin : c'est vraiment top

Packages

  • certaines complexité dans la gestion des dépendances (que va t on exposer ? doit on exposer des packages utilisés via imply ?)
  • isolement des fonctionnalités, et partage de ces features

Librairies tierces

  • c'est vraiment top, mais ça demande un brin d'apprentissage
    • useraccounts : customisez l'authentification,
    • autoform : simplifiez-vous les formulaires,
    • simple-schema : sécurisez vos modèles,
    • collections-helpers : enrichissez vos collections,
    • mizzao:autocomplete : galérez bien
    • yogiben:admin : un back-office en une matinée
    • ...

HTML5 : Apple n'est pas ton ami

Le déploiement,
c'est laborieux :

  • passer de node 0.10.x à 0.12.x : bcrypt pose problème
  • nginx en frontal, ça passe presque, si on oublie pas de transférer aussi les websockets
  • supervisor c'est cool mais des fois ça bloque à la mise en place
  • en fait les variables d'environnement c'est pas cool (c'est mon sys-admin qui dit ça)
  • finalement un sys-admin dans l'équipe c'est cool, du coup maintenant on a des scripts de déploiement et il nous reste plus qu'à générer les confs supervisor à la volée
  • il nous reste la surveillance à mettre en place 
  • ReplicaSet : documentation non mise à jour pour MongoLab (base admin et local pour le RS)

L'heure du bilan