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 frontend 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 sources de données distinctes, base de données ou fichiers, locaux ou distants, c’est un formidable outil de fusion et de préparation des données pour une architecture headless.

Comparer SPIP et Gatsby ?

Certains comparent SPIP et Gatsby. Comparer un CMS et un système de front-end n’a pas de sens. Il n’est donc pas question de "migrer de SPIP à Gatsby" comme on peut le lire sur le Web, il resterait à développer un backend pour Gatsby.

Que conclure ?

Une première expérience montre que les temps de réponse d’une même application réalisée avec SPIP+Gasby ou SPIP+Offline sont comparables.

Si vous voulez transformer en PWA une application SPIP existante, n’hésitez pas à utiliser le plugin Offline.

Pour une nouvelle application, l’utilisation de Gatsby s’avérera intéressante pour reporter la charge de travail sur le navigateur de l’utilisateur final en développant le frontend avec Javascript.

Mais choisissez bien votre backend : si le travail collaboratif et l’intégration de données d’origines multiples est votre challenge, utilisez SPIP (plutôt que Wordpress par exemple) comme CMS headless.