saloon : débuter simplement une application web avec erlang et angular

Posté par  (site web personnel) . Édité par Benoît Sibaud, Nÿco, palm123 et Bruno Michel. Modéré par tuiu pol. Licence CC By‑SA.
Étiquettes :
15
4
fév.
2016
Programmation fonctionnelle

Le problème des piles pour applications web

Si vous avez déjà cherché à développer une appli web moderne, vous avez déjà dû vous heurter à la question de choisir les bons composants parmi la foultitude de ceux existants… et surtout les faire fonctionner.

Premièrement, quand je parle d'applis web modernes, il faut savoir qu'elles partagent en général cette architecture :

  • un serveur HTTP,
  • un cadriciel pour exposer des API REST,
  • un cadriciel JavaScript pour la partie frontend: il consomme les API REST et met en forme les données en HTML,
  • un système de construction (build), ou plutôt des, la partie serveur et la partie frontend utilisant en général un système différent.

Bref, il fait fonctionner tout cela ensemble, vérifier les incompatibilités, etc.

Les générateurs d'applications yeoman

Le projet yeoman vise à fournir des générateurs d'applications qui intègrent des piles complètes et prêtes à l'emploi dans le domaine des applis web. Même si le projet est issu de la communauté node.js, on peut aisément écrire des générateurs pour n'importe quelle techno.

saloon, faites entrer le cowboy

Le générateur saloon (licence Apache v2) est un générateur yeoman pour débuter simplement une application web avec erlang et angular.

Webinaire erocci le 15 mai 2014: découvrez le framework REST 2.0

Posté par  (site web personnel) . Édité par Benoît Sibaud, palm123, ZeroHeure, Nÿco et Nils Ratusznik. Modéré par claudex. Licence CC By‑SA.
Étiquettes :
5
9
mai
2014
Technologie

erocci est un framework générique OCCI (Open Cloud Computing) Interface) écrit en Erlang/OTP (Open Telecom Platform, la bibliothèque standard du langage de programmation Erlang).

Le standard OCCI est un standard ouvert, défini par l'OpenGridForum, pour définir des API REST autour du cloud computing, de manière plus contrainte, et donc facilement interopérables.

Plus de détails dans la suite de la dépêche. Et si vous n'avez pas tout compris, mais que cela titille votre curiosité, nous présenterons erocci lors d'un webinaire organisé par OW2 le 15 mai. Vous pourrez y voir erocci tourner en vrai et poser des questions à l'auteur. Les inscription se passent sur le site d'OW2.

Le premier framework générique OCCI : erocci 0.1

Posté par  (site web personnel) . Édité par Nÿco, Benoît Sibaud, palm123 et Xavier Teyssier. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
13
7
fév.
2014
Technologie

erocci 0.1 vient de sortir. C'est un framework, écrit en erlang/OTP, pour construire des API OCCI (Open Cloud Computing Interface).

Qu'est-ce que OCCI ?

La principale caractéristique technique du cloud computing est de définir des services sous forme d'API REST. Le standard OCCI est un standard ouvert, défini par l'OpenGridForum, pour définir des API REST de manière plus contrainte, et donc facilement interopérables.

Jusqu'ici, OCCI a été principalement utilisé comme surcouche à des API de services d'infrastructure (IaaS) tels qu'OpenStack ou OpenNebula. OCCI est en particulier utilisé par CompatibleOne pour gérer l'interopérabilité entre services cloud.

Pourquoi erocci ?

Toutes les mises en oeuvre de OCCI sont dédiées à un type d'API particulier (en général l'API Infrastructure) avec un grand nombre de connecteurs vers des API propriétaires.

erocci est un framework complètement générique basé sur OCCI : les API sont décrites en XML et le framework gère la persistence (Mnesia pour l'instant), les différents "renderings" (JSON, XML, etc) ou même transport (HTTP aujourd'hui, mais XMPP est dans la feuille de route).

L'utilisation d'erlang/OTP ainsi que des bibliothèques cowboy (serveur web), exmpp (XMPP), jiffy (JSON) permettent d'envisager un très bon passage a l'échelle ainsi qu'une grande fiabilité.

Les prochaines étapes de la roadmap prévoient donc :

  1. XMPP comme transport ;
  2. renderings XML et OCCI (similaire aux en-têtes HTTP) ;
  3. persistence SQL et Riak ;
  4. amélioration du système de connecteurs vers des API existantes.

Tous les retours et contributions sont les bienvenus.