Pourquoi aucun CMS n'est basé sur Spring framework / Spring Boot ?

Introduction

Le framework Spring est formidable. La plupart des développeurs Java l'utilisent à un moment ou à un autre, et ils l'apprécient tous. Spring fournit une bonne injection de dépendances et de nombreuses autres bibliothèques (Spring Security, Spring Batch, Spring Boot, ...) pour résoudre les problèmes habituels auxquels les développeurs sont confrontés. 

Cela dit, Spring a des limites importantes lorsqu'il s'agit de construire une plateforme, et elles ne peuvent pas être ignorées ou évitées. La plupart des projets ne seront jamais confrontés à de telles limitations, et cet article ne doit pas être lu comme un pamphlet contre Spring ; il ne couvre que le cas d'utilisation des plates-formes, en particulier les CMS. 

Qu'est-ce qu'une plateforme ?

Le terme de plateforme est souvent utilisé sans trop de précautions. Une plateforme est un logiciel dans lequel des tiers peuvent déployer des extensions, connues sous le nom de plugins, apps, ou modules, selon le fournisseur. La plupart des CMS sont des plateformes, pour deux raisons : 

• Les développeurs doivent pouvoir déployer leurs templates et composants personnalisés.
• Un CMS se trouve au centre d'un riche écosystème pour gérer les expériences numériques. Il doit s'intégrer avec des outils d'analyse, de DAM, de CRM, d'automatisation du marketing, d'analyse SEO, des systèmes de traduction, de gestion des consentements, etc. Pour tous ces connecteurs, un mécanisme d'applications/plugins est nécessaire. 

En d'autres termes, un bon CMS est un bon logiciel pour gérer les sites web ET une bonne plateforme pour gérer les plugins/applications/modules. Appliquée au monde Java, la capacité à gérer des modules tiers implique des choix technologiques spécifiques. 

« Isolation », l'exigence sous-jacente de toute bonne plateforme Java

Lorsque vous construisez un projet avec Spring, vous utilisez un "context". A l'intérieur d'un contexte Spring, un seul classLoader est disponible, ce qui signifie qu'une seule version d'une classe peut être chargée à la fois. Cette simple limitation est impossible à surmonter et a de lourdes conséquences. En d'autres termes, si l'éditeur du CMS intègre une librairie, les développeurs qui construisent des modules/plugins devront utiliser la même version de cette librairie. Cette situation deviendrait rapidement très difficile à vivre, en particulier lors des migrations

En théorie, il serait possible d'utiliser plusieurs contextes Spring dans la même application, mais dans ce cas là, vous ne pourrez pas partager des objets / de la données entre ces contextes.Si vous avez besoin de réutiliser une couche de service partagée entre différentes parties de votre application, vous serez bloqués.

D'un autre côté, OSGi a été conçu pour offrir plus de flexibilité. Malheureusement, Spring et OSGi ne peuvent pas vraiment fonctionner ensemble. Il existe quelques solutions, mais vous serez confronté à des impasses à long terme. Pour plus d'informations, vous pouvez lire les avantages d'OSGi dans mon article sur les CMS Java Headless. 

À propos du JPMS (Java Platform Module System) et de Spring modulith

D'autres technologies sont disponibles pour la modularité en Java : JPMS (Java Platform Module System) et Spring modulith. Aucune de ces solutions n'offre la maturité et la flexibilité d'OSGi. Nous pensons que ces deux solutions sont excellentes pour s'assurer que le code de votre logiciel est divisé correctement, mais elles ne résolvent pas le cas d'utilisation spécifique du déploiement d'un code sur mesure sur une plateforme Java.

En ce qui concerne Spring Boot : Oui, Spring Boot est très populaire, et pour de bonnes raisons. Cependant, comme il est basé sur Spring Framework, il est incompatible avec OSGi. Vous devez donc choisir entre un bon CMS modulaire, ou un CMS basé sur Spring Boot, mais vous ne pourrez pas avoir les deux. 

Conclusion

Même si Spring est populaire, alors qu'OSGi est plus confidentiel, si vous cherchez une technologie qui supporte l'intégration de code Java qui suit différents cycles de vie, alors OSGi est la seule voie à suivre. Oui, OSGI a une courbe d'apprentissage plus difficile, mais après de nombreuses années avec OSGi, nous confirmons que lorsque vous prenez le temps de comprendre les concepts et la logique, les efforts en valent la peine.