Qu’il soit textuel ou multimédia, le contenu est aujourd’hui massivement présent dans nos quotidiens : sur les sites en ligne, les apps de nos smartphones, les panneaux d’affichage, à la télévision et désormais sur nos montres. Jusque là désorganisées et sans réel outil de gestion centralisée, les entreprises géraient le stockage et la publication de contenu indépendamment pour chaque device. Mais cette situation évolue peu à peu et les entreprises sont de plus en plus nombreuses à mettre en place une stratégie globale en centralisant le contenu au sein d’une plateforme unique, pour le diffuser massivement via une API, rendant ainsi ce contenu pleinement réutilisable. Il y a un peu plus de deux ans, je présentais lors de cette même conférence un sujet sur l’avenir du web et comment nous allions évoluer d’applications monolithiques en architecture micro-services ou orientées composants. La communauté Drupal a très bien su négocier ce virage et appliquer les changements profonds mais nécessaires à plus de flexibilité. Grâce aux modules communautaires, et aux initiatives core telles que WSCCI et API-first, Drupal a fait de formidables avancées pour assurer l’interopérabilité avec d’autres technologies et outils. Basé sur l’expérience acquise sur un projet similaire, nous allons voir lors de cette session comment Drupal peut facilement devenir une plateforme COPE (Create Once, Publish Everywhere). * Les caractéristiques indispensables d’une plateforme de gestion des contenus (production de contenu en mode collaboratif, workflow, promotion sur les réseaux sociaux) * ce que d’autres solutions analogues proposent. * les différences fondamentales d’une utilisation de Drupal en mode traditionnel (coupled, progressively decoupled, decoupled) et les problématiques associées. * comment Drupal peut se positionner dans ce segment.

1. CRÉER UNE FOIS, PUBLIER
PARTOUT GRÂCE AU
DÉCOUPLAGE D’APPLICATIONS
ET À LA MISE EN PLACE D’API
Julien Dubreuil
Consultant Drupal spécialisé dans les
problématiques Back-end, industrialisation
et qualité

2. SOMMAIRE
1. Retour sur 2014 et l’avenir du web à
cette époque
2. Ce que cela signifie de découpler son
site
3. Comment mettre en place une telle
stratégie avec Drupal
4. Faire du content-as-a-service
5. Quels projets pour une telle
architecture

3. Julien Dubreuil
Contributeur Drupal depuis 2009
Co-organisateur du groupe utilisateurs
Drupal à Paris depuis 2011
@juliendubreuil
Juliendubreuil.fr
Consultant Drupal spécialisé dans les
problématiques Back-end, industrialisation
et qualité
2 ans en tant qu’indépendant
3 ans chez Commerce Guys
3 ans au Figaro

4. 2014, CE QUE L’AVENIR
NOUS RÉSERVAIT
1.

5. Applications monolithiques
VS
Application micro-services

13. Drupal et WP peuvent alors être
considérés comme des solutions
monolithiques
• Themingcompliqué
• Courbe d’apprentissage trop grande
• Manque de ressources disponibles
• Frustration des Dev Front

16. Des Webhooks qui permettent à
l’application consommant l’API
de réagir en cas de modification
Une API REST qui
retourne bien
souvent du JSON
Des contenus accessibles
via une API REST
Un CMS dans le cloud du
stockage des contenus
Une interface web
pour l’édition de
contenus Content-as-
a-Service
(CaaS)

17. La tendance des solutions CaaS
Pour les équipes
techniques
Pour les
développeurs
Pour les
entreprises
Séparer les problématiques
Back-end et Front-end
Permet aux équipes de
travailler en parallèle.
Pas de perte de temps à
monter en compétence
Utilisation des dernières
technos et techniques
Mutualiser et réutiliser leurs
contenus
Publier instantanément sur
plusieurs plateformes en
même temps

18. • Pas de front-end, ce n’est qu’un endroit
pour stocker du contenu
• Limité en terme d’outils d’édition
• Très peu adaptable aux besoins, voire non
modifiable
• Délaisse toutes les problématiques de
présentation aux développeurs front-end
Pour le
meilleur
et pour
le pire

19. TECHNIQUEMENT,
DÉCOUPLER SON
SITE CA VEUT DIRE
QUOI ?
2.

20. • Un CMS utilisé comme gestionnaire de contenus
• Des contenus sont accessibles via une API REST
• Une API REST retourne bien souvent du JSON
• Une interface web pour l’édition de contenu
Back-end
• Une interface graphique développée de A-Z
• Bâti avec des technologies Javascript
modernes
• Une consommation de contenus via des
webservices,
• Une transformation de JSON en HTML
Front-end
Serveur Client
Requête
Réponse

21. Couplé, Découplé
& Co
« Couplé » ou « Classic », est l’utilisation normale de
l’outil. Drupal est chargé de générér du HTML qu’il
renverra au client
L’autre option est le mode découplé, ou Drupal n’est
chargé que de mettre à disposition des données et
l’équipe front-end de les consommer et afficher.
Il existe une alternative, un mixte entre les deux
appellée « Progressively Decouple ». Dans ce cas,
Drupal est utilisé comme outil de génération de
contenu pour l’équipe front-end tout en étant
capable de fournir de la donnée via une API pour
des éléments de pages.

22. Avantages du Headless
• Flexibilité et contrôle total pour les devs Fronts (plus limité par Drupal et
Twig)
• Le front devient plus facilement interchangeable.
• Pas besoin de migrer des contenus pour changer le front.
• Permet de faire travailler l’équipe Back-end en parallèle de l’équipe Front-
end
• Moins de dépendance envers les spécialistes Drupal
• Un endroit unique de contribution de contenus

23. Inconvénients du Headless
• Les fonctionnalités «out-of-the-box » deviennent (content preview, action
links, in place-enditing)
• Il faudra réinventer la roue (password reset)
• D’un site web on passe alors à un écosystème (coût de maintenance, coût
de hosting, coût d’évolution)
• Une application composée de plusieurs couches augmente aussi la
complexité de celle-ci (debug plus compliqué. fort besoin de loguer les
échanges)

24. Inconvénients du Headless
• Une séparation stricte entre les données et l’affichage doit être faite et
perdurer (une modification de structure dans le Back-end peut avoir des
conséquences sur l’une des applications front)
• Potentiellement besoin d’une équipe technique plus importante que dans
une approche classique.
• Bye bye aux fonctionnalités de SEO native

25. EN PRATIQUE,
DÉCOUPLER DRUPAL,
ÇA DONNE QUOI ?
3.

30. Drupal 7
• Services https://www.drupal.org/project/Services
• Views Datasource https://www.drupal.org/project/views_datasource
• RESTWS https://www.drupal.org/project/restws
• RESTful https://www.drupal.org/project/RESTful
• Code custom

31. Drupal 8
Intègre désormais plusieurs modules permettant de mettre en œuvre une API
REST
• REST module
• Serializer
• HAL
• Basic Authentification

32. REST UI
La communauté a crée un module REST UI permettant de réaliser les mêmes
actions qu’un développeur devrait écrire directement depuis une UI
vous permettant alors de choisir les méthodes disponibles (GET, POST,
PATCH, DELETE), les formats (json, xml) renvoyés, et les méthodes
d'authentification (cookie ou http si le module est activé) supportées

35. Views
Permet de mettre à disposition des ressources et collections de ressources
Avantages
• Simple à utiliser
• Facile de créer un nouveau endpoint
Inconvénients
• Peut-être se retrouver limité
• Pas des plus performant pour des requêtes complexes

40. REST avec les modules core
• Web services RESTful traditionnel, centré sur les
ressources et des collections.
• Permet plusieurs formats: JSON, HAL+JSON
• Peut exposer autre chose que des entités
• Peut être étendu au moyen de plugins

41. Relaxed web services
Améliore les modules core de D8
• Traduction
• Révisions
• Fichiers attachés
• Gère les réferences UUID
Permet de faire offline. Inspired de CouchDB, le module
permet de créer une approche "offline-first” en utilisant une
librairie telle-que PouchDB ou Hood.ie.

42. Json API
• Un module contrib en accord avec le standard
http://jsonapi.org/
• Expose toutes les ressources (entitées) contenues dans
Drupal.
• Permet de filtre/trier/paginer/ des collections
• Injecte les chemins des entités liées lors de la réponse
• Permet de réduire le nombre de requêtes HTTP dues à
la connaissance des relations
• Contenu plus lisible

43. Json API Extras
• Permet d’activer ou de désactiver certaines ressources
• Surcharge le nom des ressources. Exemple: article à la place de node--article.
• Surcharge le chemin d’accès aux ressources: /jsonapi/node/article devient
/api/articles
• Permet de désactiver certains champs
• Permet d’améliorer le rendu des champs, comme pour les champs date

44. Nested data

45. Données plus
propres et
plus lisibles

46. GraphQL
• Expose toutes les entités Drupal selon le standard
graphql.org standard. (non-RESTful)
• Permet de filtre/trier/paginer/ des collections
• Injecte les chemins des entités liées lors de la réponse
• Réduit le nombre de requêtes http
• Dès l’activation du module toutes les données sont
accessibles (contrôle d’accès réalisé par Entity Access API)

47. http://example.com/jsonapi/node/article?sort=created&filter[status][value]=1
API Namespace
Bundle
Type d’entités Filtres

50. Reservoir
• Une distribution signée Acquia
• Un dépôt de contenus, configuré pour
fonctionner avec JSON API et OAuth2.
• Fonctionnelle dès son installation
• 4 axes : Contenus, API, Modélisation de contenu,
Contrôle d’accès

52. Contenta CMS
• Une distribution orienté API-first
• Maintenu par une communauté de contributeur
• Starter kit pour mettre en place une architecture
découplé
• Ce veut, simple et ne nécessitant que peut de
configuration et sans avoir besoin de connaître Drupal
• Dispose d’exemples Elm, React, Ember, Ionic, Angular

55. METTRE EN PLACE
UNE STRATEGIE
CONTENT-AS-A-
SERVICE
4.

56. Une stratégie de contenus
robuste
&
API de qualité

57. Stratégie de contenus (Phase 1)
• Analysez l’existant
• Pensez contenus et composants
• Imaginez différents rendus (page, bloc, list, teaser…)
• Déterminez les outils d’édition (prévisualisation, système de révisions,
publication à date…)
• Utilisez des contenus dédiés pour les landing pages
• Réfléchissez aux taxonomies à mettre en place pour structurer votre
contenu

58. Stratégie de contenus (Phase 2)
• Convertissez les résultats de votre audit au format de données de Drupal
• Pensez au responsive avant tout, surtout pour les images
• Utilisez les bons types de champs
• Servez vous des champs « entityréférences » dès que possible

59. Une API de qualité
Une API c’est un contrat déterminé entre le Back-end et le Front-end
• Documentée
• Versionnée
• Testable
• Permettre les réponses partielles pour filtrer ou limiter les résultats
• Résiliente
• Utiliser une stratégie de cache intelligente.
• Loguer les requêtes entrantes et les réponses

60. QUELLES
OCCASIONS POUR
DÉCOUPLER UNE
APPLICATION ?
5.

61. - S’il y a plus d’une application qui consomme du contenu
- Si vous n’avez pas d’expertise Drupal en interne
- Si l’équipe front a besoin d’un contrôle total de la structure
des pages
- Si votre projet est composé de plusieurs équipes

63. POUR ALLER
PLUS LOIN6.

64. liens & références
RESTful Web APIs
Services for a ChangingWorld
O'Reilly Media
Septembre 2013

65. liens & références
• Tag #decoupled du blog de Dries Buytaert
Dries Buytaert
http://buytaert.net/tag/decoupled
• Comment mettre en place un site Drupal « Headless »
Simon Georges
https://makina-corpus.com/blog/metier/2017/comment-mettre-en-place-un-site-drupal-
headless
• Le blog de Yineo
Yann Boisselier
https://yineo.fr/

66. Liens & Références
• Distribution Reservoir
https://github.com/acquia/reservoir
• Contentacms initiative
http://contentacms.org
• Contenta Makes Your Content Happy
Lullabot
https://lullabot.com/articles/contenta-makes-your-content-happy
• 7 Ways to Make Your API More Successful -
Daniel Jacobson
http://www.danieljacobson.com/blog/231

67. Liens & Références
• How should you decouple Drupal?
http://buytaert.net/how-should-you-decouple-drupal
• Json API, module Drupal
https://drupal.org/project/jsonapi
• JSONAPI, le standard pour construire des APIs en JSON
http://jsonapi.org
• REST 2.0 Is Here and Its Name Is GraphQL
https://sitepoint.com/rest-2-0-graphql/
• GraphQL for Drupal (Brouillon)
https://fgm.gitbooks.io/graphql-for-drupal

68. CONCLUSION

69. #tl;dr
• Drupal peut être utilisé de façon couplée (traditionnelle), découplée ou un
mixte entre les deux
• Le headless n’est pas toujours une bonne option
• Le core fournit une solution REST et il est possible de l’étendre
• Des alternatives existent telles que JSONAPI et GraphQL
• Passer du temps en début de projet à analyser et préparer le terrain pour
les contenus
• Développez une API de qualité et investissez du temps sur la
documentation

70. Credit
• Images - https://www.pexels.com
• Icones - https://thenounproject.com/

71. Questions ?
71

72. MERCI
72
t w i t t er : @ dr upagor a
Drupagora 2017 – Créer une fois, publier partout grâce au découplage d’applications et à la mise en place d’API - Julien Dubreuil
Twitter : #drupagora