Nous avons testé pour vous le framework Phoenix sous le langage Elixir avec Erlang/OTP, et tant qu’à faire nous avons développé un petit Quiz (pour les joueurs comme nous 🤗) que vous pouvez rejoindre ici ! Plus sérieusement, le framework Phoenix est léger, ultra performant, et gère nativement bien le « temps réel » 💪. Nous explorerons dans cet article ce qui rend ce framework puissant et nous vous donnerons quelques clés pour savoir quand l’utiliser.

 

Erlang, la machine virtuelle

Erlang, abréviation de Ericsson Language, est un langage créé pour faire fonctionner des applications téléphoniques, par Joe Armstrong (qui nous a quittés le 20 Avril 2019 😢), Robert Virding et Mike Williams de Ericsson. Le langage était opérationnel dès 1988 et a beaucoup évolué depuis. Notamment grâce au développement de BEAM (parfois appelée EVM), la machine virtuelle qui permet d’exécuter du bytecode (byte pour octet en anglais, off course), de la même manière que la JVM permet d’exécuter du bytecode Java.

Erlang se différencie de la majorité des langages populaires car c’est un langage fonctionnel (dans le sens Functional Programming, par opposition à l’Object Oriented Programming) et concurrent. Il est open-source depuis 1998.

 

OTP, les indispensables librairies

Open Telecom Platform est une suite de composants d’architecture (= librairies) pour les applications Erlang : démarrage et redémarrage des applications, monitoring et gestion des erreurs, serveurs de données, gestion de l’état de l’application, interface avec le système d’exploitation, gestion des évènements, etc. Ces librairies sont en production depuis plus de trente ans et sont testées, re-testées, et améliorées en permanence. C’est très probablement une des plateformes les plus stables que l’on puisse trouver 💪 !

La gestion avancée des erreurs et des pannes, la distribution sur plusieurs machines et l’isolation de chaque processus permettent d’avoir un système très puissant et résistant aux erreurs. Par exemple, vous pouvez utiliser Erlang pour gérer les conversations de 900 000 000 d’utilisateurs comme le fait Whatsapp (!) afin que votre système ne tombe pas quand une/des erreurs surviennent (car pour un service il faut toujours savoir gérer les erreurs d’autant plus un service de masse). Ainsi, vous pouvez cantonner une erreur à une seule conversation, là où elle a eu lieu. De plus, comme on parle de code en production, il n’est pas possible d’aller déboguer rapidement, le plus simple est de laisser crasher le processus responsable de cette conversation puis de le relancer, très rapidement, afin que cela soit transparent pour l’utilisateur. C’est cette philosophie et ce design qui ont permis à Ericsson en 1998 d’obtenir une disponibilité de 99,9999999 % (mesuré sur une année entière !) sur leur commutateur téléphonique AXD301. Cela signifie que sur cette année, le service a été indisponible pendant moins d’une dixième de seconde au total, pas mal 🏆 ! Il est également possible de déboguer du code et de recharger le nouveau code pendant que celui-ci est utilisé pour assurer une conversation téléphonique. Cette démonstration a été présentée dans le film « Erlang, The Movie » qui ne brille malheureusement pas pour ses qualités cinématographiques…

 

Elixir, le langage de programmation

Erlang est compilé pour la machine virtuelle BEAM, cela signifie que l’on peut créer d’autres langages qui seront compilés pour cette même machine virtuelle, et il y en a plusieurs, le plus connu étant Elixir créé par José Valim en 2011. De la même manière, on trouve plusieurs langages compilés pour la machine virtuelle Java (JVM) comme Clojure, Scala, Groovy, Jython, Jruby etc. La machine BEAM permet l’interopérabilité de tous les langages compilés pour elle, donc l’ensemble des librairies Erlang sont disponibles pour Elixir, notamment OTP.

Elixir apporte son lot de fonctionnalités comme des outils de compilation et de déploiement, un système de « macros hygiéniques » offrant des possibilités quasi-infinies en méta-programmation (générer des programmes, faire écrire du code par du code… le graal 🏁) ou encore une syntaxe inspirée de Ruby qui a permis de le rendre très populaire parmi la communauté des développeurs – alors que Erlang reste un langage beaucoup plus confidentiel. Cela a donné naissance aux librairies qu’on attend d’une plateforme mature : gestion de fichiers de données ; connexion à MySQL, PosgreSQL, SQLite, et un ORM (Ecto, qui n’est pas vraiment un Object Relationnal Mapper puisque Elixir n’est pas un langage Object Oriented, mais fonctionnel) ; tests unitaires ; cryptographie (déjà largement développée en Erlang) ; documentation ; logs ; authentification, etc.

 

Phoenix, le framework léger

Parmi les développeurs attirés par ce nouveau langage on trouve Chris McCord qui faisait partie des développeurs de Ruby On Rails (le framework web le plus populaire pour le langage Ruby). Chris McCord a publié la version 1.0.0 de Phoenix en Août 2015 et le framework n’a cessé de s’améliorer depuis. Originellement proche de Rails, Phoenix n’en garde aujourd’hui que les aspects les plus extérieurs : organisation des fichiers (templates HTML, code JavaScript et Styles), gestion des URLs (routing), … Le cœur du système tire parti d’Elixir pour offrir de nombreuses fonctionnalités avancées. Par exemple, le système de routage, bien que reprenant la syntaxe de Ruby On Rails, est directement compilé, le rendant bien plus optimisé.

La distribution qu’offre Erlang sur tous les processeurs de plusieurs machines permet de gérer un nombre « monstrueux » de requêtes en parallèle 📈, ce qui est parfait pour créer des APIs à forte capacité. Cela est d’ailleurs possible grâce à CowBoy, le serveur HTTP intégré à Phoenix, développé en Erlang qui fonctionne comme si chaque requête arrivant avait son propre mini-serveur HTTP dédié (toujours dans le but de laisser crasher seulement le mini-serveur quand une erreur survient au lieu de devoir redémarrer tout le serveur d’API). CowBoy gère HTTP 1, SPDY et HTTP 2. Il est cependant toujours avantageux d’avoir un serveur Nginx pour servir les fichiers statiques (images, documents, etc.). Un système concurrent permet aussi de se passer d’outils externes pour gérer la communication entre requêtes (par exemple pour un tchat) ou lancer des opérations longues. Là ou en PHP on se baserait par exemple sur Redis pour avoir un système de messaging ou de job queues, il suffit avec Elixir de lancer un processus concurrent et de le laisser faire son travail sans s’en préoccuper 😎. Et quelques lignes de codes supplémentaires suffisent à gérer les erreurs et relancer les opérations échouées. Il est aussi possible de paralléliser les tâches : vous avez un très gros fichier à traiter, vous avez deux serveurs ayant chacun quatre CPUs ? Vous pouvez donc découper votre fichier en huit et le traiter beaucoup plus vite.

Phoenix et CowBoy offrent nativement la gestion des websockets, ce qui rend inutile les outils extérieurs comme Pubnub ou Pusher pour offrir des expériences riches et interactives. Une simple URL peut devenir un point d’entrée websocket et gérer la communication avec le navigateur en temps réel ! La librairie JavaScript fournie par Phoenix est très simple d’utilisation et est aussi disponible pour les applications mobiles.

Phoenix est simple d’utilisation parce qu’il permet de s’affranchir des concepts de concurrence et de gestion des erreurs : il fait ça pour nous. Le code que le développeur écrit au quotidien reste simple et focalisé sur les fonctionnalités à fournir. Traditionnellement, les frameworks web les plus populaires d’un langage sont généralement de grosses machineries, comme Symfony pour PHP par exemple (ce qui ne lui enlève rien). À contrario, Phoenix reste relativement petit, il constitue essentiellement une surcouche d’Elixir qui organise et met en valeur ses capacités pour le monde du web.

 

Qui utilise Elixir et/ou Phoenix ?

SquareEnix, parmis les plus gros développeurs de jeux vidéo, pour leurs APIs. Bet365, l’une des plus grandes compagnies de paris en ligne, pour servir six millions de requêtes HTTP par seconde. Whatsapp gérait neuf cent millions d’utilisateurs en 2015 avec une équipe de cinquante ingénieurs seulement, grâce aux capacités d’Erlang/OTP. Discord a pu gérer cinq millions d’utilisateurs en simultané grâce à cette technologie, notamment sur le salon de discussion dédié à Overwatch (un jeu vidéo) qui comptait trente mille personnes. Le Financial Times pour fournir un ensemble d’APIs REST puis GraphQL.

Ce sont quelques exemples pour des projets à haute disponibilité, mais Phoenix fonctionne également très bien pour des projets beaucoup plus petits parce que le système est léger et la concurrence fonctionne tout aussi bien avec peu de RAM (les processus sont très légers) et un seul CPU core (le langage gère lui-même la répartition du temps machine entre les différents processus, comme un système d’exploitation). De plus, les librairies existantes (job queues, events, messaging, bases de données internes) permettent de créer un système complet en un temps record sans outils externes (MySQL, Redis, Pusher, CRON, Semaphores) : créer un prototype est simple, et le code utilisé repose sur des librairies largement utilisées en production.

 

Notre avis sur le framework Phoenix

Le framework Phoenix s’appuie sur la stack Elixir & Erlang/OTP, et celle-ci a été créée pour gérer des problématiques de communication de masse en temps réel. Sa performance, sa robustesse et sa capacité à traiter en parallèle des tâches de manière indépendante en font un outil formidable pour les échanges d’informations, d’où son succès pour des applications comme Whatsapp. Par ailleurs, pour les mêmes raisons, il est particulièrement bien adapté pour gérer les échanges entre applications et, par exemple, il est très intéressant pour le développement d’un moteur d’API (schématiquement un Web MiddleWare 😉) car il est capable de traiter indépendamment les appels et les retours pour chaque connexion externe. Néanmoins, si Phoenix est très efficace pour les traitements, il nous semble un peu léger pour les développements d’outils de gestion ou de plateformes publiques. En effet, sa force est sa simplicité mais dans le cadre de développements front-end, il nous semble qu’il manque de librairies et de retours d’expérience de développeurs comme sur les grands frameworks tel que Symfony ou React. Ainsi, le framework Phoenix nous paraît particulièrement adapté pour prendre en charge des applications principalement back-end de communication que ce soit pour des échanges de données à la volée ou de données structurées comme un Moteur d’API.

PS : Cliquez sur le bouton pour jouer, seul ou avec des amis, au quiz Agilap développé sous le framework Phoenix :

JOUER AU QUIZ AGILAP SOUS PHOENIX

Bons projets et à bientôt, l’équipe d’Agilap 🌈

Categories: Techno

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Related Posts

Techno

Moteur d’API, le web MiddleWare !

Il est loin le temps où le web était la dernière roue du carrosse du SI. A cette époque, un des enjeux était de relier les différentes applications majoritairement non web d’une société, pour ce Read more…

Projet

C’est quoi le développement web durable ?

« Euh, ça ne marche plus ! » 😡. Petite phrase simple à laquelle a déjà été confronté n’importe quel utilisateur du web. Ce qui peut se traduire chez un client par : « Euh, mon site ne fonctionne plus du Read more…

Projet

Et si on jouait aux Legos ?

Assis au milieu d’un parterre de Legos, ma nièce de 3 ans me demande « Tonton, construis moi un bateau ». Là où ses parents auraient aligné quelques plaques bleues pour la mer et entassé artistiquement les Read more…