[Devoxx FR 2012] – GWT à l’épreuve du feu


Sami Jaber
 est un architecte Java EE / .NET notamment connu pour le blog DotNetGuru. Il a fondé DNG Consulting qui s’est spécialisée dans le développement d’applications web. Sami Jaber nous a présenté l’application Cobra développée en grande partie par sa société pour le compte de son client : Arkadin.
Sami Jaber nous a d’abord présenté la société cliente et le besoin avant de faire une démonstration de l’application.
Nous verrons dans cet article les raisons qui l’ont poussé à opter pour GWT.

Le contexte

L’offre de Arkadin intègre un support devant permettre de dépanner les utilisateurs qui n’arrivent pas à rejoindre une conférence alors qu’ils disposent d’un PIN. Le PIN est un identifiant fourni par l’organisateur de la conférence aux participants afin que ceux-ci puissent se connecter. Si jamais l’utilisateur rencontre un quelconque problème pour rejoindre une conférence, il n’aura qu’à appeler le support d’Arkadin. L’opérateur doit être en mesure de retrouver facilement (via une expression régulière par exemple) le bon code PIN de manière à introduire immédiatement l’utilisateur dans sa conférence.
Plusieurs exigences ont été évoquées mais nous ne citerons que la plus importante pour le projet : l’interaction entre l’application de l’opérateur et le téléphone de l’utilisateur (appel, mute, musique d’attente, passage en conférence, …) doit être quasiment instantanée.

Le résultat

Une fois le contexte précisé, Sami Jaber nous a fait une démonstration de Cobra. Il s’agit d’un unique écran avec une multitude d’onglets et de boutons qui s’affichent selon le contexte. Le résultat n’a rien à envier à une application client lourd classique.

Pour les besoins du test quatre volontaires se sont prêtés au jeu et ont fourni leur numéro de mobile. Sami Jaber a créé une conférence et les a fait participer à la conférence. En un clic il a fait sonner leur téléphone respectif puis il en a désactivé un. A chaque fois la communication entre la webapp et le téléphone semblait instantanée.

Lors de la démo Sami Jaber a beaucoup insisté sur le fait que son application était 100% web : http HTML JavaScript. Et surtout que l’application était compatible avec tous les navigateurs de IE6 à la dernière version de Chrome.

Le choix de GWT comme framework web

Le besoin étant de développer une webapp, le choix du framework est une préoccupation centrale. Sami Jaber nous a expliqué les contraintes du projet et les raisons qui l’ont poussé à opter pour GWT. La numérotation ci-dessous n’est donnée qu’à titre indicatif.

  • Contrainte N°1 : la complexité de l’IHM

Nous l’avons tous vu à la démo, les écrans de Cobra, ou plutôt l’écran – car il s’agit en fait d’un unique écran englobant plusieurs widgets s’affichant en fonction du contexte –est assez complexe. Sami Jaber a indiqué l’intérêt d’un écran unique : éviter à l’opérateur de perdre du temps à naviguer à travers une multitude de fenêtres.

  • Contrainte N°2 : la problématique du push

Comme indiqué plus haut, l’application doit être réactive à des évènements divers tels que le fait que l’utilisateur décroche ou raccroche son téléphone.
Le framework Atmosphere a été envisagé un moment comme alternative mais n’a pas été jugé assez mature.
De son coté, GWTEventService gère le long pooling et le short pooling, répondant ainsi au besoin.

  • Contrainte N°3 : La diversité des browsers

Les utilisateurs de l’application sont situés sur plusieurs continents et n’ont potentiellement pas les mêmes postes de travail. Il faut que l’application puisse fonctionner sous plusieurs versions d’IE, Firefox, Chrome.  Sur ce point également GWT répondait aux attentes car le code généré s’exécute de la même manière sur tous les navigateurs courants.

  • Contrainte N°4 : Performances (Code spliting)

Compte tenu de la richesse de l’écran, le code JavaScript généré est très important. Cela aurait été une catastrophe en terme de performances si tout le code avait dû être chargé systématiquement comme ceci est fait de manière classique. Il est intéressant de ne pas charger le code JavaScript du front lorsqu’on est sur les écrans d’administration par exemple. GWT 2.0 intègre le code splitting.

  • Contrainte N°5 : La productivité

Compte tenu de la complexité de l’IHM, et du nombre de widgets, une expertise en JavaScript semble indispensable. La difficulté de ce sujet reposait sur le fait que l’équipe était composée de développeurs Java ne maitrisant pas ou peu JavaScript. Une fois de plus GWT est apparu comme la meilleure solution car il a permis à l’équipe de développer le code Ajax nécessaire sans pour autant mettre les mains dans le JavaScript.

La communication avec le backend

Après avoir explicité le choix de GWT, Sami Jaber nous a exposé une des difficultés qu’il a rencontré : la mise en œuvre du pont .Net vers Java.
En effet le backend exposant ses services via des composants COM, il fallait les consommer. Après avoir essayé un outil payant qui s’est révélé inefficace, l’équipe s’est retournée vers Jacob un outil open source quasiment inconnu mais qui se montra néanmoins parfait pour couvrir le besoin après quelques adaptations.

Les choix effectués

Sami Jaber nous a brièvement décrit les choix organisationnels et l’environnement de développement.

  • Itérations de 3 semaines
  • Coffee meeting au lieu du DSM traditionnel debout
  • Jenkins
  • Confluence – Google doc
  • QA Director
  • SVN

Sami Jaber a mis en avant le caractère 100 % transparent du processus : à chaque instant son client peut savoir ou en sont les développements.

Les tests

Pour finir nous avons eu une démo des tests Sélénium. Je vous invite à parcourir le blog So@t si vous ne connaissez pas l’outil.

Notre opinion sur la présentation

Voir une démo d’une application qui ne soit pas un POC à une conférence était appréciable, surtout avec la participation du public. Lors des conférences, ce sont souvent des use cases « standards » qui sont décrits. Cobra nous a donné une idée de ce qui était faisable. Cependant beaucoup regretteront surement d’avoir assisté à une présentation plus orientée client / décideur que développeur. En 55 mn pas une seule ligne de code.

Nombre de vue : 24

AJOUTER UN COMMENTAIRE