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 2016, signifie que des dizaines à des millions de personnes peuvent utiliser l'application. Une majorité de plateformes doivent être accessibles (ordis de bureaux, portables, tablettes, téléphones mobiles) de préférence à moindre coût et sans avoir à tout refaire pour chaque appareil.
Vivant dans un monde régi 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.
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
Concernant les ordis de bureau/portables, 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 peuvent 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
Le HTML peut s'avérer poser des problèmes de maintenabilité, notamment à cause de son manque de granularité et composabilité. Les standards émergents "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.
Handlebars permet d'écrire des morceaux de templates, de les composer ensemble et de les nourrir en données.
Maturité : 5/5
Créée par Facebook, cette technologie prometteuse se base sur la notion de composant visuel et va 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çues en évitant un problème de performance appelé layout thrashing Vidéo
Maturité : 5/5 (utilisé par Facebook en production aujourd'hui)
Comme le code, le CSS est difficile à maintenir sans y consacrer temps, énergie et discipline. 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
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 semble avoir trouvé un bon équilibre.
Maturité : 4/5
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.)
Prendre un photo ou vidéo, enregistrer un son ou une image dans une application web. Tout dépend du navigateur.
JavaScript est assez 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.
Concernant les débats sur l'application mobile HTML5 de Facebook, les ingénieurs de Sencha ont démontré que l'application était mauvaise à cause de certains mauvais choix de Facebook et non à une limitation de la technologie web mobile.
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
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
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é et performance (cache HTTP), tant son support est fiable 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.
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 et inconvénients en terme de bibliothèques, performance, réactivité de la communauté, sécurité, etc. Tout est question de culture de votre équipe. La grande majorité des applications en J2EE souffrent des problèmes des organisations qui les font naître (lenteur et rigidité), tout comme PHP qui souffre de l'extrême inverse (risques et fragilité). Toutes les technologies récentes mettent un point d'honneur à fournir non seulement une solution technique, mais un outillage complet. Les valeurs de la communauté finissent par s'y retrouver. La base technologique est réelle mais n'est pas à blâmer pour le tout : quand l'outil n'est pas adapté au besoin, on peut aller loin en déviant de son usage prévu, mais ça devient de plus en plus dur.
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.
Dans des cas très spécifiques, il est intéressant de croiser avec l'usage : a-t-on une topologie et des besoins particuliers (base de données de graphe), veut-on majoritairement écrire ou lire (base de données "de logs")... De plus, vous trouverez plus facilement des équipes ou des offres qui maîtrisent le sujet, au lieu de devoir chercher des compétences rares.
Tout cela, c'est une fois que vous avez une application qui grandit énormément : tenter d'anticiper ces besoins est plus souvent un piège qu'autre chose, et comme l'optimisation de code, ça n'a de sens qu'une fois que vous saurez où sont les limites de votre solution actuelle.
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 peut être complexe et le volume modéré.
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.
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).
MongoDB n'est pas conseillé pour ce genre de cas d'utilisation. MongoDB est utile pour des données peu structurées par exemple.
Différentes options de PostGreSQL suffisent pour disposer de presque tous les avantages de MongoDB. Faites attention à ne prendre ce genre de décisions qu'en connaissance de cause.
Ici, les données sont simples, mais très volumineuses (gros fichiers). Il s'agit de fichiers type résultats scientifiques, imagerie médicale, etc.
Utiliser une des bases de données précédentes n'est pas forcément le bon choix. On pourra se diriger tout simplement vers un système de fichiers classique. Ça permettra notamment de garantir l'utilisation de streams pour traiter le gros fichier par petit bouts côté applicatif.
Ce document rédigé principalement par David Bruant est sous licence Creative Commons 0