[DOC] Documenter le choix de l'architecture pour la mise à disposition des données (PIX-16526). #11406
Conversation
VincentHardouin
force-pushed
the
pix-adr-maddo
branch
3 times, most recently
from
6c30acb to
d23af6a
Compare
|
Possible d'ajouter les acteurs sur les schémas ? De ce que je comprends ce sont des consommateurs des APIs ? |
|
Est-ce que datawarehouse reste en place dans ces 4 scénarios ? |
VincentHardouin
force-pushed
the
pix-adr-maddo
branch
from
d23af6a to
7595aa4
Compare
Nous avons ajouté une petite phrase, en effet le datawarehouse reste inchangé |
| #### Avantages | ||
|
|
||
| * Pas d'augmentation de la volumétrie de la BDD de production avec des données froides | ||
| * Complexité minimum : l'architecture reste inchangée |
There was a problem hiding this comment.
Ce point me semble faux : on passe sur une archi multi-tenant et c'est un changement a la fois d'architecture, et une complexite ajoutee : https://en.wikipedia.org/wiki/Multitenancy (notamment paragraphe complexity)
Je propose de remplacer le mot "minimum" qui n'informe pas le lecteur et reste tres subjectif, pour le remplacer par un court TLDR + neutre d'une approche multi-tenant
A noter que la solution 4 devrait avoir le meme texte (quand les gens consulteront l'ADR + tard, ils liront que ls solution choisie)
There was a problem hiding this comment.
On n'introduit pas le concept de multitenancy tel que défini dans l'article wikipedia que tu cites. On a déjà une seule instance qui sert toutes les orgas / centres de certif...
| Cela implique des audits de sécurité différents, et peut potentiellement provoquer des failles de sécurité. | ||
| De plus, nous ne souhaitons pas forcément avoir deux bases d'utilisateurs distinctes. | ||
| - Comme les requêtes et le schéma ne sont pas connus, les tests de non-régressions sont compliqués à mettre en place. | ||
| - La mise à disposition d'une documentation des requêtes demanderait un développement spécifique à chaque requête. |
There was a problem hiding this comment.
Ce point existe aussi dans les autres solutions :
C'est facilement automatisable (standardisable), ce n'est pas + un inconvenient que sur la solution 1 ou 4 ou on doit creer sa definition API + son swagger.js associe pour mettre a dispo la doc (ou alors de mettre aussi, comme api data, un effort d'automatisation)
There was a problem hiding this comment.
Un développement spécifique vs. s’appuyer sur du déclaratif qui permet de généré du swagger avec un outils existants est quand même sensiblement différent.
Le dév spécifique, nécessitera forcément un effort plus grand en maintenance et/ou évolution, et aussi certainement un effort de compréhension plus grand pour les personnes ne le connaissant pas.
A contrario générer du swagger à partir de Hapi/Joi est une solution déjà en place et connu dans Pix, et qui ne demande normalement pas ou peu d’effort de maintenance.
| désynchronisations. | ||
| * ce qui rend le contract testing obligatoire pour assurer la non-régression. | ||
|
|
||
| ### Solution 4 : Création d'une API de mise à disposition de données (base de code mutualisée) |
There was a problem hiding this comment.
| ### Solution 4 : Création d'une API de mise à disposition de données (base de code mutualisée) | |
| ### Solution 4 : Création d'une infrastructure de mise à disposition de données (base de code mutualisée) |
Je trouve le texte de la solution 4 un peu confusant, au final ce n'est pas une nouvelle API, c'est une infrastructure + tooling separee qui deploie le mono repo
La difference avec la mise a dispo actuelle Parcoursup (solution 1) dans cette solution 4 est la partie infra + amelioration du tooling de seeding
|
|
||
| Déplacement des données froides dans une base dédiée en utilisant l'API de Pix pour les mettre à disposition. | ||
|
|
||
|  |
There was a problem hiding this comment.
Je trouve que ce schema introduit un biais de representation qui dessert la solution 1, le datawharehouse et les exports (metabase, pole emploi) devraient aussi etre presents sur les autres schemas, ou alors il faut enlever les elements "en plus" de ce schema.
Sans cela on a l'impression que les autres solutions sont plus simples, alors qu'elles possedent la meme complexite mais avec des fleches differentes.
J'aurais aime voir les exports ACSOS et pole-emploi apparaitre dans la solution 4 pour pouvoir vraiment me rendre compte de ce que ca fait.
There was a problem hiding this comment.
Le schéma auquel tu fais référence ici est bien neutre et n'a pas de datawarehouse. Tu as dû confondre avec le schéma d'au-dessus qui présente les différents moyens de mise à dispo des données actuelles.
| - Comme les requêtes et le schéma ne sont pas connus, les tests de non-régressions sont compliqués à mettre en place. | ||
| - La mise à disposition d'une documentation des requêtes demanderait un développement spécifique à chaque requête. | ||
|
|
||
| ### Solution 3 : Création d'une API de mise à disposition de données (base de code indépendante) |
There was a problem hiding this comment.
Avis personnel : je preferais encore mettre un effort d'outillage et de support de code metier sur API Data que cette solution 3
| Cette API utilise deux bases de données : | ||
|
|
||
| * une base de données froides en base principale | ||
| * la base de données de Pix, notamment pour l'authentification et les autorisations |
There was a problem hiding this comment.
Y'a un truc que je comprends pas ici, c'est pourquoi faire appel a la BDD Pix ; si infra separe, alors BDD "pix" separee (pix-maddo) et les users sont dans la BDD "pix-maddo" sans faire appel a celle actuelle (meme schema, mais PG separes donc users separes)
ou alors proposition si le lien ne serait que pour les users : mettreen place un authorization-server (detacher la partie gestion des users/perm pour la rendre mutualisee), ca permettrait que la solution 4 ne depende plus du tout de la BDD live.
@romain-pix-cyber un avis ?
J'ai peut etre mal compris la formulation, j'essaye de bien m'assurer que il y aura, dans la solution 4, aucun appel / lien technique au backend de pix actuel (parce que sinon autant garder la solution 1)
There was a problem hiding this comment.
Effectivement l’idéal serait d’avoir un serveur d’authentification/autorisations, cependant ce n’est pas envisageable rapidement.
Que l’API MaDDo soit connectée à la BdD Pix ne répond pas que à la problématique d’authentification/autorisations.
En ce qui concerne l’autorisation, on va certainement avoir besoin à moyen terme des infos des orgas.
Ça nous permet également plus de souplesse pour la migration d’endpoints de l’API Pix vers l’API MaDDo.
| * sécurité au niveau de celle de l'API Pix | ||
| * expérience de développement favorisant l'autonomie des équipes | ||
| * séparation des usages qui a pour conséquence la sécurisation des usages à destination des applications (front) | ||
| * documentation des endpoints et données mis à disposition |
There was a problem hiding this comment.
Je suis etonne de ne voir aucun mention de la gateway Pix.
Quel est le role de la gateway dans toutes les solutions 1 a 4 ?
- facturation de ces interconnexions
- offre d'un service standardisé (documenté, testable, industrialisé)
- limitation de l'impact sur la production de Pix (performances)
Car au final pour moi la gateway est presque + une reponse aux nouveaux sujets (rate limiting, mise a dispo des endpoints de maniere separe de Pix pour le client) que les solutions proposes.
Formules autrement j'aurais aime que les differentes solutions reprennent les nouveaux sujets / besoins et decrivent comment elles permettent d'y repondre.
Par exemple un atout a la solution 4 est que elle pourrait "porter les fonctions de la gateway", la ou la solution 1 par exemple oblige le composant supplementaire de la gateway.
There was a problem hiding this comment.
Volontairement, et pour simplifier la lecture, la gateway ne fait pas parti du scope de cet ADR.
|
Merci pour le travail autour de cet ADR 🙇 |
Cette ADR ne couvre que la partie mise à disposition de données, la production de ces données fera l'objet d'une ADR future. Pour le moment nous conservons le fonctionnement actuel. |
nlepage
force-pushed
the
pix-adr-maddo
branch
from
7595aa4 to
ea14667
Compare
VincentHardouin
changed the title
Co-authored-by: Nicolas Lepage <[email protected]> Co-authored-by: Guillaume Lagorce <[email protected]> Co-authored-by: Vincent Hardouin <[email protected]>
nlepage
force-pushed
the
pix-adr-maddo
branch
from
ea14667 to
9ca141b
Compare
🥞 Problème
Voir ADR