Architecture contributions

[m-maillot]

L'admin est aujourd'hui composé des frameworks : Next.js et Hasura. L'objectif est d'utiliser Hasura comme API et ne pas avoir d'API à gérer de notre coté.

Il y a cependant actuellement une API mise en place sur Next.js pour gérer :

• l'authentification : POST /activate_account, POST /change_password, POST /login, GET /logout, POST /refresh_token, POST /reset_password
• les fichiers stockées sur azure: POST /storage, GET /storage, DELETE /storage/[path]
• Event hasura : POST /webhooks/publication (trigger sur la table documents qui appel ce webhooks qui va mettre à jour l'elasticsearch de preprod quand on publie/dépublie un contenu)
• Action hasura : POST /actions/email_account_activation (envoie l'email pour activer le compte), POST /actions/email_password_request (envoie l'email pour changer le password), POST /actions/preview (met à jour l'elastic search de preprod avec le nouveau contenu du document)

La fusion de l'outil de contrib dans l'admin va apporter des règles métiers plus complexes que ce qui est actuellement géré par l'admin. L'idée de cette discussion est de choisir la meilleure approche pour voir l'implémentation des contributions et pour la suite sur l'outil d'admin.

Voici la liste des approches identifiées :

Logique métier dans le Next.js

Dans cette approche, on va gérer nos règles métiers dans le frontend au niveau des composants.

Exemple:
Lors de la création d'une question, je dois générer les réponses pour les conventions collectives. On va donc avoir le call dans le composant React pour créer la question, puis à la réponse sur ce call, on va faire le call pour créer les réponses pour chaques conventions collectives.

Logique métier dans Hasura

Dans cette approche, on a 2 possibilités : le gérer via PL/SQL ou via les actions/events d'Hasura.

PL/SQL

L'idée est d'utiliser une procédure stockée en SQL que l'on va mettre à disposition via le GraphQL (https://hasura.io/docs/latest/schema/postgres/custom-functions/)

Exemple:
Lors de la création d'un question, je dois générer les réponses pour les conventions collectives. On va créer une procédure PL/SQL qui prend en entrée la question et qui va se charger de créer les réponses. On ajoute la procédure dans GraphQL via Hasura et on appelle via une mutation depuis le frontend.

Actions/Events

L'idée est d'utiliser les fonctionnalités Actions/Events de Hasura. Une action va permettre de mettre à disposition une entrée dans GraphQL avec des custom inputs. Elle va ensuite transformé cette requête pour appeller une API REST avec un JSON en entrée. L'API se charge ensuite de faire la logique métier et de retourner le résultat. hasura se charge de traduire le résultat en GraphQL à l'appelant.

Exemple:
Lors de la création d'un question, je dois générer les réponses pour les conventions collectives. On va créer une API sur le Next.js qui prend en paramètre les infos pour créer la question. Dans Hasura, on crée une action qui va appeler cette API.

Logique métier dans une API

L'idée est d'utiliser des APIs en amont d'Hasura. Chaque API sera responsable de faire le call sur Hasura et d'inclure la logique métier si besoin.

Exemple:
Lors de la création d'un question, je dois générer les réponses pour les conventions collectives. On va créer une API sur le Next.js qui prend en paramètre les infos pour créer la question. On appelera directement cette API.

[m-maillot]

Logique métier dans le Next.js

Cette option ne semble pas être la plus idéale. On risque d'avoir des règles métiers fortement lié à des composants graphiques. De plus, les tests sur les règles métierr sont complexes à mettre en place.
Il y a également la partie sécurité et intégrité des données. Si le front a la possibilité de créer des réponses dans notre exemple, rien ne l'empêche l'utilisateur de rejouer la requête. On ne veut pas qu'une réponse puisse être créer toute seule. Cette API doit même être caché sur Hasura.
Il y a également l'envoie d'email. Qui n'est pas possible depuis le client également.

[m-maillot]

Logique métier dans Hasura : PL/SQL

Cette option demande une montée en compétence en PL/SQL par l'équipe et ajoute un nouveau langage dans le projet. Sa mise en place est bien supporté par Hasura même si moins poussé que les Actions. Cela demande aussi une mise en place des tests sur du PL/SQL, ce qui n'est pas en place sur nos projets.
Pour l'envoie d'email, il y a également la question de comment le faire ? On serait surement obligé de passer une API et donc une Action ou Event d'Hasura.

[m-maillot]

Logique métier dans une API

Aujourd'hui, on utilise urql pour effectuer nos requêtes avec GraphQL fourni par Hasura. Ajouter une couche API demande à revoir toute l'implémentation actuelle pour utiliser des APIs REST en json à la place de GraphQL. Cela demanderait aussi des APIs pour des simples select/update pour éviter le mélange entre call REST et GraphQL.

[maxgfr]

D'un autre côté, passer directement par l'API me semble nécessaire dans le futur dans le cas où on intégrerait un upload de documents ou d'images

[m-maillot]

Logique métier dans Hasura: Actions/Events

Cette solution est la plus proche de ce que l'on a actuellement. On garderait notre API urql pour faire les requêtes dans le front. On utiliserait le GraphQL fourni par Hasura pour des simples update/select. On passerait sur une Actions pour des update/select demandant des règles métiers.
Les tests pourraient directement tester l'API qui contient alors la logique métier.
L'envoie d'email est directement possible depuis l'API.

Cette solution semble la plus adaptée dans l'architecture actuelle.