Dans mon article précédent, j’ai évoqué la vision technologique à l’origine de Nuxeo, nos objectifs, nos rêves les plus fous, nos réussites et nos craintes. Aujourd’hui, je souhaitais vous expliquer pourquoi nous avons décidé de remodeler entièrement la plateforme en 2006, malgré les bons résultats obtenus avec notre approche initiale.

A cette époque, nous passions vraiment trop de temps à résoudre des problèmes techniques ponctuels alors que nous aurions dû nous concentrer sur la résolution des problématiques métiers rencontrées par nos clients.

Repenser entièrement une plateforme est une tâche colossale, en particulier avec une petite équipe et des ressources limitées. Avec les évolutions de Zope, nous étions conscients qu’une migration technique complexe nous attendait. Nous avons donc estimé qu’il était préférable d’investir dans une refonte totale de la plateforme afin de proposer une plus grande valeur ajoutée à nos clients et de franchir un nouveau cap.

Ainsi, nous avons commencé à re-coder Nuxeo 5 en Java.

NB : Le passage de Nuxeo CPS 3 à Nuxeo 5 n’est pas le fruit du hasard, mais je garde cette partie de l’histoire pour une prochaine fois.

De Python à Java : Pourquoi ?

En 2020, réécrire une application Python en Java peut sembler une hérésie. Mais les technologies et les tendances évoluent. En 2006, coder une application côté serveur en JavaScript aurait semblé fou, mais passer d’un framework Python à un écosystème Java plus mature avait du sens.

Le choix de Java a été motivé par plusieurs facteurs :

  • adéquation avec les attentes des services informatiques
  • performances de la JVM, en particulier avec le multithreading
  • le code et la communauté existants

Avec le recul, nous ne regrettons pas notre décision :

  • Java nous a vraiment aidé à être reconnus comme une solution professionnelle
  • nous étions (et sommes toujours) très heureux des performances de la JVM
  • nous avons pu bénéficier des multiples frameworks et technologies Java

Et pour être honnêtes, .NET n’étant pas open source à l’époque, nous n’avions que peu d’alternatives crédibles à disposition !

À l’époque, les applications Java étaient conçues de façon monolithique et nous avons dû redoubler d’efforts pour conserver la modularité et la flexibilité que nous et nos clients aimions tant avec Python/Zope.

Se concentrer sur les besoins de nos clients

Refondre la plateforme impliquait également de faire des choix. Alors que notre précédent produit (CPS) répondait à une multitude de cas d’utilisation, y compris la gestion de contenu Web, nous avons décidé de limiter Nuxeo 5 aux applications de gestion documentaire :

  • La transformation digitale générait plus de documents, pas plus de pages Web
  • Les cas d’utilisation liés aux types de documents et workflows complexes étaient plus axés sur la gestion de documents et de ressources digitales
  • Il existait déjà une multitude d’options efficaces en matière de gestion de contenu Web, notamment Zope 3

Principes architecturaux

Lors de cette refonte, nous avons retenu les enseignements de nos précédents projets et nous avons essayé d’intégrer au maximum les bonnes pratiques identifiées avec l’architecture précédente.

Développer et configurer, sans se perdre

Chaque entreprise a une relation avec le contenu qui lui est propre, ce qui rend la personnalisation essentielle. Mais cela n’implique pas de personnaliser chaque projet à 100 %. Nous avions seulement besoin de proposer une plateforme configurable.

La différence peut sembler mince, mais celle-ci a eu un impact considérable sur notre capacité à maintenir et à faire évoluer l’application.

Nous avons développé un modèle de configuration et de développement assurant une distinction et une séparation claires entre les personnalisations et extensions associées à un projet et la plateforme par défaut. Ce modèle est le fruit de notre expérience avec Zope et Eclipse RCP/OSGi (Kudos à Bogdan sur ce sujet !).

C’est ce qui a donné naissance à cette architecture basée sur des plug-ins, où chaque projet peut reposer sur la configuration de différentes parties de la plateforme. Cette décision initiale nous a également permis de développer la plateforme de façon progressive, un plug-in à la fois. Aujourd’hui, cette architecture moderne et flexible est l’un des facteurs qui poussent nos clients à opter pour la plateforme Nuxeo.

Adaptateurs de stockage

Ce modèle basé sur des plug-ins nous a également permis de développer les notions d’implémentations et d’adaptateurs de stockage.
L’expérience proposée avec CPS nous avait prouvé la pertinence de ce modèle et nous avons ouvert le référentiel documentaire aux intégrations, car nous savions que la première version (basée sur JCR) aurait besoin d’être remplacée dans un avenir proche.

Cette idée d’adaptateurs de stockage nous a permis de développer la plateforme Nuxeo en suivant l’évolution des technologies (par ex. le choix de NoSQL) et d’adapter la capacité de stockage en fonction des besoins du projet et des solutions Cloud. Tout cela a permis à la plateforme Nuxeo de devenir l’une des plateformes de services de contenu les plus flexibles du marché.

Un méta-modèle abstrait

L’élément le plus important de notre architecture est l’application d’un méta-modèle aux documents.
Nous voulions ajouter cette couche abstraite pour plusieurs raisons :

  • l’utilisation d’un adaptateur de stockage nécessitait de définir un modèle abstrait commun
  • nous savions qu’il était impossible de tout réussir du premier coup, et cette couche abstraite allait nous être utile
  • les technologies évoluent et nous voulions être en mesure d’en adopter de nouvelles sans opérer une refonte complète ou impacter certaines fonctionnalités

Ce méta-modèle (qui masque une partie des détails techniques les moins séduisants) nous a également permis de développer l’environnement de configuration Nuxeo Studio, qui symbolise aujourd’hui la philosophie de notre plateforme : nous permettons à nos clients de créer et configurer leurs applications aussi vite que possible, avec le moins de code custom possible.

Voici pour cette présentation de la base technologique de la plateforme Nuxeo que nous connaissons aujourd’hui. Cette vision, née il y a plusieurs années, nous permet de proposer aujourd’hui la plateforme la plus évolutive du marché. Nous sommes fiers de nos décisions et de la direction prise pour répondre aux évolutions du marché. Et nous sommes fiers de voir nos clients créer de nouvelles applications et intégrer rapidement de nouvelles technologies. Cloud, NoSQL ou services d’IA, nous sommes fiers de proposer à notre communauté une plateforme capable de s’adapter aux nouvelles réalités du marché.