[Techdays 2013] Asp.Net Web.API, SignalR et UX

downloadVoici un retour sur la session intitulée « Asp.Net Web.API, SignalR et UX : le futur ». Cette session était animée par Thomas Jaskula (@tjaskula) et Rui Carvalho (@rhwy). Elle a été découpée en deux parties : les WebAPIs d’un côté et signalR de l’autre. Une introduction sur les Ux a permis d’amener ces deux parties.

Les deux sont membres d’une communauté .net qui est très intéressante : Alt net http://www.altnetfr.org/

Expérience Utilisateur (UX)

Cette session a commencé par parler d’expérience utilisateur.

Le monde des réseaux change. Nous somme passés d’un environnement décentralisé à distribué puis à globalement distribué grâce au Cloud. Du coup, à la création d’une application, il est important de se poser la question suivante : à partir de quels terminaux les utilisateurs vont-ils utiliser mon application ?

Aujourd’hui, de plus en plus de terminaux entrent dans la réponse à cette question. Le parc est très hétérogène car le monde entier est connecté. Nous avons complètement dépassé les 3 écrans.

Autre point, l’utilisateur s’attend à toujours plus de fluidité. C’est à nous autres développeurs de la lui fournir. Pour cela, il est important de mettre en place des APIs qui soient au cœur de l’application, et surtout standardisées. Pour le côté fluidité, l’utilisateur veut de la communication temps réel. Il s’attend à ce que notre application se comporte comme une vraie application de bureau. Il nous faut donc fournir l’information en moins de 1 seconde. Et pour cela, il existe des frameworks spécialisés.

C’est après cette brève introduction que nous sommes passés au vif du sujet : les APIs web (avec un passage sur ASP .net web API) et ensuite SignalR pour la communication temps réel.

Les APIs Web

C’est Thomas Jaskula qui a présenté cette partie en commençant par un chiffre très intéressant : aujourd’hui les APIs web sont à 69% du REST et 24% du SOAP.

Pour ceux qui voudraient un exemple d’API web, voici un vieil article représentant l’achat d’un café chez Starbuck au format REST : http://www.infoq.com/articles/webber-rest-workflow

Il est ensuite passé à la notion intéressante de ressources et d’hypermédias.

Hypermedia, Content Negociation

Globalement dans une api REST, une URI permet de récupérer un résultat. Grâce au content type, le consommateur de cette api va pouvoir utiliser la même URI pour récupérer différentes ressources de ce qu’il cherche. Admettons qu’il ait une URI pour appeler un livre spécifique (ici avec un id = 1) /book/1. Cette même URI associée avec un content type « application/json » renverrait les informations du livre au format Json, tandis que le content Type « image/jpeg » renverrait l’image associée à ce livre.

Cette réflexion quant à la manière de requêter une API en lui spécifiant la ressource attendue n’est pas encore très répandue mais est très intéressante.

Hateoas

C’est en parlant du modèle de mâturité des APIs web qu’il a soulevé un second point intéressant : HATEOAS ou « Hypermedia As The Engine Of Application State ». Globalement le client connaît uniquement l’URI de point d’entrée dans l’application, par exemple http://bookseller/start . A partir de ce moment, tous les liens de l’application sont fournis par l’API. Il faut bien entendu un contrat définissant une collection de liens associés à une clé qui serait utilisée mais cela donnerait par exemple ceci :

  • ‘ViewProducts’ => /books/
  • ‘Search’ => /search/

Le point intéressant est que les clients utilisent les clés pour trouver les liens et que du coup l’API puisse redéfinir ses liens sans impacter les clients. C’est l’application qui donne les actions possibles à l’utilisateur.

Il est ensuite passé à la présentation d’ASP.net WebAPI suivant les deux points précédents.

ASP.net WebAPi

Le framework comprend un support complément de HTTP et notamment l’aspect « content negociation » que nous venons de voir. Point important, il propose une grande indépendance au hosting puisqu’il peut être hébergé dans IIS ou s’héberger soi-même grâce à un process windows. Il supporte également HATEOAS.

Pas de doute pour lui, webAPI est la technologie à utiliser pour faire les APIs, notamment pour sa performance et sa montée en charge mais aussi pour permettre de découpler son application.

Après ce passage sur Web API, nous avons parlé du second point : la communication en temps réel avec SignalR.

Communication temps réel : SignalR

C’est Rui Carvalho qui s’est attaqué à cette partie en commençant par rappeler ce qu’est le temps réel. Le temps réel permet au serveur d’envoyer des informations au client sans que celui-ci n’en soit demandeur. C’est un push server. Vous avez peut-être déjà essayé d’utiliser Comet qui fait cela. Pour plus d’info sur le push server : http://en.wikipedia.org/wiki/Push_technology

Il a ensuite énoncé un fait : HTTP n’est pas fait pour le temps réel. En effet HTTP n’a jamais été prévu pour cela, il permet avant tout de fournir à un client qui le demande un document. De plus il gère uniquement une communication requête/réponse et cela de manière stateless.

WebSocket et autres alternatives

C’est à cause de cela qu’a vu le jour WebSocket. Ce standard, qui est en cours de spécification, permet d’utiliser un canal bidirectionnel entre le serveur et le navigateur. Mais il se trouve que les spécifications sont en cours d’écriture et donc instables, que du coup le support serveur et celui des navigateurs sont aléatoires.

Il y a néanmoins quelques alternatives :

  • Le short et le long polling : requêter le serveur pour récupérer les informations à traiter.
    • Beaucoup de trafic
    • C’est au serveur de garder l’état de l’information pour savoir à qui l’envoyer.
  • Le Forever Iframe : utilise une iframe pour ouvrir un stream, récupérer et traiter les informations au fur et à mesure de leur arrivée.
    • Consomme beaucoup de ressources

Globalement, il n’y a pas de moyen stable de faire car ils ont tous leurs avantages et leurs inconvéniants, ainsi qu’une liste de clients compatibles. Il faut donc généralement tous les implémenter et choisir par client lequel utiliser. C’est un travail assez fastidieux.

SignalR

Mais c’est là qu’entre en scène SignalR http://signalr.net. Pourquoi l’utiliser ? En fait il implémente pour vous toutes les technos de communication temps réel vues au-dessus et va choisir par client, la meilleure à utiliser. SignalR est une technologie OpenSource utilisée depuis plus de 2 ans, et reprise depuis novembre 2012 par Microsoft au sein du namespace Microsoft.Aspnet.SignalR. De plus, il dispose maintenant de clients dans toutes les plateformes.

Coté serveur, il vous faudra une application ASP.net en framework 4 minimum. Après, comme WebApi, il peut s’héberger dans un processus Windows, dans IIS, dans Azure ou encore Mono. Vous avez l’embarras du choix !

SignalR vous propose deux niveaux de programmation. Un bas niveau en utilisant les connexions persistantes et un niveau plus élevé en utilisant les Hubs. Globalement, ce niveau plus élevé utilise les connexions persistantes mais génère automatiquement ses proxies et propose des routes dynamiques.

La fin de la présentation de SignalR a présenté ses performances et quelques warnings. Evidemment, SignalR encapsule les technologies de communication temps réel. La performance dépend donc de la techno choisie ainsi que du navigateur du client.

Néanmoins, il est possible de gérer avec un serveur de 250000 à 500000 requêtes par secondes, ou encore 70000 utilisateurs simultanés. Bien sûr, plus il y aura d’utilisateurs, plus la charge CPU augmentera.

Voilà pour la présentation de SignalR. C’est vraiment un outil très pratique pour faire du temps réel sans avoir à tout coder à la main. De plus, vous obtiendrez un niveau d’abstraction supplémentaire et donc un code plus maintenable.

Conclusion

Utilisant déjà WebAPI, je connais la qualité de la librairie. J’ai vraiment été intéressé par toute la partie hypermédia. Coté signalR, c’est vrai que la communication temps réel était compliquée à mettre en place. Mais SignalR propose une chose : vous aider à le faire et surtout décider à votre place quelle technologie utiliser pour le faire au mieux. Bref, très bonne session, merci à Thomas Jaskula et Rui Carvalho pour leur session !

Vous retrouverez les exemples présentés lors de cette session ici:
https://github.com/codedistillers/talks-td2013
https://github.com/tjaskula/ASP.NETWebAPI-Techdays2013

Edit :

J’ai trouvé la présentation de la session sur SlideShare, la voici :

[slideshare id=16506212&doc=web304-webapisignalr-v1-1-0-public-130213081954-phpapp02]

Nombre de vue : 70

AJOUTER UN COMMENTAIRE