Skip to content

Instantly share code, notes, and snippets.

@DavidBruant
Last active June 3, 2018 22:08
Show Gist options
  • Save DavidBruant/8519103 to your computer and use it in GitHub Desktop.
Save DavidBruant/8519103 to your computer and use it in GitHub Desktop.
Guide pratique à destination des preneurs de décisions pour faire des applications partagées pérennes disponibles sur une majorité de plateformes

Problème

Créer des applications partagées pérennes qui peuvent être déployées à grande échelle.

Partagées signifie que différents utilisateurs vont pouvoir interagir et "travailler" ensemble sur l'application

Grande échelle, en 2013, signifie que des dizaines à des millions de personnes peuvent utiliser l'application. Une majorité de plateforme doit être accessibles (ordis de bureaux, portables, tablettes, téléphones mobiles) de préférence à moindre coût et donc sans avoir à tout refaire pour chaque appareil. Vivant dans un monde régit par certaines lois physiques, il sera raisonnable de supposer que le réseau de communication est au pire ouvert. La sécurité de l'application ne devra pas supposer le contrôle du réseau, même dans si l'environnement de déploiement est considéré contrôlé.

Pérennes signifie que l'arrivée de nouveaux appareils sur le marché ne remet pas en cause plus de 1% du temps de développement. Personne ne peut prévoir le futur ; il conviendra de garder un œil ouvert sur les tendances hardware/OS.

Dans beaucoup de cas, une seule organisation créé l'application ou en a la responsabilité. La disparité des terminaux dans les mains des utilisateurs suggère des problèmes de sécurité si les terminaux possèdent trop d'autorité. On préfèrera une architecture avec un serveur central (on peut évidemment avoir plusieurs machines physiques), seule source de vérité et de confiance. Des applications "clientes" seront déployées sur les terminaux des utilisateurs et interagiront avec le serveur.

Solution

Une fois la contrainte architecturale posée, il convient de faire 3 choix :

  • technologie(s) des applications clientes
  • technologie(s) de l'application serveur
  • protocoles de communication

Technologie(s) des applications clientes

Concernant les ordis de bureau/portable, il serait stupide de prétendre que le navigateur web n'est pas la plateforme de choix. Les tablettes et mobiles ont d'autres contraintes. Si ces appareils possèdent un navigateur, les utilisateurs ont une tendance à préférer les "apps" (iOS/Android), même si celles-ci ne présentent parfois aucune différence technologiques et ont seulement une différence d'accès (clic sur une icône au lieu d'une recherche dans l'historique). Des technologies comme Apache Cordova (anciennement PhoneGap) permettent de packager des applications écrites en HTML+CSS+JS en applications "natives" iOS, Android ou autre.

Autre piste pour Android. Pour iOS, il est aussi possible de créer un signet depuis Safari vers l'écran d'accueil

Meilleurs HTML

Le HTML peut s'avérer poser des problèmes de maintenabilité, notamment à cause de son manque de granularité et composabilité. Les standards émergeant "Web Components" sont prometteurs, mais ne sont pas encore suffisamment supportés par les navigateurs. Des technologies s'occupent d'améliorer cet état de fait.

Templates "stateless"

Handlebars permet d'écrire des morceaux de templates, de les composer ensemble et de les nourrir en données.

Maturité : 5/5

React.js

Créée par Facebook, cette technologie prometteuse se base sur la notion de composant visuel et va donc un peu plus loin que les templates HTML. Typiquement, une checkbox est un composant visuel avec un état et on s'attend à ce que cet état soit géré au sein du composant visuel et pas ailleurs. Pour les applications très dynamiques, ReactJS permet d'obtenir de meilleures performances perçue en évitant un problème de performance appelé layout thrashing Vidéo

Maturité : 5/5 (utilisé par Facebook en production aujourd'hui)

Meilleurs CSS

Le CSS est extrêmement dur à maintenir et les gros projets tendent à avoir une seule feuille CSS où chaque page en utilise une minorité. Les préprocesseurs CSS comme SASS (+Compass) ou LESS aident à modulariser le CSS et le rendre plus maintenable (via l'utilisation de variables et mixins notamment)

Maturité (SASS/LESS) : 5/5

Meilleurs JavaScript

TypeScript

Technologie développée par Microsoft. Elle apporte certaines parties de syntaxes d'ECMAScript 6 (prochain standard de JavaScript) et une vérification de types. Contrairement à une technologie comme Closure Compiler qui force un peu le style d'écriture du code, TypeScript a trouvé un bon équilibre entre laisser les développeurs écrire le code comme ils veulent

Maturité : 4/5

Limitations

Hors ligne

Le hors ligne n'a pas été le fort des applications web initialement. Des technologies comme IndexedDB permettent d'écrire des applications web qui sauvegardent les données localement et les synchroniser plus tard. Les technologies pour faire ça (Appcache notamment) ne sont pas toujours adaptées pour rendre cette partie facile. D'autres technologies (ServiceWorker) émergent doucement pour rendre cet aspect plus facile à développer.

L'aspect hors ligne est possible, mais dur à développer aujourd'hui et pose parfois des problèmes mineurs d'expérience utilisateur (avoir à recharger la page, etc.)

Tout ceci devrait arriver à maturité vers début 2015.

Média

A l'heure actuelle, il n'est pas vraiment possible de prendre un photo, enregistrer un son ou une image dans une application web. Ce genre de fonctionnalités arrivent avec la technologie WebRTC. A titre expérimental, Firefox et Chrome supportent cette technologie, mais la maturité n'est pas encore là.

On peut s'attendre à un bon niveau de maturité vers fin 2014

Mythe : performance

JavaScript est rapide. On est désormais capable de compiler un million de lignes C++ d'un jeu en 3D et le faire tourner à 60fps en JavaScript. Il n'y a pas de lenteurs inhérentes à JavaScript ou aux navigateurs comme il pouvait y avoir il y a 10 ans.

De manière anecdotale, pour implémenter la bibliothèque standard de JavaScript, les navigateurs remplacent leur C++ par du JavaScript, prouvant que JavaScript n'a pas grand chose à envier à C++ en terme de performance.

Concernant les débats sur l'application mobile HTML5 de Facebook, les ingénieurs de Sencha ont démontrés que l'application était mauvaise dus à certains mauvais choix de Facebook et non pas à une limitation de la technologie web mobile.

Mythe : pas de boussole

Il existe l'API orientation qui donne accès au gyroscope. Voir : http://www.html5rocks.com/en/tutorials/device/orientation/ http://www.w3.org/TR/orientation-event/ Support navigateur (dont mobile) : http://caniuse.com/#feat=deviceorientation

Mythe : pas de GPS

L'API de geolocation est disponible depuis longtemps. Voir :

https://developer.mozilla.org/en-US/docs/Web/API/Geolocation http://www.w3.org/TR/geolocation-API/ Support navigateur (dont mobile) : http://caniuse.com/#feat=geolocation

Protocoles de communication

Pour l'énorme majorité des cas d'utilisation, HTTPS servant du HTML ou du JSON compressé via gzip ira très bien pour couvrir les besoins de sécurités et performance (cache HTTP), tant son support est fiables sur la majorité des plateformes. Pour des besoins plus spécifiques de temps réel, on pourra utiliser descendre au niveau TCP (ou WebSockets dans un navigateur) échangeant des données binaires.

Coté serveur

Côté serveur, on pourra choisir l'un différents frameworks web comme Python + Django, Node.js + express, Ruby on Rails, Java/Scala + Play Framework. Ils ont chacun des avantages, inconvénients en terme de bibliothèques, performance, réactivité de la communauté, sécurité, etc. Le web a grossit avec PHP et les applications J2EE. Même s'il est possible de faire de très bonnes applications dans ces technologies, on remarque une tendance des applications PHP à être des passoires en sécurité et les applications J2EE de ne pas être synonyme de performance. Si les technologies ne sont pas à blâmer directement, il semble qu'elles encouragent naturellement des pratiques de développement qui amènes aux constats précédemment évoqués.

Stockage de données

Il y a deux dimensions pour prendre en compte pour choisir un type de base de données : la complexité des données (les données sont-elles fortement inter-connectées les unes aux autres ?) et le volume de données.

Données applicatives

Les données à stocker sont par exemple des comptes utilisateurs. Ces utilisateurs ont des interactions entre eux et manipulent un nombre restreint d'objets (commentaires, préférences). Le modèle de données va être complexe et le volume modéré.

Bases de données graphes

Les bases de données graphes comme Titan sont prometteuses, mais pour l'instant trop instables pour être fiables en production, à l'exception peut-être de Neo4J. Neo4J souffre de son côté de sa licence AGPL aux termes confus quant à savoir si l'application que vous développez avec Neo4J vous appartient ou leur appartient. Peut-être qu'OrientDB est assez mature. Dans tous les cas, se reposer sur Blueprint.

SQL

Un bon vieux SQL fonctionne bien et sera sûrement le meilleur choix jusqu'à ce que les bases graphes arrivent à maturité. Côté open source, on pourra choisir PostgreSQL ou MariaDB (fork de MySQL après le rachat de Sun par Oracle).

Un mot sur MongoDB

MongoDB n'est pas conseillé pour ce genre de cas d'utilisation. MongoDB est utile pour des logs peu structurés par exemple.

Grosses données

Ici, les données sont simples, mais très volumineuses (gros fichiers). Il s'agit de fichiers type résultats scientifique, imagerie médicale, etc.

Utiliser une des bases de données précédente n'est pas forcément le bon choix. On pourra se diriger tout simplement vers un système de fichier classique. Ca permettra notamment de garantir l'utilisation de streams pour traiter le gros fichier par petit bout côté applicatif.

Licence

Ce document rédigé principalement par David Bruant est sous licence Creative Commons 0

@0gust1
Copy link

0gust1 commented Jan 28, 2014

Bonjour,

Mon client actuel (comme beaucoup d'autres) se pose ce genre de questions. Je m'intéresse également à React (en ce moment "ils" sont en débat React vs Angular... hum.). Et c'est surtout le "pérenne" qui m'interpelle dans ta phrase de problématique.

Bref, concernant React (qui m'intéresse suffisamment pour que j'ai envie de jouer avec), je me pose plusieurs questions (que je me pose pour toute nouvelle techno) :

  • "past-proof" ? Le coût de temps machine / mémoire additionnel, coté client (puisque react semble gérer son propre DOM, plus pas mal de choses). Comment se comporte React sur un "vieux" smartphone, une vieille machine, une vieille machine + un vieux nav ?
  • ticket d'entrée vs bénéfices ? Arriver à évaluer à partir de quand une appli devient suffisamment grosse, suffisamment "temps réel", et suffisamment complexe, niveau UI (data-binding, comportements liés, asynchronicité) pour que le bénéfice de React soit flagrant
  • future-proof ? Evaluer si React est un outil qui vieillira bien (développement, communauté) et pas seulement une techno transitionnelle, voire morte-née (genre GWT... pardon, j'ai trollé ^^).

@vjeux
Copy link

vjeux commented Jan 28, 2014

@0gust1:

past-proof

Le principal gouffre de performance d'une application classique se situe dans la manipulation du DOM. React passe un peu plus de temps en JS mais réduit le temps passé dans le DOM de façon beaucoup plus significative. Cet effet est d'autant amplifié que plus le navigateur est vieux, moins il a d'optimisations sur le DOM.

Pour ce qui est de la compatibilité, React fonctionne jusqu'à IE8 et la majorité des smart phones qui supportent JavaScript.

Ticket d'entrée vs Bénéfices

React n'est pas un gros framework comme Angular, Ember ... Il faut plutôt le voir comme jQuery. C'est une bibliothèque de manipulation du DOM. Il s'intègre très bien avec plein de bibliothèques et des applications existantes.

La façon de construire ton application via des composants est bénéfique dès le début. Il n'y a pas besoin de faire quelque chose de complexe pour que cette structure du code soit agréable :)

Future-proof

Facebook, Instagram et Khan Academy sont convertis à React. Des personnes connues font l'apologie de React:

Je ne vois pas l'avenir mais je pense pas me tromper en disant que React ne va pas mourir demain.

@0gust1
Copy link

0gust1 commented Jan 29, 2014

un grand merci @vjeux pour ta réponse.

J'ai pris un peu le temps hier soir de regarder la doc et de jouer (très très rapidement) avec, je comprends mieux la philosophie et le périmètre de la librairie. ça m'a fait penser à KnockoutJS sur certains points (notamment par l'orientation assumée "bibliothèque" plutôt que framework ; ce que je trouve très séduisant).
Je trouve aussi l'idée du DOM virtuel très très maligne, je suis plus réservé sur JSX, mais ça donne un code très lisible et simple. Encore merci pour le "débroussaillage".

Pour les lecteurs éventuels, ci-dessous 2 liens supplémentaires qui m'ont également aidé à mettre les choses en contexte :

http://skulbuny.com/2013/10/31/react-vs-angular/

http://programmers.stackexchange.com/questions/225400/pros-and-cons-of-facebooks-react-vs-web-components-polymer

@DavidBruant
Copy link
Author

TODO mettre à pour partie sur Phogap/Cordova https://medium.com/dev-rocket/phonegap-cordova-the-story-c4064bd7d802

@abelards
Copy link

abelards commented Jan 6, 2016

Bonjour, merci pour ce texte clair et efficace !
Quelques remarques si cela vous tente de les intégrer (je peux forker pour quelques typos corrigées aussi) :

  • La préférence des apps natives n'est plus forcément garantie.
  • Je ne suis pas sûr que l'utilisation par Facebook soit un marqueur de maturité, même si pour le coup React semble l'être.
  • Le CSS n'est pas difficile "per se" mais, comme le code, on peut faire un gros tas de spaghetti.
  • "TypeScript a trouvé un bon équilibre entre laisser les développeurs écrire le code comme ils veulent"... et quoi ?
  • Je pense que le Offline est plus dur à spécifier qu'à coder (qui a raison en cas de désaccord & ergo de rattrappage / dédoublonnage).
  • Média : de plus en plus d'applis Web peuvent prendre des photos ou voir une webcam. Je n'ai pas de techno testée / à recommander.
  • Je suis pour retirer l'anecdote de perf car c'est un tradeoff qui n'a pas grand chose de techique et est plus orienté UX.
  • "Le web a grossi avec PHP et les applications J2EE." [citation needed] je crois qu'on oublie Perl, Lisp, C++ notamment.
  • Il y a vraiment de plus en plus d'articles anti-Mongo mais aussi plus de DB "NoSQL". Les DB "Cloud" aussi changent le jeu.
  • Je propose de retirer la section BDD graphes (qui n'est pas si fréquent finalement) au profit d'une simple ligne parlant des BBDs "à usage spécifiques" comme graphes, logs, et peut-être même optimisés recherche / indexation, stats / BI...

En tout cas merci, ça fait du bien de lire quelque chose de clair et qui se veut argumenté.
Et bravo d'avoir pris des partis qui ont peu changé entre 2012 et 2016 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment