Technologies

GWT 2 : productivité pour les développeurs, performance pour les utilisateurs

Publié le : Auteur: Mohamed SYLLA Laisser un commentaire
technologies

Avant d’entrer directement dans le vif du sujet, plantons le décor…

Le Web à ses débuts

Avant le JavaScript et autres langages coté client, les navigateurs Web étaient comme des terminaux passifs HTML, se limitant à une simple présentation Web des pages générées sur un serveur. Pour ces pages, chaque action de l’utilisateur nécessite une pleine actualisation de la page, avec un aller-retour sur l’Internet, qui dégrade les  performances et donc la satisfaction des utilisateurs.

Dynamisons nos pages Web

L’utilisation traditionnelle de JavaScript a permis d’intégrer des fonctionnalités sur le client (poste utilisateur), en améliorant leurs performances par diminution du trafic réseau. JavaScript était et continue d’être  idéal pour des besoins tels que la validation d’un formulaire utilisateur. Mais un tel code JavaScript ne peut pas communiquer avec le serveur, et n’a donc aucun moyen d’accéder aux données d’une base de données via la couche applicative, ou même d’assurer le maintien de l’état entre les pages actualisées.

Encore plus de confort d’utilisation de nos pages Web dynamiques

Les solutions Ajax (de l’anglais Asynchronous JavaScript and XML) proposent de résoudre les problèmes précités en permettant aux navigateurs de communiquer avec le serveur dans les coulisses, sans avoir à rafraîchir la page entière. Elles accomplissent cette mission en utilisant JavaScript afin de ne changer que la partie de la page Web en cours de traitement.  L’utilisation d’Ajax apporte aux utilisateurs d’applications Web des fonctionnalités manquantes dans ce type d’applications mais déjà bien connues des utilisateurs d’applications de type standalone. La mise à jour dynamique des pages apporte aux utilisateurs convivialité et rapidité dans les pages Web.
Ajax est asynchrone en ce sens que les données chargées à partir du serveur n’interfèrent pas avec l’affichage et le comportement de la page Web en cours. La requête de chargement des données est envoyée au serveur grâce à l’utilisation de l’objet XMLHttpRequest, et généralement sous forme d’XML, d’où le reste de l’acronyme.

Mais la programmation brute en Ajax est généralement assez fastidieuse. En partie parce que les navigateurs Web mettent en œuvre JavaScript de façons différentes malgré une convergence sur les normes ECMAScript. En conséquence, les programmeurs Ajax peuvent passer beaucoup de leurs temps de développement pour remédier aux incompatibilités entre navigateurs et systèmes d’exploitations. Cela baisse beaucoup leur productivité.

Plus de confort de programmation de nos pages Web dynamiques

La réponse de Google à ces difficultés, le Google Web Toolkit (GWT), est un framework open source qui permet d’écrire du code Java de façon classique, dans un environnement de développement intégré Java, et qui peut être débogué avec les outils Java habituels. Ce code Java est ensuite traduit en pur JavaScript par le compilateur GWT pour les principaux navigateurs (IE, Mozilla, Chrome…). Le code JavaScript généré utilise des techniques HTML dynamique (DHTML) et de manipulation du DOM (Document Object Model) pour les aspects dynamiques de l’interface.

Pour plus d’informations, je vous invite à consulter le site officiel de GWT.

GWT 2 : de quoi s’agit-t-il exactement ?

La version 2 de GWT est une révolution par rapport aux versions antérieures. Dans ce qui suit, il est question de GWT2.x. La dernière version de GWT en date est GWT 2.6.0,  sortie le 30 janvier 2014.

Pour comprendre l’évolution de GWT et en apprendre un peu plus sur les versions antérieures, je vous invite à consulter son site officiel. Le framework GWT  met à la portée de tous les développeurs Web la possibilité de créer des applications Web interactives et robustes avec une productivité hors pair. Publié en licence libre Apache, Google Web Toolkit génère depuis Java du code JavaScript et HTML5/CSS optimisé à l’extrême.

GWT est un kit de développement pour la construction et l’optimisation des applications basées sur des navigateurs complexes. Il est utilisé par de nombreux produits de Google, notamment par Google Adwords, Google AdSencse, Google Wallet. Il est open source, complètement libre et utilisé par des milliers de développeurs actifs dans le monde entier. Vous trouverez des exemples sur http://www.gwtproject.org/examples.html.

GWT 2 : qu’apporte-t-il à GWT1.x ?

Avec la correction de nombreuses bogues et l’amélioration de  GWT1 en introduisant de nouveaux concepts, GWT2 atteint l’âge de la raison.  Parmi les évolutions, on peut citer le mode développement, le chargement à la demande (la fragmentation de code), la gestion asynchrone des ressources (ClientBundle), le nouveau modèle RPC (Direct Eval RPC),le support de format XML pour la structuration des sites.

Dans ce qui suit, je présenterai les trois apports majeurs qui ont le plus attiré mon attention, à savoir : le mode développement, le chargement à la demande et la gestion asynchrone des ressources.

1. Le mode  développement ou dev mode

Développer une application Web avec un EDI java a été rendu possible grâce à GWT1. Mais ce qui manquait le plus cruellement aux développeurs d’application Web était de pouvoir déboguer leurs applications au même titre que n’importe quelle application client lourd. Cette fonctionnalité est désormais possible grâce au mode développement introduit par GWT2. Avec ce nouveau concept, l’application est déboguée comme une application client lourd (Swing/SWT) à l’intérieur d’un navigateur Web.

Le dev mode est un environnement qui permet aux développeurs de réduire la lourdeur des étapes de codage, test et débogage. Il reproduit fidèlement un environnement Web. C’est un navigateur qui possède la capacité de déboguer et charger dynamiquement du byte code java.

Voyons un exemple d’illustration pour mieux cerner ce nouveau concept de GWT2. En mettant un point d’arrêt dans Eclipse au niveau d’une méthode appelée et en appuyant sur le bouton « Envoyer ».

gwt_dev_mode1

Le résultat en mode debug sous éclipse est très impressionnant.

gwt_dev_mode2

L’avantage de cette façon de faire est que le développeur bénéficie de nouvelles fonctionnalités telles que les points d’arrêt, le pas à pas, la possibilité d’espionner des variables java à l’exécution et l’affichage de la pile d’appels.

2. Le chargement à la demande (la fragmentation de code)

Partant de l’idée selon laquelle « on ne paye que ce qu’on utilise« , GWT 2 a révolutionné la manière de télécharger les scripts JavaScript générés à partir du code java. Le chargement à la demande est sans nulle doute la nouveauté la plus marquante de GWT2. GWT2 est désormais capable de charger progressivement des scripts de manière différée au moment où l’utilisateur active un traitement ou navigue dans l’application.

Le chargement à la demande, ou fragmentation, est un mécanisme proposé par GWT2 et dont l’objectif est de scinder le code java en plaçant manuellement des points de rupture. L’idée est de générer non plus un seul fichier, mais plusieurs fichiers ou fragments de code JavaScript.

L’arbre syntaxique ci-dessous nous explique comment la fragmentation est faite, en faisant une comparaison avec les deux modes de chargement. A gauche, le chargement normal (sans fragmentation) et à droite le chargement avec des fragments :

gwt_arbre_syntax

Le chargement à la demande s’apparente à un concept souvent utilisé lors de la conception d’application client lourd avec (Swing/SWT).

Ce concept est le suivant : pour des raisons de performance, lors de l’affichage d’une fenêtre avec plusieurs onglets et dont chaque onglet fait plusieurs appels serveurs pour charger les données à partir de la base de données en lieu et place du chargement de toutes les données de tous les onglets, on charge uniquement les données de l’onglet par défaut et on affiche seulement les informations nécessaires. Chaque fois que l’utilisateur clique sur un onglet, on peut lancer un appel serveur uniquement pour l’onglet sollicité. Cela évitera  non seulement de charger des données qui ne seront jamais utilisées au cours de la session de l’utilisateur, mais aussi de charger une trop grande quantité d’informations lors de l’affichage de la fenêtre qui aurait pour conséquence un temps d’attente considérable, d’où la détérioration de la performance de l’application.

GWT2 adopte un concept similaire pour le chargement des scripts car aucun navigateur, même dans les meilleurs conditions, ne sait charger rapidement un fichier JavaScript d’une très grande taille (quelques mégaoctets). Sans l’apport de la fragmentation de code GWT n’aurait pas pu prétendre générer des applications de grande envergure.

Dans l’exemple pratique ci-dessous nous allons illustrer les deux cas : le chargement complet et le chargement à la demande.  Chaque cas sera inspecté avec Firebug pour montrer ce que ça donne exactement.

1 – Chargement complet

Sur la partie encadrée en rouge on voit bien qu’il y a 8 requêtes lancées. La taille totale des fichiers chargés est égale à 80,5 Ko et le temps total de chargement est de 315 ms.

gwt_charge_dmd3

2 – Chargement à la demande

a- Charger uniquement la partie nécessaire pour l’affichage : sur la partie encadrée en rouge on voit bien qu’il y a deux requêtes en moins (6 requêtes). Le lancement de ces deux requêtes est éventuellement différé, la taille totale des fichiers chargés est égale à 79,2 Ko , soit 1,3 ko en moins  et le temps total de chargement est de 275 ms, soit un gain de 40ms (315ms-275ms ) au lancement.

gwt_charge_dmd1

b- Charger le reste si l’utilisateur y accède : si l’utilisateur clique sur le bouton « rechercher » l’écran des critères de recherche s’affiche. Ce traitement télécharge le code JavaScript (éventuellement des ressources) associé à cette portion d’écran. La figure ci-dessous nous montre qu’il y a au total 8 requêtes comme lors du chargement complet. La taille total des fichier est complété à 80,5Ko et on gagne quelques 16ms (315ms-299ms).

 gwt_charge_dmd2

 

Remarque : si nous projetons ces résultats dans le cadre d’applications qui chargent des dizaines de mégaoctets il est certain que le chargement à la demande est une aubaine pour le développement d’applications Web.

3. La gestion asynchrone des ressources ou ClientBundle

On a l’habitude de dire que les ressources (support média, fichier texte, feuille de style CSS ou fichier PDF) sont la première cause de dégradation des performance d’un site Web. C’est pourquoi, la gestion des ressources est depuis toujours une des préoccupations majeurs des développeurs  d’application Web. Où doit-on stocker ses fichiers ? Comment optimiser leur chargement pour bénéficier les meilleures performances ? Toutes ces questions sont à l’origine de la création de l’API ClientBundle, une des nouveautés de GWT2.

L’API ClientBundle permet de gérer toutes les ressources pour qu’elles bénéficient de la mise en cache permanente. Le développeur jusque là n’ayant pas assez de solutions  pour ces ressources, peut désormais à l’image du chargement à la demande, définir les ressources qu’il souhaite charger dès le lancement de l’application, celles qu’il souhaite charger de manière asynchrone au moment où l’utilisateur y accède, et celles pour lesquelles un traitement particulier est nécessaire.

L’API ClientBundle lève également toutes les incertitudes liées aux configurations des pare-feu et proxies qui, tout au long de la chaîne du Web, modifient les en-tête HTTP pour des besoins de sécurité et de traçabilité. Il s’assure également à la compilation que des multiples références à un fichier de ressources sont intactes, mais également que deux références pointant vers la même ressources ne nécessiteront pas deux téléchargements.

Nous allons utiliser les ressources textuelles asynchrones comme exemple d’illustration. Les ressources externes asynchrones constituent une des fonctionnalités les plus intéressantes de l’API ClientBundle. C’est un procédé qui permet de récupérer une ressource à partir d’une requête Ajax au moment opportun.

gwt-clientBundle

Avec l’exemple ci-dessus, GWT fait deux optimisations :

  1.  GWT réalise la première optimisation lors de la compilation en modifiant la ressource et la transforme au format JSON. Ce format est reconnu par l’ajout d’un crochet et des guillemets au début et à la fin de notre fichier XML. Les fichiers JSON sont plus facilement  absorbés par des méthodes de désérialisation dynamique de GWT. Avec ce procédé, GWT s’assure des performances optimales.
  2. La deuxième optimisation est réalisée par la Classe ExternalTextRessources: la mise en cache automatique des ressources. Lors du premier appel à une ressource donnée, GWT la stocke localement et la réutilise pour les appels suivants. Sans les apports de l’API ClientBundle, ce procédé se serait appuyé sur les en-tête HTTP, peu fiable lorsqu’on traverse les proxies et les pare-feu.

 

Voilà un aperçu des apports de GWT2. Je vous proposerai séparément un tutoriel qui apportera des détails au développement d’une application Web avec ce framework.