SPIP CMS headless + Gatsby

Gatsby est bien tentant pour pouvoir profiter de l’architecture headless et produire des pages Web en Javascript capables de Progressive Web App.

Utiliser SPIP pour fournir des données structurées à Gatsby, c’est parfois souhaitable et c’est toujours possible.

Le besoin

Il y a peu, j’ai voulu transformer un site SPIP en Progressive Web App (PWA). J’ai d’abord utilisé le plugin Offline de Cerdic, qui fonctionne très bien.

J’ai voulu explorer la technique CMS headless avec Gatsby afin de tester le fonctionnement offline intégré à ce système de front-end et comparer les performances.

Gatsby + CMS headless

De quoi s’agit il ?

Un CMS headless est un logiciel de gestion de contenu qui permet aux rédacteurs de produire et d’organiser du contenu, tout en fournissant aux développeurs des données structurées qui peuvent être affichées à l’aide d’un système distinct sur le frontend d’un site Web ou d’une application.

Un CMS monolithique traditionnel est responsable à la fois de la gestion backend du contenu et de la diffusion de ce contenu aux utilisateurs finaux. En revanche, un CMS headless est découplé des problèmes de frontend, ce qui permet aux développeurs de créer des expériences riches pour les utilisateurs finaux, en utilisant la meilleure technologie disponible.

De nombreux systèmes de gestion de contenu (CMS) prennent désormais en charge un mode « sans tête » ou « découplé », ce qui est parfait pour les sites Gatsby.  [1]

Malheureusement, SPIP ne figure pas dans la liste des CMS pour lesquels Gatsby offre un plugin. Wordpress y figure, ce n’est pourtant pas un CMS headless.

SPIP Headless ?

Une page Gatsby est définie comme "une page de site avec un chemin d’accès, un composant de modèle et une requête GraphQL facultative et un composant de mise en page". Gatsby attend d’un CMS headless qu’il lui fournisse des données sous une forme structurée.

Ce peut être un module du CMS fournissant du JSON couplé à un plugin de Gatsby. Rien n’est plus facile avec SPIP : le plugin REST Factory est parfait pour cela. Mais n’est-ce pas un marteau-pilon pour écraser une mouche ? Avec un peu d’habitude, on préfèrera créer des squelettes qui produiront les listes de données au format JSON.

Mais aussi, beaucoup plus simplement dans le cas d’un projet Gatsby co-localisé avec SPIP, il est possible d’accéder directement à la base de données. Cela se fait par exemple avec le plugin gatsby-source-mysql.

Et pourquoi s’accrocher à SPIP ?

La mauvaise raison, c’est que l’on a déjà des sites sous SPIP. On ne progresse pas avec de telles raisons.

Une bonne raison (il y en a beaucoup d’autres), c’est que SPIP est excellent pour organiser la production de données au sein d’une équipe. Cela peut être géré nativement au niveau de l’espace privé qui offre de nombreux outils pour cela ; cela peut également être l’objet d’un site web SPIP ouvert au public permettant de construire du contenu selon une logique particulière.

Et comme SPIP est capable d’intégrer plusieurs base de données distinctes, locales ou distantes, c’est un formidable outil de fusion et de préparation des données pour une architecture headless.

[1] Traduction d’un extrait de https://www.gatsbyjs.com/docs/how-t....

Une idée, un projet?