Migration API - Python => TypeScript

[lsagetlethias]

Objectifs

Stack utilisée

• TypeScript
• Nextjs
• postgres lib

Tech

• 928

• 929

• 930

• 931

• 932

• 933

• 934

• 935

• 936

• [ ] Setup ExcelService

Implémentation

• [ ] Route PUT: /declaration/{siren}/{year}
• [x] Route GET: /declarations/{siren}
• [x] Route GET: /declaration/{siren}/{year}
• [ ] Route PUT: /representation-equilibree/{siren}/{year}
• [x] Route GET: /representation-equilibree/{siren}
• [x] Route GET: /representation-equilibree/{siren}/{year}
• [ ] Route POST: /declaration/{siren}/{year}/receipt
• [ ] Route POST: /declaration/{siren}/{year}/objectifs-receipt
• [ ] Route GET: /ownership/{siren}
• [ ] Route PUT: /ownership/{siren}/{email}
• [ ] Route DELETE: /ownership/{siren}/{email}
• [ ] Route GET: /me
• [ ] Route POST: /simulation
• [ ] Route POST: /simulation/{uuid}/send-code + mark as deprecated
• [ ] Route GET: /simulation/{uuid}
• [ ] Route POST+GET: /token or change security
• [ ] Route GET: /search
• [ ] Route GET: /stats
• [ ] Route GET: /config
• [ ] Route GET: /jsonschema.json
• [ ] Route GET: /validate-siren
• [ ] Route GET: /entreprise/{siren}
• [ ] Route GET: /healthz ehanced for app status + api status

---

Étude de faisabilité

Context actuel

• Bare Python 3.6+ sans framework
• API simple
  • on top roll et gunicorn (+ hupper pour le développement local)
  • gestion d’un JWT
  • pas de documentation api exposée (ni swagger, ni api.gouv)
  • REST classique, pas de graphql
• pas d’i18n (pas de besoin actuellement)
• httpx pour les appels externes
• Jinja2 pour les templates de mail
• exposition d’un binaire type CLI (via minicli) pour des commandes relatives au projet (exports, manipulation de base de données, webserver local)
• sentry en utilisation standard (pas de setup de contexte ou de breadcrumbs, juste les logs et erreurs http)
• pas d’enregistrement d’actions (as events)
• pas d’architecture standard en place (ni ddd, ni microservice, ni cqrs/es)
• base de données en pgsql (via asyncpg)
  • migrations écrites à la main et exécutées via la CLI custom
  • modèle de données organique et non documenté (MCD/MPD)

Besoin

Prio 1

• reprise en main du code, bonnes pratiques et standards en place
• code maintenable par la team SRE en cas de besoin
• architecture scalable, évolutive, et adaptative
• application deployable sur les nouveaux services de la Fabrique
• iso à ce qui est déjà en place

Prio 2

• modèle de données retravaillé
• v2 d’api avec des routes plus descriptives des besoins externes et des fronts
• authentification plus sécurisée et maintenue sur l’ensemble des modules

Solutions proposées

Technologies (non exhaustif) :

• TypeScript
• PostgreSQL
• Express
• Nestjs
• Serveless on top Azure functions, ou autre serverless style API manager
• Hasura

Solution 1 - Base solide + Copycat

Migration “copycat” de l’API vers une architecture techniquement plus solide et plus maintenable pour la team SRE.

Le modèle de données actuellement en place est gardé (et idéalement documenté).

Les routes d’API sont copiées une par une, permettant d’itérer facilement de la version Python (considérée comme legacy) vers la version TypeScript, considérée comme v2 tout en maintenant un service opérationnel en continu.

Les features additionnelles seront ensuite développées suivant la même stratégie produit actuellement en place.

Solution 2 - Base solide + Domaines métiers

Reprise de la base technique de la première solution en tant que base de développement et refonte du modèle de données sur un concept “lean DDD” afin de définir des domaines métiers distincts et compréhensibles ou au moins, des objets un peu plus représentatifs de ce qui est manipulé par l’utilisateur.

Cette solution peut être faites en deux temps (en commençant par la base technique de la solution 1, et en faisant en sorte qu’elle soit prévue pour) afin mieux jalonner les développements.

Solution 3 - Domaines métiers + Hasura

Cette solution suggère de commencer par la refonte du modèle de données évoquée dans la solution 2 afin de brancher un Hasura par dessus par la suite.

La distinction des domaines actuels et futurs permettrait potentiellement de conduire a une architecture microservices.

Matrice de faisabilité

Migration API - Matrice de Faisabilité

[devthejo]

si je peux me permettre une suggestion: https://github.com/porsager/postgres à la place de knex see https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf410349856c c'est juste une proposition, ouvert pour en discuter la semaine prochaine si vous voulez