Scala IO 2013 => Spray : REST on Akka

Présentateur

Mathias Doenitz, lead developpeur de spray.io, commiteur sur le projet Akka.

• Twitter : @sirthias
• G+ : Mathias Doenitz
• Sa bio sur Scala IO
• La description de sa session ScalaIO

Le Talk

Ce talk a eu comme objectif la présentation de Spray, une couche HTTP pour les acteurs d’Akka à destination des développeurs Scala.

En Java nous avons déjà ce qu’il faut pour faire du HTTP

Pour communiquer à travers HTTP, nous disposons de multiples librairies et frameworks dans l’écosystème de la JVM (Servlets, Restlet, Spring MVC, JAXRS, …). Scala étant basé sur la JVM, nous pouvons bien entendu “réutiliser” certains de ces outils.

Mais…

Les outils Java => un enfer pour le développeur Scala

Le développeur Scala est frustré car il y retrouve tous les défauts du monde Java qu’il a justement fui en faisant du Scala.

Quels sont ces défauts que nous retrouvons généralement dans nos librairies/frameworks ?

• Un conteneur Servlet avec sa session qui limite la scalabilité horizontale

• XML, XML, XML,… Java étant un langage pas assez expressif pour être utilisé en DSL de façon convenable. Les configurations des outils Java reposent souvent sur d’autres formats XML, properties, … là où les autres langages peuvent aisément s’utiliser en configuration. On pensera à Groovy avec la configuration d’un build Gradle ou encore à Scala avec la configuration SBT. C’est dommage de se retrouver avec des fichiers XML à configurer lorsqu’on travaille avec un langage pour lequel il possible de créer un DSL qui compile !

• Des API et objets du modèle “mutables”. En développant en Scala Style, vous vous débrouillez pour réaliser une application en prenant soin d’éviter d’utiliser des objets mutables et vous voilà condamné à utiliser une API qui ne respecte pas vos principes et qui peut vous entrainer des comportements difficiles à prévoir.

• Les collections Java. Scala fournit une API riche pour manipuler des collections. Il est dommage de s’en priver.

• Un typage limité. Impossible de détecter des problèmes de configuration à la compile, trop de surprises au runtime.

Que souhaite le développeur Scala ?

• Retrouver ses case class
• Communiquer en asynchrone via des messages (Merci Akka)
• Utiliser des closures, on est en 2013 quand même ! :)
• Consolider plusieurs requêtes asynchrones grâce aux Futures
• Manipuler naturellement ses collections avec une API avancée

=> En somme, pouvoir pleinement profiter de Scala !

Et voilà Spray !

Spray a pour objectif de réaliser les souhaits du développeur Scala en se reposant complètement sur Scala et Akka.

Spray est construit de façon modulaire pour nous donner la possibilité de n’utiliser que les parties qui nous intéressent. Il y a de nombreux modules : spray-caching, spray-can, spray-client, spray-http, spray-httpx, spray-io, spray-servlet, spray-routing, spray-testkit, spray-util, spray-json.

Mathias a poursuivi son talk en présentant quelques modules de Spray :

• spray-http => structures de données HTTP basées sur les case class. Ce module permet entre autres de créer des objets Requête, Réponse. Le paramétrage HTTP est lui aussi typé, des case class pour Accept-Charset, Accept-Encoding etc…

• spray-can => API HTTP serveur et cliente de bas niveau construit sur Akka IO.

• spray-routing => ce module fournit un DSL avec des très nombreuses directives pour décrire :

  • le routage des requêtes
  • (Un)marshalling d’objets
  • la mise en cache des ressources statiques
  • la gestion des erreurs
  • …

A savoir !

• Spray est encore en cours de développement. A sa version finale, il changera de nom et s’appelera akka-http.
• Play Framework va progressivement abandonner Netty pour akka-http.

Les slides de la présentation

Lien direct : http://spray.io/scala.io/

Ce que j’en ai pensé

Une bonne présentation d’un outil plein de promesses pour les développeurs Scala. Nous avons là une librairie qui va probablement devenir la référence dans l’écosystème de TypeSafe.

L’abandon progressif de Netty au profit de akka-http dans le projet Play Framework montre une nouvelle fois la volonté de TypeSafe de créer un écosystème d’outils fortement typés pour Scala et ne garder de Java que la JVM :)

On peut légitimement se poser la question de la durée du support du langage Java dans les projets comme Play Framework et Akka lorsque Scala aura son écosystème suffisamment développé.

Si vous souhaitez en savoir plus, je vous recommande les liens suivants :

• La philosophie de Spray, pourquoi il n’est pas conçu comme un framework
• Des vidéos, slides, podcasts de l’équipe Spray
• Et bien sûr, la documentation officielle à travers l’introduction et la référence.