CaaS : Content As A Service et architecture découplée

Content As A Service une approche “Content Centric”

Aucune organisation n’ignore désormais l’importance des contenus. Au-delà du traditionnel aspect référencement, le contenu doit désormais être abordé comme un flux protéiforme aux origines diverses. En effet le contenu d’une marque est généré non seulement par les services spécialisés comme la Direction Communication ou la Direction marketing mais aussi par les employés et salariés qui utilisent les réseaux sociaux. Enfin ce contenu est également produit par les consommateurs des marques. On emploie souvent le terme de « conversations » pour caractériser les flux de contenus. Partant de ce constat l’approche Content As A Service place ces flux de conversation généré par la marque au centre de l’approche technique. Ceci, en proposant une architecture qui permet de délivrer un contenu adapté, quel que soit l’interface graphique, l’application, le réseau social qui le consomme. Techniquement on utilise alors une architecture découplée.
Le découplage est une approche qui n’est pas propre à l’approche CaaS mais qui s’y adapte parfaitement. En effet le découplage répond également à l’évolution générale des sites et applications web de l’approche MPA (Multiple Page Application) à l’approche SPA (Single Page Application) nous ferons dans un autre article un focus sur cette évolution globale mais revenons au CaaS.
L’approche CaaS ou Content As A Service est donc une architecture découplée où bien souvent un CMS (Content Management System) fait office de Back Office pour la saisie et le stockage des données. On emploie également le terme d’architecture headless. Dans le cas de CaaS le backoffice va être constitué d’un CMS user friendly le plus simple et complet possible pour faciliter la saisie par différents profils non techniques. Chez DOT nous développons ce backend sur la base du CMS Drupal (ou WordPress), le front peut-être en ReactJS ou en VueJS.

Le rendu des contenus saisis en back office se fait non plus directement par des pages générées par le CMS mais via une API (Application Public Interface) qui est une interface technique qui présente des services, en l’occurrence des contenus, consommables par tout type d’application de présentation dites frontend. Ces applications de présentation peuvent être des pages Web, des applications mobiles dédiées ou bien des applications externes qui s’abonnent à ce flux présenté par l’API. De manière très schématique un flux RSS est une forme d’API qui permet de consommé le contenu d’un site d’actualités par exemple.

L’approche CaaS permet de mutualiser les contenus et de publier instantanément sur plusieurs plateformes en même temps.

Quel degré de découplage ?

L’approche CMS Headless se définit par opposition à l’architecture couplé ou classique dans laquelle le CMS génère tout le code HTML. Basiquement un CMS classique propose :

• Un mécanisme de stockage de données (Base de données)
• Un mécanisme de création, lecture, mise à jour et suppression de données (Create, Read, Upadte, Delete : CRUD) par exemple le backoffice de Drupal
• Un mécanisme d’affichage de données dans le cas de Drupal 8 avec le moteur Twig mais d’autres stacks (AngularJS, ReactJS, VueJS, etc.) peuvent être implémentées.

Dans l’approche Headless d’une manière générale le CMS propose seulement les deux premiers éléments :

• Un mécanisme de stockage de données (Base de données)
• Un backoffice qui porte les fonctions CRUD d’administration

Au-delà de cette approche générique il existe des nuances dans le découplage. Celui-ci peut-être plus ou moins complet en fonction des besoins fonctionnels finaux ou même de la méthodologie de développement choisie. Pour mieux comprendre comment nous abordons cette question dans le cadre de notre réponse examinons les avantages et les inconvénients de l’approche Headless :

C’est pour cette raison que l’approche de découplage progressif existe qui va plus ou moins conserver les fonctionnalités de base du CMS. En ce cas Drupal va générer le HTML et une partie du Javascript de rendu (on peut utiliser NodeJS par exemple à ce niveau côté serveur) et faciliter l’implémentation du Framework javascript retenu côté client.

Quelle architecture Drupal pour le découplage

Drupal 8 intègre dans son cœur des librairies qui permettent l’implémentation d’un découplage complet ou partiel. Il existe par ailleurs plusieurs modules communautaires ainsi que des distributions qui visent à faciliter cette approche.

Les fonctions du core Drupal

Dans Drupal 8 les entités qui représentent les contenus sont aisément accessible au format JSON ou CSV grâce aux modules suivants :

• RESTful Web Services (rest). Inspiré de RestWS de D7 RESTful expose les entités et autres ressources via RESTful web API. Il depend du module Serialization pour la sérialisation des données qu’il reçoit ou qu’il envoie.
• Serialization (serialization). Apporté par la couche Symfony de D8 il fournit un service e sérialisaiton des données vers ou à partir de données au formats JSON ou XML. A noter qu’il existe un module additionnel Serialization CSV qui fournit une sortie au format CSV.
• Hypertext Application Language (hal). HAL étend le module précéent pour fournir le format HAL Hypermedia. C’est le format de base du Coeur Drupal. HAL ajoute deux primitives réservées, « _links » pour les liens relationnels (c’est également utilisé par l’API Github’s Pull Request) et « _embedded » pour les ressources embarquées. Le format HAL hypermedia supporte JSON et XML.
• HTTP Basic Authentication (basic_auth). Ce module fournit une couche d’authentification de base pour l’appel aux services REST. Pour plus de sécurité et une granularité fine de la gestion des droits, Simple OAuth peut être utilisé.

Par défaut, le module REST permet les opérations GET, POST, PATCH et DELETE. Il prend en charge l’authentification de base ou de cookie et les formats HAL ou JSON. Par défaut ces paramètres sont modifiables via fichier de configuration.

Les modules additionnels ou alternatifs

Les modules du cœur Drupal sont suffisants pour les besoins les plus basiques mais la communauté a mis à disposition plusieurs modules pour faciliter la vie des développeurs et des webmasters.
REST UI : Ce module permet de modifier les paramètres via une interface graphique et ce par ressource et par gestion des droits utilisateurs :

OpenAPI : comme souvent la documentation de l’API bien que primordiale pour les développeurs souahitant l’utiliser est le parent pauvre le module OpenAPI d’Acquia apporte une réponse à la documentation automatique de l’API.

JSON API : JSON API est une alternative aux modules du cœur de Drupal qui se focalise sur les contenus. En effet contrairement à RESTfull il ne gère pas les endpoints (point d’accès aux web services) suivants :

• /session/token
• /user/register
• /user/login
• /user/login_status
• /user/logout

Dans le cas du site de la présidence ou l’API doit présenter les contenus et où il n’y a pas de partie logguée dans le site JSON API est parfaitement indiqué. JSON API fournit entre autres une gestion des contenus complexes (entités liées), associé à JSON API Extras il permet de personnaliser les endpoints.

Exemple de sortie JSON :

Distributions alternatives

Les distributions Drupal sont des versions de Drupal et d’un certain nombre de modules packagées pour fournir un service particulier. Souvent fournies par un éditeur aussi bien que par la communauté les distributions présentent l’avantage de faire gagner du temps lors de la mise en œuvre initiale. Néanmoins elles présentent l’inconvénient d’être parfois trop riches (avec des modules inutiles), mal maintenues, ou encore de brider les évolutions.
La communauté nous propose 2 distributions qui permettent de gagner du temps :
Contenta CMS est une distribution communautaire (Communauté sur GitHub) qui propose un Drupal sans FrontOffice avec une configuration de base adaptée à l’approche CaaS.

Reservoir est une distribution sponsorisée par Acquia et qui propose la même chose que Contenta avec une plus grande facilité de mise en œuvre (et moins de souplesse)

Avantages et inconvénients

L’approche CaaS, nous l’avons dit, vise la centralisation :

• de la production de contenus par différents types de contributeurs,
• de la gestion des conversations,
• de la diffusion des contenus sur des supports multiples.

Du point de vue des développements la mise en place d’un architecture découplée est un peu plus complexe lors de la phase initiale selon l’habitude qu’on les équipes de développement de ce type de mise en oeuvre. Néanmoins le fait que les équipes front et back aient l’obligation de se mettre d’accord sur un contrat d’interface présente l’avantage de de se pencher en amont sur le modèle de données mais après les Cependant