Modularisation npm de la stack

[sylvainlg]

Salut

Comme on en a discuté avec Hugues et les autres développeurs de l'incubateur, il serait intéressant de se pencher sur une distribution sous forme de packages npm versionnés et plus d'un fork qui devra être rebase pour se tenir à jour.

Mon idée : avoir un package de base @anct/stack par exemple qui permet de charger une multitude d'autres modules qui permettraient d'activer des configurations.

@anct/stack ferait les choix les plus structurels comme NextJS / Router / i18n par exemple et mettrait à disposition une manière d'ajouter les services / pages et autres possibilités d'extensions pour que chaque service puisse ensuite customiser la stack pour ses besoins propres.

Exemple @anct/authentication et @anct/mon-compte-pro

@anct/authentication permettrait d'activer une authentification dans l'application en fournissant par exemple :

• une solution technique générique tel que next-auth
• enregistrement des modèles prisma
• mise à disposition d'un widget pour le header
• mise à disposition / enregistrement des pages génériques (signin, profil, ...)

@anct/mon-compte-pro
Serait une implémentation de connecteur next-auth pluggable dans @anct/authentication pour Mon compte pro.

---

Les solutions techniques qui pourraient être envisagées : feature-u (moteur AOP), inspiration du fonctionnement de NestJS.

---

C'est une première réflexion, dites moi ce que vous en pensez !

[sneko]

Question :

Si on part du principe qu'on a des choix métiers qui varient (auth avec MonComptePro, AgensConnect...), est-ce qu'on apporte aussi une abstraction au niveau des technologies ?

Par exemple les packages ont des chances de pouvoir resservir dans des outils hors Next.js (sauf si spécifique next-auth par exemple), donc pour le package @anct/authentication :

1. Est-ce qu'on l'intègre en dur avec Prisma ?
2. Est-ce qu'on apporte une couche d'abstraction pour que d'autres ORM puissent être utilisés ?

A première vue la (2) est bien pour l'extensibilité, mais ça va amener à gérer des cas compliqués pour rien (abstraction et donc boilerplate code...). La (1) est sûrement plus simple à réaliser bien que ce soit un parti pris en mode "on fournit une stack modulable" (donc n'espérez pas réutiliser nos briques en-dehors, ou alors faut les forker).