Le retour de l'informatique client-serveur?

L’une des choses que j’ai trouvée intéressante dans le monde du développement au cours des derniers mois est la façon dont les applications modernes reviennent à placer davantage d’intelligence dans le client plutôt que dans le serveur. Le modèle client-serveur n’est certes pas nouveau: c’est la façon dont les applications traditionnelles ont été construites pendant des années, les applications clientes riches communiquant avec les applications côté serveur. Mais à l'ère du Web, et même du Web 2.0, l'accent a été mis sur les applications Web dans lesquelles l'intelligence était concentrée sur le serveur Web (généralement dans les serveurs d'applications basés sur Java) et le client n'était qu'une simple page Web dans un navigateur où chaque fois que vous avez cliqué, vous avez chargé une nouvelle page.

Mais récemment, la maturation de HTML5, CSS et plus particulièrement de JavaScript amène les développeurs à mettre en place une véritable intelligence et un réel traitement dans la page Web elle-même. Nous avons notamment assisté à la montée en puissance de nombreux frameworks JavaScript côté client facilitant la création de frontaux intelligents entièrement exécutés dans un navigateur Web moderne. Les navigateurs impliqués sont généralement ceux basés sur le moteur Webkit, y compris Chrome et Safari, mais la plupart des applications semblent également fonctionner correctement dans les versions actuelles de Firefox et Internet Explorer. Vous vous retrouvez avec une page Web plus complexe qui change de façon dynamique, en extrayant les données du serveur en fonction des besoins.

Trois frameworks MVC en particulier semblent attirer l'attention: Backbone.js, Ember.js et Angular.js. (MVC signifie model-view-controller - c'est essentiellement l'architecture derrière l'informatique client Web. Le "js" signifie JavaScript.) Il s'agit essentiellement d'un prolongement de l'approche AJAX (JavaScript et XML asynchrones) populaire au cours de la dernière décennie ou oui, mais en devenant beaucoup plus mature et presque standardisé. L'idée est de mettre davantage d'informations sur l'état et l'intelligence dans le navigateur, puis de le connecter avec les API REST côté serveur.

Backbone est peut-être le plus fondamental et le plus minimal de ces frameworks; il est utilisé à divers degrés par de nombreux sites populaires. Ember est né d'un framework appelé Sproutcore pris en charge par Apple. Il s'agit d'un framework beaucoup plus complet conçu pour vous permettre de réaliser des applications de type bureau. Il est souvent utilisé avec Bootstrap, un ensemble de modèles pour HTML et CSS créés à l'origine par les employés de Twitter. Angular est l'alternative de Google qui semble se situer quelque part entre les deux. Certaines personnes pensent qu'il est un peu plus flexible ou au moins "moins nuancé" qu'Ember mais plus complet que Backbone. (Remarque: Google encourage les développeurs à utiliser Angular pour améliorer la qualité du codage, mais utilise en interne un ensemble différent de cadres propriétaires.) Même Microsoft a ajouté des points d'ancrage dans Visual Studio pour ces cadres.

Ceci étant le Web, il existe des dizaines d’alternatives. Meteor est l'un des plus intéressants dont j'ai entendu parler récemment. Il est conçu pour fonctionner avec JavaScript, tant du côté client que du côté serveur. Mais cela est encore très tôt et je ne connais pas encore de vrais utilisateurs. Entre-temps, de plus en plus de développeurs jouent avec Node.js, souvent utilisé pour les implémentations JavaScript côté serveur.

L'avantage de tels cadres semble évident. Les applications client Web riches sont plus puissantes que les applications client léger où tout est exécuté sur le serveur, elles peuvent fournir une meilleure interface utilisateur et offrir la possibilité d'informations en mode hors connexion. En utilisant ces frameworks, vous pouvez créer des applications client Web riches beaucoup plus rapidement que vous ne le feriez en construisant tout à partir de zéro et en tirant parti des communautés se développant autour de chacune d'entre elles.

Peut-être plus important encore, vous pouvez créer des applications mobiles qui s’adaptent à différents appareils sans avoir à écrire d’applications natives spécifiques. Il reste encore un bon argument à faire pour les applications natives, qui peuvent plus directement traiter les caractéristiques spécifiques de chaque plate-forme. Cependant, de nombreux développeurs ont constaté que de tels frameworks pouvaient accélérer considérablement le développement multi-plateformes, en particulier lorsqu'ils étaient utilisés conjointement avec PhoneGap, un framework mobile open source acheté par Adobe et open-source dans le projet Apache Cordova.

Mobile, bien sûr, a ses propres limites, y compris la rapidité des processeurs, et peut-être plus important encore, la rapidité et parfois le manque de connectivité. L'une des raisons pour lesquelles les gens aiment les applications sur les pages Web est que vous pouvez souvent télécharger les fonctionnalités de base via Wi-Fi ou une connexion rapide et obtenir simplement les données dont vous avez besoin téléchargées, et non la totalité du design. Des paquets tels que PhoneGap résolvent ce problème en mettant le JavaScript dans une application téléchargée.

Il existe toutefois d'autres problèmes avec de tels cadres. Par définition, utiliser davantage d’informatique côté client augmente la complexité par rapport à une simple application réservée aux serveurs. En effet, certains des inconvénients de l’ancien modèle client-serveur se reproduisent. Les développeurs doivent gérer l’état des deux côtés. Le code à deux endroits signifie que vous devez vous concentrer sur la sécurité dans les deux endroits. Puisqu'une équipe de développement a souvent des personnes travaillant sur le client et d'autres sur le serveur, vous rencontrez des problèmes de communication supplémentaires. Par contre, certains des problèmes les plus anciens de client-serveur ne reviennent pas et vous gardez les avantages du logiciel Web. C’est un monde beaucoup plus axé sur les normes et la communauté, vous ne devez donc pas être aussi dépendant d’un seul environnement propriétaire. En scindant les parties client et serveur, vous pouvez également obtenir une implémentation serveur plus propre et plus simple, qui effectue simplement le traitement et non l'interface utilisateur, ce qui peut nécessiter moins de ressources. Pourtant, vous avez toujours l’avantage de pouvoir mettre à jour tous les clients en même temps, car en général, le navigateur charge le code à partir du serveur lorsque l’application est invoquée.

Nous constatons clairement une évolution vers des clients Web plus intelligents - pas dans tous les cas, mais dans de nombreuses nouvelles applications. Il est beaucoup plus difficile de prendre des applications plus anciennes et de les transférer dans ce modèle, mais nous en voyons aussi une partie. Ce n'est pas tout à fait l'ancien modèle client-serveur, mais il se rapproche beaucoup.