CMS Java headless - Guide pour les développeurs

Introduction

Les Headless CMS ont gagné en popularité au cours des 7 dernières années ; cependant, beaucoup sont des produits SAAS purs qui ne peuvent pas être étendus ou fortement customisés ; les autres sont basés sur node.js. Par conséquent, les organisations qui utilisent Java comme principal langage de backend n'ont pas de solution évidente. Dans cet article, vous découvrirez les principales caractéristiques d'un bon CMS Java headless. Et, bien sûr, comment Jahia répond à ces critères. 

Modularité avec OSGi

L'attribut le plus important d'un CMS Java, qu'il soit headless ou non, est sa modularité. La modularité est ce qui permet aux développeurs Java de customiser et d'étendre le CMS. Dans le monde Java, il n'y a qu'une seule technologie qui supporte correctement la modularité : OSGi. 

Passons en revue les principales exigences d'une bonne modularité, bien couvertes par OSGi :

• Isolation : Le problème le plus complexe à résoudre est de s'assurer que les bibliothèques que vous utilisez dans votre code n'entreront pas en conflit avec celles fournies par le fournisseur du CMS. L'isolation garantit que vous pouvez utiliser toutes les librairies que vous voulez et que votre code ne sera pas cassé lors de la mise à jour de la version de votre CMS.
• Gestion des dépendances : La gestion des dépendances entre vos modules ou entre vos modules et le coeur du CMS doit être effectuée correctement. OSGi fournit un support avancé, y compris la possibilité de déclarer des dépendances pour une gamme de versions.
• Déploiement à chaud : Si vous devez redémarrer votre application à chaque fois que vous déployez du code, votre processus de développement sera terriblement lent. Vous avez besoin d'un CMS qui prenne en charge le déploiement à chaud. Cette fonctionnalité est également utile pour modifier la configuration de votre application à la volée.
• Prise en charge du "whiteboard pattern" : Ce design pattern est le complément parfait du déploiement à chaud ; il permet aux développeurs qui codent des modules de déclarer des implémentations qui seront déployées dans la plateforme. Par exemple, dans Jahia, vous pouvez déclarer des « actions ». Les actions sont du code qui sera exécuté lorsqu'une URL donnée est appelée. Le modèle du tableau blanc vous permet de déclarer vos actions dans votre module et de vous assurer qu'elles seront prises en compte par Jahia lorsque vous déployez votre module. Le modèle du tableau blanc est basé sur des registres, chaque registre étant utilisé pour stocker les actions, les filtres, les travaux ou tout autre point d'intégration que la plateforme peut prendre en charge. Le code à l'intérieur de Jahia qui exploite le modèle du tableau blanc est le registre OSGi.
• Bonus : l'outillage. Une bonne technologie de modularité s'accompagne d'un bon outillage pour mettre à jour la configuration, déployer, démarrer, arrêter et annuler le déploiement des modules. Cet outillage doit être accessible à l'aide d'API HTTP, de lignes de commande et d'interfaces utilisateur. Jahia utilise Karaf comme implémentation OSGi, fournissant la plupart de ces fonctionnalités. Jahia a également ajouté une interface utilisateur pour déployer et gérer les modules, ainsi qu'une API de provisionnement basée sur YAML.

Modélisation du contenu

L'une des différences entre un CMS et une application classique est l'agilité requise pour gérer le modèle de données, appelé "content modeling" (modélisation du contenu) ou types de contenu. Il existe généralement deux approches pour répondre à cette exigence : 

• Le CMS qui fournit une interface utilisateur pour créer des types de contenu. Cette approche permet d'apprendre rapidement la modélisation de contenu.
• Les CMS qui permettent aux types de contenu d'être déployés en tant que code, en s'assurant que les types de contenu sont versionnés en même temps que le reste de votre code. 

Jahia est le deuxième type de CMS, offrant de nombreuses options pour la modélisation de contenu. Vous pouvez en savoir plus sur notre page présentant l'expérience développeur.

Extension de l'API

Une fois que vous avez un moyen de déployer du code Java - grâce à une bonne modularité - l'exigence la plus courante pour un CMS Java Headless serait de créer des nouvelles APIs sur mesure. 

Jahia utilise principalement GraphQL, et vous pouvez étendre les points d'API existants ou en créer de nouveaux. Cette capacité s'applique aux queries, aux mutations et aux souscriptions. Si vous souhaitez voir à quoi ressemble une extension GraphQL, un exemple est disponible dans notre repository GraphQL Github.

Autres "integration patterns"

Outre la personnalisation des API, un bon CMS Java Headless prendra également en charge d'autres modèles d'intégration, tels que :

• Les services : Code réutilisable mettant en œuvre tout comportement personnalisé
• Actions : Exécution d'un code basé sur une URL
• Jobs : Exécution du code en fonction d'un calendrier
• Initialisateurs de sélecteurs : Remplir de manière programmée les listes déroulantes ou autres sélecteurs utilisés par les auteurs de contenu.
• D'autres modèles peuvent inclure des filtres, des règles, des validateurs, des décorateurs, etc. 

Si vous voulez voir à quoi cela ressemble dans Jahia, il y a un dépôt dédié : OSGi modules samples. 

Open source / open core

Pouvoir accéder au code source d'un produit que l'on souhaite étendre ou personnaliser est souvent très utile. Cela facilite le débogage et la relation avec le vendeur. 

La plupart du code de Jahia est open source, et l'ensemble de notre base de code est accessible à nos clients. 

Expérience pour les utilisateurs métier

Il ne faut pas oublier qu'un bon CMS Java headless doit être un bon CMS. N'oubliez donc pas de vérifier les fonctionnalités pour les utilisateurs métier avec lesquels vous travaillez. Pour plus d'informations, lisez l'article Headless CMS - Quelles fonctionnalités pour les marketers ?

Couche de présentation / La tête

Si vous lisez ce billet et que vous cherchez un CMS headless, vous ne serez peut-être pas d'accord avec toutes les lignes ci-dessous... et ce n'est pas grave. Chez Jahia, nous pensons qu'une couche de présentation (générant du HTML à partir d'éléments de contenu) est toujours pratique et souvent essentielle. La capacité de rendre des pages HTML complètes ou des fragments HTML offre beaucoup plus de flexibilité qu'un CMS qui ne peut produire que du JSON. 

Jahia propose deux technologies de présentation (également appelées « templating ») : 

• JSP (Java Server Pages), technologie Java éprouvée depuis longtemps
• React JSX (JavaScript XML), qui peut être intégré dans des modules JavaScript. 

Composants complémentaires 

Un CMS seul n'est parfois pas suffisant. Si votre projet implique de travailler avec des données clients, en particulier avec une fréquence d'écriture élevée, vous ne devriez jamais stocker ces données dans un CMS. La gestion du contenu et la gestion des données clients requièrent des architectures différentes. En d'autres termes, le meilleur complément à un bon CMS est une bonne CDP (Customer Data Platform). 

Jahia contribue fortement au projet Apache Unomi. Nos clients l'utilisent pour stocker et gérer les données des formulaires, le contenu généré par les utilisateurs, les données comportementales, les préférences des visiteurs, etc.

Conclusion

En résumé, un bon CMS Java headless doit.. :

• Être modulaire et basé sur OSGi
• Fournir un modèle de données/contenu flexible
• Offrir une personnalisation/extensibilité des API
• Prendre en charge de multiples modèles d'intégration
• être un bon CMS pour les utilisateurs professionnels
• Avoir une couche de présentation (donc, idéalement, ne pas être purement headlesss)

Si vous voulez en savoir plus, vous pouvez : 

• lire notre page résumant l'expérience de développeur
• Lire la vue d'ensemble technique
• Essayer Jahia et parcourir nos tutoriels, décrivant l'intégration d'une page d'atterrissage dans Jahia.