[Tech] Refonte du front-end de Permacoop

[Volubyl]

Refonte du front-end de Permacoop

Etat des lieux

Sapper est devenu obsolète

Actuellement, le front-end de permacoop est construit avec les technologies suivantes :

• Le framework Sapper
• Svelte
• Tailwind pour la gestion du CSS

Le développement de Sapper a été arreté en faveur d'un "nouveau" framework nommé Sveltekit

Comme l'indique le Doc de Sapper

Sapper's succesor, is currently available for use. All development efforts moving forward will be focused on .

Sapper est en "maintenance" mais plus aucune fonctionalité sera rajoutée. De ce fait, il est certainement temps de migrer vers SvelteKit

Le frontend n'est pas testé

Contrairement au back-end qui possède une bonne couverture de tests, le front-end, lui n'est pas du tout tester via des tests automatiques qu'ils soient unitaires ou end-to-end

Ce type de test pourrait permettre de garantir le bon fonctionement de la partie front-end de l'application

Nous ne pouvons pas garantir que permacoop est accessible

Fairness s'insert dans l'écosystème du "Numérique responsable".

De ce fait nous souhaitons que les applications produite par la coopérative en respecte les principes.

Le numérique responsable inclut un volet visant à ne pas exclure certaines populations :

"celles peu à l’aise avec les technologies numériques, celles habitant en zone blanche, celles avec une faible connexion ou encore celles ayant un handicap. Il s’agit donc de tendre vers des services publics numériques inclusifs : des services accessibles"

source

Vérifier que Permacoop est accessible (au sens RGAA du terme) permettrait de voir si cette application est conforme aux attentes Fairness.

Nous ne pouvons pas expliquer pourquoi permacoop est éco-concu

Comme dit dans le paragrpahe précédent, Fairness se revendique du "Numérique responsable".

Le numérique responsable inclut aussi une volonté de "Réduire l’impact environnemental" du numérique

Permacoop a été construit sur des pratiques d'éco-conception mais actuellement rien ne permet de le prouver/ démontrer.

Description du besoin et pistes de remédiations possibles

Face à ces constats, je propose de mener un chantier de "remédiation" afin de pouvoir améliorer le frontend de Permacoop.

Ce chantier peut être vu comme un "milestone" (au sens Github du terme)

⚠️ ce paragraphe vise à proposer de manières succintes des pistes de remédiations. Il est fort probable que chacune de ces pistes fera l'objet d'une isssue dédiée. Dans quel cas, chacune de ces issues sera décrite et analysée plus en profondeur.

Axe : Migration depuis Sapper vers SvelteKit

• [tech] Migration Sapper -> SvelteKit #214

Une piste pour remédier à cela sera de migrer tout le frontend depuis Sapper vers Svelte kit et l'on pourrait aussi en profiter pour mettre à jour les dépendences du projet.

Je pense que dans un premier temps, l'on pourrait chercher à être simplement "iso-fonctionnel", c'est à dire faire en sorte que la version avec SvelteKit présente les mêmes fonctionalitées que la version avec Sapper.

Cela implique de veiller a ce que rien ne soit rajouter ou manquant après avoir effectuer la migration.

Axe: Tester le frontend

• [Tech] As a developer I would like to ensure my frontend code is well tested at any time #272

L'idée de cet axe est de pouvoir garantir de manière automatique que le frontend de l'application (et plus largement l'application elle-même) garde un haut niveau de qualité logicielle

Les tests automatiques sont un bon moyen de le garantir.

En vue du travail à effectuer pour l'"Axe Obsolescence de Sapper", les tests e2e pourraient être un bon outil pour inventorier les fonctionalités de l'application et garantir que l'on reste bien "iso-fonctionnel"

Dans un second temps, on pourrait aussi a améliorer la couverture de test via des tests untaires en cherchant a tester aussi bien les fonctions "utilitaires" que les composants.

Axe : Garantir que Permaccop est accessible

Ici dans un premier temps, mon idée serait de faire un audit de l'application pour déterminer la conformité au RGAA

:question-mark: Pourquoi le RGAA ? En France, le RGAA est le référenciel recommandé par l'Etat Français

Je pense que dans un premier temps, l'on pourrait se baser sur les beta.gouv et sur les tests proposés par le RGAA pour effectuer cet audit et le cas échéant essayer d'améliorer la situation.

En fin de course, soumettre Permacoop à un audit externe pourrait aussi être une bonne chose.

Pour moi le livrable serait, l'ajout d'une déclaration d'accessibilité à Permaccop

Axe : Expliquer pourquoi permacoop est éco-concu

Je crois sincèrement que Permacoop a été conçu en gardant les 115 bonnes pratiques en ligne de mire mais qu'est-ce qui le prouve aux personnes voulant utiliser permacoop ?

Pour moi cet axe aurait pour objectif de trouver un moyen pour expliquer en quoi Permacoop est éco-conçu.

[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"