[Flex] Les flux de données : un problème de volume

Flex est à la mode, c’est indéniable. Il est vrai que les atouts de ces interfaces riches sont tentants :

  • Richesse des composants ;
  • Environnement de développement basé sur Eclipse ;
  • Accessibilité du langage ;
  • Nombreux composants disponibles sur le marché.

Développer en Flex, c’est néanmoins se confronter à plusieurs problématiques :

  • Technologie propriétaire ;
  • Coût de certaines librairies ;
  • Incompatibilité avec Safari Mobile (iPhone / iPad) qui ne supporte pas (pour le moment) le Flash.

Refondre un site Web en technologie Flex permet d’enrichir considérablement l’expérience utilisateur. Toutefois, elle implique des difficultés comme l’échange de gros volumes de données : mieux on affiche les informations dans un tableau, plus on souhaite en afficher. Se pose alors la question des performances. Si afficher quelques centaines de lignes se fait relativement rapidement, afficher des milliers voire des dizaines de milliers de lignes peut dégrader considérablement l’expérience utilisateur.

Heureusement, les solutions existent. La plus simple ? Ne plus utiliser les Web Services (basés sur un SOAP trop volubile) mais leur préférer un transmission de données au format JSON en se basant sur une architecture REST.
Un autre solution ? Pourquoi ne pas mettre en place une architecture avec Blaze DS (Open Source) ou Granit DS (Open Source) ? Ils offrent des possibilités pertinentes en matière de sérialisation AMF (optimisation des transferts de données) tout en facilitant le développement de services métiers pour l’interface Flex.

Pour optimiser son flux JSon, et soulager le réseau lors de transferts volumineux, la piste la plus simple et efficace est la compression gzip proposée par les serveurs HTTP1.1 .
En utilisant les outils de profiling intégrés aux navigateurs récents ( Google Chrome, Firefox ou Firebug ), nous pouvons identifier et observer les bénéfices de la compression.
Chrome nous indique par exemple les pistes à suivre pour réduire notre utilisation du réseau :

Gains attendus de compression JSon sous Chrome

Par une simple modification du fichier server.xml de configuration de Tomcat, on active la compression en ciblant le type (html, javascript, JSON) et la taille des ressources retenues dans le cadre de notre optimisation :

Configuration Tomcat pour la compression

On peut observer les gains obtenus :
Notre flux de 3,9 Mo a été très favorablement réduit à moins de 100ko, et le temps passé à réceptionner le flux est passé de 1,2 secondes à 80 ms en moyenne.

Gains de consommation observés sous FireBug

Bilan
Refondre une interface en Flex (ou la créer « from scratch ») sans concevoir l’ensemble de l’architecture peut se réveler dangereux. Car la fluidité et le confort de l’interface sont entièrement dépendants de la réactivité de la partie serveur et des performances des services métiers. Faire du Flex par simple effet de mode risque de vous confronter à de sérieuses désillusions.
Les avantages sont indéniables mais les risques sont bien réels.

Fort heureusement, des solutions crédibles existent, elles rationalisent les développements tout en assurant un niveau de performance suffisant dans la majorité des cas.