search

fairnesscoop / permacoop

Open source and eco-designed ERP solution for worker-owned businesses.
MIT License
241 stars 34 forks source link

[tech] Migration Sapper -> SvelteKit #214

Closed florimondmanca closed 1 year ago

florimondmanca commented 3 years ago

Prérequis

Contraintes

Critères d'acceptation

Implémentation

Solution proposée

Option 3 : migration incrémentale selon le Strangler Fig Pattern. Un dossier client/kit où on migrera petit à petit le client Sapper jusqu'à remplacer totalement ce dernier. Les deux seront déployés en cohabitation pour éviter toute migration brutale (tout code ajouté à client/kit sera immédiatement utilisé en production).

Conséquences

Options envisageables

Dans le respect des contraintes mentionnées plus haut

Option 1
Résumé Recoder toute l'app en un coup dans une unique PR
Avantages
Risques
  • Revue de code très difficile voire impossible => risque de régression important.
  • Risque d'abandon par la ou les personnes qui prendront en charge cette masse de travail
  • Parallélisation ou relai du travail entre différentes personnes difficile
Option 2
Résumé Recoder l'app petit à petit dans un nouveau dossier \client_kit`, puis faire le switch une fois la nouvelle implémentation totalement prête
Avantages
Risques
  • Risque de régression lors du "switch" final : il faudra quand même une "recette fonctinnelle"
Option 3
Résumé Recoder l'app petit à petit dans un dossier client_kit, et déployer les deux serveurs (ancien et nouveau) en coexistance. Router les requêtes vers la nouvelle version dès que les pages le permettent, jusqu'à ce que la version SvelteKit couvre toute l'app anciennement codée avec Sapper. C'est le Strangler Fig Pattern
Avantages
  • Faible risque de régression grâce à la validation in situ des PRs au fur et à mesure de leur déploiement et utilisation par les salarié-es
  • Possibilité d'avancer la migration morceau par morceau, compatible avec du temps mobilisé le vendredi ou en inter-mission
Risques
  • La migration ne prend pas moins de temps pour autant
Option 4
Résumé Recréer un frontend non-SvelteKit, par exemple avec une approche hypermedia (Turbo, htmx, templates handlebars ou autre dans le Nest.js)
Avantages
  • Faible risque de régression grâce à la validation in situ des PRs au fur et à mesure de leur déploiement et utilisation par les salarié-es
  • Possibilité d'avancer la migration morceau par morceau, compatible avec du temps mobilisé le vendredi ou en inter-mission
Risques
  • La migration nécessite de reconcevoir Permacoop. On ne peut plus "copier-coller du Svelte".</li
  • Nécessiterait de remplacer l'API JSON par une API HTML (autrement dit, des routes "classiques" qui renvoient des templates). C'est donc aussi une reconception du backend, or celui-ci est très bien comme il est.

Implémentation

Contexte supplémentaire

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

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

Comme l'indique la documentation Sapper :

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

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

Précédents

Volubyl commented 2 years ago

@florimondmanca je suppose que tu as écarté l'option 1 ?

Si oui, as tu tranché entre l'option 2 et l'option 3?

J'ai une préférence p-e naïve pour l'option 3 même si je comprends le coté fastidueux qu'il peut y avoir

florimondmanca commented 2 years ago

L'idée était d'exposer les options dans la PR puis d'en discuter.

Personnellement je suis aussi plutôt côté option 3 aussi. J'ai créé #277 dans ce sens

florimondmanca commented 1 year ago

J'ai mis à jour l'issue pour acter que l'on décide de l'option 3 : migration incrémentale vers SvelteKit avec le "strangler fig pattern".

florimondmanca commented 1 year ago

Je clos en vertu de #405