[Tech] Refonte du front-end de Permacoop

[fairnesscoop]

[Tech] Refonte du front-end de Permacoop

[florimondmanca]

Permacoop devrait peut-être avoir une page publique.

On y dirait que c'est notre outil interne, dont le code est accessible, mais pas fait pour une adoption plus large ni en mode SaaS. Mais ça serait un bon endroit pour y expliquer ce qu'on y a fait.

Après tout, si Permacoop est accessible et éco-conçu, et qu'on veut noter ça quelque part, où le met-on qui ne soit pas seulement accessible à nous-mêmes ?

[florimondmanca]

@Volubyl Comme tu l'as fais en créant un milestone, j'imagine que ce ticket est encore plus gros qu'une epic. C'est une esquisse de "vers où on voudrait aller".

Peut-être que la migration vers SvelteKit est en soi une epic, qui devra se décomposer en plusieurs petites parties, sinon on avancera pas à moins de consacrer 2 personnes (code + review) pour faire ça sur une semaine.

Idem l'accessibilité est un vaste chantier. La mise en valeur de Permacoop (explications éco-conception, page publique, etc) encore un autre.

En tout cas bravo et merci pour la rédaction de ce ticket, c'est très clair et ça distingue bien les différents chantiers possibles.

Chaque thématique a une partie "Etat des lieux" et "Axe de remédiation". À mon avis on peut maintenant convertir cela en tickets "epic" organisés selon la structure Besoin (user story ou motivation technique) / Critère d'acceptation / Design-implémentation. Sur Catalogage ça fonctionnait bien, non ?

[florimondmanca]

J'ai mis à jour #214 en reprenant ton analyse ici, avec 3 "options" pour l'organisation de l'implémentation. On peut en discuter sur ce ticket-là.

[florimondmanca]

J'y ai réfléchi (ou plutôt mon cerveau s'est allumé pour y réfléchir) et au final je me dis que la taille de Permacoop et les différences entre Sapper et SvelteKit doivent probablement nous amener à traiter la refonte de Permacoop comme relevant d'une "migration de système legacy". (De fait Permacoop, est legacy aujourd'hui.)

Dans cette optique je me suis renseigné sur les stratégies générales de migration d'un système "legacy".

Il se confirme qu'une migration incrémentale est préférable : https://www.dcs.ed.ac.uk/home/rgd/sw/migrateIncrementally.html

Problem

What is the best strategy with which to execute a large, complex reengineering project?

Solution

Plan for a incremental, phased migration from the legacy to the target architecture. Decompose the legacy into sensible components. The reengineering of each decomposition becomes a phase in the project. Balance the effort involved in each phase with the available resources. Ensure that, throughout the project, there is an operational hybrid legacy/target system. Prioritise the order in which phases should take place based on the most pressing objectives being addressed first.

Dans la littérature, on trouve ça théorisé par le Strangler Fig Pattern (M. Fowler), du nom de la vigne qui encercle l'arbre et finit par le remplacer totalement.

• StranglerFigApplication, Martin Fowler
• Stranger Fig pattern, Microsoft blog
• Strangler Pattern for Frontend
• StranglerApplication pattern, or How we transformed an AngularJS application in a shiny new frameworkless application

L'idée d'une "façade" permettant de migrer progressivement ce qu'il y a derrière correspond à une formalisation de "l'Option 3" que j'ai envisagé en réécrivant rapidement #214.

• Cas concret ici : Strangler Pattern in practice.
• La nouvelle app est créée dans un nouveau dossier / projet. En prod, Nginx la sert sur un préfixe comme /app/ qui ne devait pas exister auparavant, et petit à petit l'ancienne app met à jour ses href pour pointer vers la nouvelle version.
• Il faudra trouver un moyen de garder le développement aussi "smooth" que possible. Si on peut se passer de Nginx c'est idéal je pense. On peut peut-être par exemple utiliser un reverse proxy simplifié en Node.js. http-party/node-http-proxy a l'air ancien mais peut suffire ?

Les différents billets insistent que ce pattern permet surtout de réduire le risque. En revanche, il ne facilite pas la migration en soi. La migration sera lente aussi. Le Strangler Fig Pattern permet surtout de la faire avancer petit à petit, en minimisant les risques à chaque étape. Les gros inconvénients apparaissent surtout pour de très gros systèmes :

• Requires a lot of ongoing attention to network and routing management
• When you have dozens, a refactor effort can get stuck in "adapter hell" [...]
• Make sure you have a rollback plan for each refactored instance [...]

https://www.redhat.com/architect/pros-and-cons-strangler-architecture-pattern

Il y a aussi cette idée de l'architecture sacrificielle : créer des systèmes faciles à jeter à la poubelle. Dans un contexte de migration, ça facilite une migration par StranglerFig jusqu'à l'étape finale où le legacy disparaît.

[Volubyl]

@Volubyl Comme tu l'as fais en créant un milestone, j'imagine que ce ticket est encore plus gros qu'une epic. C'est une esquisse de "vers où on voudrait aller".

Peut-être que la migration vers SvelteKit est en soi une epic, qui devra se décomposer en plusieurs petites parties, sinon on avancera pas à moins de consacrer 2 personnes (code + review) pour faire ça sur une semaine.

Idem l'accessibilité est un vaste chantier. La mise en valeur de Permacoop (explications éco-conception, page publique, etc) encore un autre.

En tout cas bravo et merci pour la rédaction de ce ticket, c'est très clair et ça distingue bien les différents chantiers possibles.

Chaque thématique a une partie "Etat des lieux" et "Axe de remédiation". À mon avis on peut maintenant convertir cela en tickets "epic" organisés selon la structure Besoin (user story ou motivation technique) / Critère d'acceptation / Design-implémentation. Sur Catalogage ça fonctionnait bien, non ?

Oui exactement!

Pour moi cette issue a plus vocation dêtre une sorte de note d'intentiion et de servir de description général au milestone

[florimondmanca]

cc @mmarchois @ip512 Curieux de vos avis sur la façon de procéder

[mmarchois]

Je serais aussi d'avis de procéder de manière progressive.
On start un nouveau projet, dans un nouveau dossier, puis on migre les composants / libs / pages etc. un à un.
Les deux cohabiterons le temps de la migration sur des URL différentes.
Ce sera aussi parfait pour init les tests sur la partie client et monter la version de Node (16).

[Volubyl]

Je serais aussi d'avis de procéder de manière progressive.

Donc tu es d'accord avec ce que propose Florimond ?

[florimondmanca]

Je clos en vertu de #405

La refonte continue mais avec une autre approche, tant pis pour le "strangler fig pattern"