[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...
There was a problem hiding this comment.
De ma comprehension dans cette solution 1
- on a plusieurs types de tenants (grand public, parcoursup)
- sur une meme application (pix-api) partageant un meme code metier
- mais faisant appel a des base de donnees separees par usager (bdd pix pour un utilisateur grand public, datamarts pour parcoursup par exemple)
- et on personnalise l'experience de l'usager en fonction de la configuration faite pour l'usager (API consommables)
- et la solution 1 se distingue de la solution 4 sur la base suivante
- Multitenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants.
Peux-tu m'aider a comprendre la difference entre multitenancy et la description ci-dessus afin de m'ameliorer sur la comprehension du terme multitenancy ?
There was a problem hiding this comment.
je viens d'avoir une epiphanie, il faut qu'on partage la meme notion de "tenant" !
Tu dois voir un tenant a la maille d'un utilisateur (une ecole, une lycee), et moi je vois un tenant en tant que groupe / organisations (pas orga au sens pix). Un tenant peut tres bien avoir X utilisateurs d'ailleurs.
Contrairement a "avant", on voit recemment l'apparition du concept de tenants je trouve chez Pix.
Avant on avait qu'un seul groupe d'usagers, un seul tenant. Maintenant on distingue, et on en a deja 2 avec Parcoursup. Et on voit deja avec parcourup que la complexite n'est pas minimum, et que l'architecture n'est pas inchangee.
Avec un schema, avec par exemple en orange le tenant "grand public" (ecoles, eleves) et bonhomme vert par exemple le tenant "Parcoursup" (qui aussi a comme utilisateurs d'ailleurs des ecoles et des eleves, mais on va pas taper dans les memes BDD).
| 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.
There was a problem hiding this comment.
pix-api-data est aussi servi avec hapi+joi+swagger, on a donc exactement les memes outils dans le code api-data que la solution 1 ou 4 (avec le meme besoin de dev specifique pour documenter les api).
J'ai tendance a me dire que pour dire que quelque chose est un inconvenient, il faut que cet inconvenient soit propre a la solution.
En quoi api-data a specifiquement sur sa documentation un inconvenient qui n'est pas le meme par exemple que la solution 1 ou 4 ?
There was a problem hiding this comment.
Le problème de l’API Data c’est qu’elle utilise un endpoint générique, qui ne décrit pas les données qui peuvent être récupérées.
En version très résumée, ce endpoint reçoit un identifiant correspondant à une requête SQL, il exécute cette requête SQL, puis renvoit le résultat.
| 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
| - 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
| * 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.
There was a problem hiding this comment.
Du coup actuellement dans votre proposition d'ADR, dans la solution 4, la gateway pointerait donc vers le hostname de l'application PaaS au lieu de pix.api.fr c'est bien ca ?
Si oui, je voulais justement proposer a cet ADR de justement supprimer la gateway, et que gateway.xxx.pix.fr devienne le DNS de l'application de la solution 4.
J'y vois un gros avantage en + pour la solution 4 contrairement a la 1 par exemple.
Que pensez-vous de cette proposition cote maddo ? @1024pix/team-captains ca semble faisable / interessant comme proposition ?
|
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
nlepage
force-pushed
the
pix-adr-maddo
branch
from
ea14667 to
9ca141b
Compare
| * Pour que Maddo puisse démarrer, il lui faut attendre le déploiement de l'API, afin que les migrations sur la base de | ||
| données Pix aient été faites. | ||
|
|
||
| ## Décision |
There was a problem hiding this comment.
👻 Ajouter une note sur la problématique d'anonymisation. Que ce soit pour dire que cette problématique est « naturellement » prise en compte par la solution, ou, pour dire que cette problématique n'est pas à prendre en compte dans cet ADR mais plutôt dans le processus de production des données froides, ou alors pour ajouter des points supplémentaires à cette décision si c'est ici que cette problématique d'anonymisation doit être prise en compte.
VincentHardouin
force-pushed
the
pix-adr-maddo
branch
from
9ca141b to
051737b
Compare
pix-service-auto-merge
force-pushed
the
pix-adr-maddo
branch
from
051737b to
6556022
Compare
Co-authored-by: Nicolas Lepage <19571875+nlepage@users.noreply.github.com> Co-authored-by: Guillaume Lagorce <guillaume.lagorce@pix.fr> Co-authored-by: Vincent Hardouin <vincent.hardouin@pix.fr>
pix-service-auto-merge
force-pushed
the
pix-adr-maddo
branch
from
6556022 to
03d0180
Compare
🥞 Problème
Voir ADR