Aller au contenu

ADR1

Pour écrire un nouveau document veuillez vous référer à la documentation associée.

  1. Architecture Decision Record ↩

  • dans API
  • 3 min de lecture

Import de masse

Contexte

Dans le cadre de la migration du public, de nouveaux gros clients ont besoin de pouvoir importer l'historique de leurs données. Cela concerne des millions de documents et des To de binaires.

Nous évaluons la cible à 14 millions de documents pour 7To de données.

Le gros point de blocage est le temps d'upload des binaires de nos API actuelles limitée par le réseau. Une des solutions envisagées est que les clients nous fournissent leurs binaires et que nous lancions un script effectué par notre équipe afin d'importer de façon la plus optimisée l'ensemble des données.

Afin de savoir si cette solution nous permet de vraiment gagner du temps, on crée un script d'import très simplifié pour évaluer ce temps. (https://github.com/Efalia/mgx/pull/2703)

Cet ADR détaille la durée d'exécution de chaque étape de l'import.

  • dans API
  • 2 min de lecture

Archive D.U.A.

Contexte

Dans le cadre de la fonctionnalité D.U.A./D.U.C., il faut pouvoir exporter un ensemble de documents ainsi que leur métadonnées dans une seule archive afin de pouvoir les transmettre au service des archives départementales.

Le volume de ces documents n'étant pas connu, il faut pouvoir générer à la volée cette archive sans contrainte de taille de stockage.

  • dans API
  • 3 min de lecture

Changement de l'ORM pour gérer nos entités

Contexte

Depuis le début du projet nos entités sont structurées autour du concept d'Aggregate du Domain Driven Design. Chaque Aggregate est responsable de l'intégrité de ses données et de celles de ses relations. Les objets qui sont liés dans un Aggregate lui appartiennent, par conséquent ces objets ne peuvent pas être utilisés dans d'autre Aggregate. Si on veut réutiliser une donnée d'un de ces objets alors il faut le dupliquer.

  • dans API
  • 2 min de lecture

Stratégie d'écriture des tests pour couvrir au mieux les fonctionnalités

Contexte

Depuis tôt dans la vie du projet on utilise innmind/black-box pour générer aléatoirement les données qu'on ingère dans l'API pour vérifier que l'on supporte de partout tout un jeu de caractères qu'on souhaite supporter.

Suite à une expérimentation dans le projet Efalia Safe on utilise cet outil également pour générer des tests pré-paramétrés pour pouvoir les utiliser en dépendance d'autres tests avant de faciliter l'initialisation de l'état nécessaire à ces nouveaux tests.

Connecteur Efalia Process / Efalia Doc

Il y a pour l'instant deux méthodes de lancement d'un processus impliquant un document dans Doc :

  • Soit directement depuis Process, avec la sélection d'un document de Doc via le picker de Process.
  • Soit depuis un document dans Doc, via un lien hypertext qui redirige vers Process avec le document déjà préselectionné.
  • dans API
  • 3 min de lecture

Prise en compte des features flags dans l'API

Contexte

Dans le projet il existe déjà plusieurs feature flags configuré via le QG. Pour des questions de simplicité il avait été décidé dans un premier temps de ne gérer ces flags que dans l'interface utilisateur en désactivant les éléments liés au flag.

Dans le contexte d'Efalia Safe on souhaite prendre en compte le feature flag pour ne pas déposer des documents dans le coffre si la fonctionnalité est désactivée.