Lisez moi : Nos impressions sur le concours TypeSafe

Pour le concours TypeSafe nous avons réalisé l'application web Skimbo : un agrégateur de réseaux sociaux. Skimbo résoud un problème essentiel que rencontre tous les utilisateurs de réseaux sociaux, lorsqu'ils sont inscris sur plusieurs réseaux sociaux différents : l'obligation d'ouvrir plusieurs onglets du navigateur pour suivre tous ces réseaux. Skimbo est la solution à ce problème, un utilisateur n'a qu'à se connecter à Skimbo via un des réseaux sociaux proposé. Ensuite, il peut créer des colonnes dans lesquelles vont s'afficher les flux des différents réseaux sociaux auxquels il est connecté.

Cette application utilise complètement la stack TypeSafe : Scala, Play 2.1-RC1, Akka et en bonus Reactivemongo pour la liaison MongoDB ainsi que les WebSocket (ou Server Send Event si le client ne le permet pas) et AngularJs pour le client.

Pourquoi ces technologies ?

Découvrir de nouvelles choses est notre passe-temps favori ! Ce concours fut un véritable challenge, car il s'appuie sur une stack technologique que nous ne maîtrisions pas. La majorité des développeurs n'avait jamais écrit une ligne de scala, et les notions d'acteurs/asynchronicité/temps réel/reactive model étaient vraiment nouvelles pour nous. Le langage scala fut une révélation dans l'utilisation de notre si chère (mais si poussiéreuse) JVM. Enfin un langage nous permettant d'écrire en quelques lignes ce que nous imaginons dans notre tête d'informaticien. Le concours se déroulant sur 2 mois ce fut un grand atout dans la rapidité de mise en pratique de plusieurs de nos concepts clés.

Dans cette même optique, play nous a permis de créer des webServices en moins de 3 lignes de code ! Sans ce prendre la tête avec la configuration ou les rebuild intempestifs. De plus pour ce projet nous devions communiquer avec un grand nombre de webServices distants. Pour implémenter les différents protocoles de communication, Play fut d'un grand secours. Facile d'utilisation et surtout très rapide à appréhender.

Le premier problème rencontré, fut justement le grand nombre de webService distants à interroger. Outre le fait qu'il a fallut coder les spécificités de chacun de ces services, il fallait aussi que notre application ne ralentisse pas et soutienne la charge. De même, que pour le nombre d'utilisateur connecté. En effet, qui dit agrégateur de réseaux sociaux, dit nombre d'utilisateurs potentiels.

Pour régler ce premier problème nous avons choisi d'utiliser Akka et son système d'acteur. De la même manière que play cette librairie est très facile d'utilisation (même si à notre grand regret nous avons pas eut le temps de plonger dans les méandres de sa configuration). Etant ThreadSafe nous avons décidé d'y ajouter notre système de pooling vers les services distants. Cela permet de cloisonner chaque client dans son thread tout en ne pénalisant pas les autres utilisateurs.

Puisque notre pooling était bien géré côté serveur, il ne servait à rien de demander au client de le réaliser. Nous avons donc décidé que la communication client/serveur de notre application se ferait au travers d'un channel http ServerSendEvent. Ainsi lorsque le serveur découvre de nouveaux messages il n'a plus qu'à les envoyer au client. Mais le client doit aussi passer certaines commandes au serveur (relatives à notre application). N'ayant que peu de connaissances sur les acteurs Akka, nous pensions impossibles le fait de faire transiter une commande du client vers cet acteur en dehors d'un flux WebSocket. C'est pourquoi nous sommes parti sur cette technologie.

Ce n'est que plus tard que nous avons découvert les évennements du système Akka. Nous pouvions alors faire passer un ordre de l'extérieur du flux vers les acteurs, après plusieurs refactoring du code, nous avions les 2 technologies opérationnelles (SSE + WebSocket).

Une fois ces premières étapes de passées, nous avons décidé de sauvegarder la configuration utilisateur dans la base de donnée MongoDb grâce à la librairie reactivemongo. Une fois de plus, nous avons choisis mongoDb car nous ne connaissions pas cette fabuleuse base de donnée, donc pour le plaisir d'apprendre et de découvrir.

De même pour AngularJs côté client, ce fut une vrai révélation. Très performante même avec énormément de données.

Installation

Pré-requis :

• Play 2.1-RC1
• MongoDb > 2.0
• Un navigateur acceptant les WebSocket et/ou Sse

> "Puller" le projet > Ajouter vos clés secrètes des différents réseaux sociaux dans un fichier my-social.conf avec la structure suivante... > Démarrer le serveur mongo > cd Skimbo > play run

That's all ;)

Pourquoi nous faire gagner ?

Parce qu'on s'en fou de gagner ^^ Nous avons déjà énormément gagné en compétences et ça nous suffit. Seulement si vous souhaitez que nous continuons à faire tourner Skimbo sur un serveur, il va nous falloir, soit des sous pour le payer, soit que vous nous offriez un hébergement sur vos serveurs :D

Quoi qu'il en soit nous continuerons ce projet, pour le prochain sprint nous implémenterons l'option "Skimber!" afin de pouvoir poster un message sur tous les réseaux sociaux auquel vous êtes connecté. Bien sûr bon nombre de nouveaux réseaux vont venir étoffer la liste. Et, si nous allons jusque là, des options payantes telles que la possibilité d'avoir plusieurs comptes par réseau, ou encore des statistiques à des fins commerciales et marketing.

Si vous souhaitez nous aider à réaliser ce rêve n'hésitez surtout pas à nous contacter !