Simplifier la gestion des services

[jbuget]

🍣 Contexte

data·inclusion (DI) est devenu le référentiel France Travail de l'offre d'insertion. Historiquement, le projet est issu de DORA. Avec le temps, malgré la formation de la Plateforme de l'inclusion sous forme de GIP et la proximité conservée des équipes, des différences de schéma et modélisation, ainsi que des cycles et rythme de développement sont apparues.

Aujourd'hui, dans DORA, lorsque l'on souhaite accéder en lecture (recherche d'une offre, analyse de données) à l'entrepôt de données des Services, il faut toujours avoir en tête ces différences et composer avec plusieurs couches de mapping.

Il n'existe pas de mécanisme de synchronisation régulière de la donnée. DI appelle l'API DORA régulièrement. DORA appelle l'API DI à chaque besoin de lecture.

Il n'existe pas non plus de mécanisme de mise à jour en temps réel (appel d'API d'écriture ad hoc, abonnement à des webhooks ou à une file d'évènements).

🦄 Amélioration souhaitée

Afin de simplifier le code, la réflexion métier, l'outillage et autres procédures opérationnelles, il faudrait disposer d'une modélisation de Service unifiée.

Afin d'y parvenir et pour augmenter au passage les capacités d'élasticité (scalabilité) de la plateforme, il faudrait songer à mettre en œuvre un système de cache ou de référentiel des services unifiés (DORA et DI confondus), utilisé pour la lecture.

Ça pourrait passer par une base Redis (souvent pratique et adaptée pour des problématiques de cache, même si ici, le besoin de fonctionnalités de "recherche", qui n'est pas le point fort de la solution, paraît limitant), une List (Map, Set, Hashmap) in-memory propre à chaque instance de backend, une table dédiée dans la base PG de DORA, etc.

L'intérêt de tels mécanismes serait de retrouver de la maîtrise sur cet entrepôt de données, en augmentant la réactivité du système (données prêtes à l'emploi ou pré-calculées), tout en diminuant les temps de réponses (HTTP infra DI VS. in-memory ou HTTP interne réseau DORA).

Dans le code, on finirait par se retrouver avec simplement un Repository qui dont la seule gross intelligence / responsabilité serait de penser à mettre à jour les "services DORA" du référentiel lorsqu'ils sont modifiés.

En résumé, les modifications à considérer :

• récupérer les données DI à intervalle régulier plutôt qu'à la volée
• matérialiser dans le code et/ou l'infra un espace unique avec tous les services DORA et DI, mis à jour lors de cette même synchronisation
• exposer sous une modélisation unifiée les Entités Services de ce réfentiel interne, qui est surtout un cache bien structuré
• si une édition d'un service DORA est effectuée par l'usager, alors répercuter la modification directement sur l'entrée du référentiel interne