[Devoxx FR 2012] – HTML5 & Java – Vers des applications client / serveur ?

 

James Ward (développeur Evengelist chez Heroku) nous présentait durant ce Devoxx France sa vision du futur de nos applications web. A l’écouter, les outils d’aujourd’hui nous orientent de plus en plus vers le développement d’applications de style client / serveur.
Mais qu’est-ce qu’une application Web moderne ?

Principalement une application dont le tiers de présentation a progressivement glissé vers le navigateur. Le tiers de présentation tel qu’on pouvait le connaître auparavant avec les Jsp, Facelets, etc … se réduit de plus en plus à une simple couche de serialization qui traite les allers / retours asynchrones du navigateur.

Ce glissement vers un tiers de présentation réduit et stateless permet notamment :

• de faire une séparation plus nette entre les développements à destination du client (navigateur) et ceux destinés au serveur. Ce découplage plus important permet donc des montées en version plus rapides car il n’est plus nécessaire  d’attendre des évolutions prenant en compte les deux aspects simultanément.
• d’obtenir une meilleure scalabilité de ce tiers car plus simple.
• de mettre en place des stratégies de Continuous Delivery qui mettent à jour l’un après l’autre les serveurs sans couplage entre eux.

La mise en oeuvre de ce type d’applications est grandement simplifiée par l’utilisation d’architectures de type REST qui sont aisément déployables sur le Cloud, contrairement aux architectures statefull qui rencontrent parfois des freins à leur montée de version.

Pour rappel, une architecture REST repose sur les principes suivants :

• URLs claires et formatées. Elles doivent permettre de nommer et d’identifier une ressource.
• Les opérations HTTP suffisent (GET, POST, PUT, DELETE).
• Stateless c’est à dire sans état.
• Basée sur les standard du web (HTTP, XML).

Le slogan Write Once Run Anywhere, cher aux pionniers de Java prend également tout son sens avec ce type d’architecture. Le code étant bien souvent unique (HTML5, Phonegap …) mais utilisable et/ou déployé sur plusieurs plateformes (web ou mobile).

La montée en puissance des outils

L’arrivée de nouveaux outils joue aussi un rôle non négligeable avec notamment des navigateurs toujours plus performants rendant possible :

• Un traitement de plus en plus rapide du Javascript.
• Une adoption plus rapide des standards du web (https://html5please.com/).
• L’accélération matérielle pour certains d’entre eux.

Le navigateur devient alors une réelle application cliente grâce à des frameworks et bibliothèques toujours plus riches et simples à utiliser :

• Play 2.0, Rails …
• jQuery, CoffeeScript …
• Twitter Bootstrap, Html5Boilerplate …
• Backbone.js, AngularJS, Mustache JS, Dust Js …

Néanmoins tous ces nouveaux outils montrent au final que JavaScript est encore là pour rester pendant un certain moment avant qu’il n’y ait un réel changement de paradigme. En attendant le conseil de James serait “take the most of it” via ces outils. Par ailleurs il souligne aussi que certains d’entre eux (jQuery notamment) deviennent des Must Have sur son CV …

Démonstration par l’exemple

Afin de mieux comprendre la facilité de prise main et de haute productivité de ces outils, James Ward nous a proposé de créer une application (ajout / liste de bars) et de la déployer en live sur Heroku. Le tout en moins de 30 minutes !

Cette application est un petit condensé de ce qu’il est actuellement possible de faire et repose sur Play framework 2.0, Anorm (couche d’accès aux données incluse dans Play), JSON, jQuery et CoffeeScript. Jetons un rapide coup d’oeil.

Commençons avec la création d’un projet Play.

 

[gist id=”128e4f7f38c4aa48f103″]

 

Puis enchaînons avec la création du bean entity.

 

[gist id=”2480969″]

 

Continuons avec le controller et ses méthodes d’ajout et de listing.

 

[gist id=”2480954″]

 

On constate que la méthode addBar() permet de persister un objet grâce à Anorm et qu’il est très facile de rediriger la requête vers la page d’index via le fichier routes (propre à Play). Notez au passage la manière dont Play permet de rendre un flux JSON sur la méthode listBars() et comment tout ceci est géré coté vue.

 

[gist id=”2481429 “]

 

avec encore une fois le fichier routes qui intègre le CoffeeScript traitant le flux JSON de la manière suivante :

 

[gist id=”2481509″]

 

Bref, le tout est assez bluffant de rapidité surtout grâce à la compilation et au déploiement à chaud de Play. Selon les personnes, les CoffeeScript et autres peuvent plaire ou pas, mais ils ne sont pas imposés par le framework Play. Libre au développeur de faire ses propres choix.

Enfin, pour terminer sa démonstration, James Ward nous présente à quel point Heroku et Play sont bien intégrés via ces quelques lignes de commandes qui effectuent le déploiement de l’application sur le Cloud californien :

 

[gist id=”2481952″]

 

Conclusion

Cette présentation de James Ward était bonne, très bonne. Le personnage connait bien son sujet et il sait faire partager son goût et son enthousiasme (très californien il faut l’avouer :p) pour ces nouveaux frameworks. Après ce genre de session le retour aux applications classiques d’entreprise Jsf/Spring/Websphere peut être rude.
Heureusement toute sa présentation est disponible depuis son site ou sur les repo github, et on se prend à rêver au jour où l’on utilisera tout ça dans la vraie vie.

Quelques liens pour finir :

https://www.jamesward.com/
https://github.com/jamesward/play2bars-java (pour la version Play 2.0 en Java)
https://github.com/jamesward/play2bars-scala (pour la version Play 2.0 en Scala)
https://www.playframework.org/
https://www.heroku.com/