Compétence M8
En fonction des projets déterminés autour de la « Conception et implémentation des services numériques », savoir identifier, choisir (y-c défendre) et adapter les solutions les plus appropriées pour les défis rencontrés
Projet Koloka
State management
Choisir le bon state manager : J'ai dû prendre une décision sur les différents gestionnaires d'états (state
management) dans React. Voici le tableau comparatif que j'ai fait pour prendre ma décision :
| Bibliothèque | Description | Taille de la communauté | Documentation | Performances | Flexibilité |
|---|---|---|---|---|---|
| Redux | Gestion d'état prévisible pour les applications JavaScript. | Très grande | Excellente | Bonnes, mais nécessite une configuration correcte | Haute, mais peut être verbeuse |
| MobX | Gestion d'état réactive simple basée sur des observables. | Grande | Bonne | Excellentes, en particulier pour les applications complexes | Haute, grâce à une approche plus déclarative |
| Context API (React) | Gestion d'état native de React basée sur le contexte. | Grande | Bonne | Dépend de l'implémentation spécifique, peut nécessiter l'optimisation | Faible, adaptée aux petites applications |
| Recoil | Bibliothèque expérimentale de gestion d'état pour React de Facebook. | En croissance | Bonne | Performante, prend en charge la sélectivité des rendus | Moyenne, spécifique à React, mais assez flexible |
| Zustand | Bibliothèque minimaliste pour la gestion d'état en React. | Petite | Bonne | Très bonnes, légère et optimisée | Élevée, tout en restant simple |
| Jotai | Bibliothèque de gestion d'état atomique pour React. | En croissance | Bonne | Performante, basée sur des atomes réactifs | Élevée, approche simple avec des atomes atomiques |
Le choix final a été Jotaï, car il a de très bonnes performances et une approche simple avec le pattern atomique. Cela
permet par exemple de créer un ensemble d'atom pour la fonctionnalité de chat. Mais l'élément le plus important lorsque
j'ai testé les différents state manager était la possibilité d'hydrater côté serveur un atom et le rendre disponible
de manière global dans toute l'applications. Ce qui n'est pas focément possible avec tous les state manager.
En utilise useHydrateAtom, j'ai pu hydrater les atomes côté serveur et les rendre disponible dans toute l'application :
Déploiement
Après avoir réfléchis et designé l'application Koloka avec un serveur Backend, un serveur Frontend, un serveur de base de données et un serveur de cache, j'ai dû choisir comment déployer l'application. Selon ce design, l'application Koloka ne pouvais pas être totalement héberger sur un PaaS comme Heroku ou Netlify. J'ai donc dû choisir un IaaS pour déployer l'application. Plusieurs concurrents se sont présentés à moi :
- Digital Ocean (opens in a new tab)
- Scaleway (opens in a new tab)
- Railway (opens in a new tab)
- AWS (opens in a new tab)
J'ai choisi AWS, parce que les autres concurrents ne proposaient autant de service différents que AWS. AWS propose le service RDS pour la base de données, le service Elasticache pour le cache, le service EC2 pour le serveur Backend et le service S3 pour les données statiques. AWS propose aussi un service de déploiement continu, CodePipeline, qui permet de déployer automatiquement le serveur Backend et le serveur Frontend. Amazon permet de lancé les services facilement partout dans le monde, ce qui est un avantage pour que les serveurs soient au plus proche de l'utilisateur (Edge computing) ! Ce choix est particulièremenet adapté au projet Koloka, sachant que les autres concurrents seraient de bons condidats pour des projets plus simples.
Outil de gestion de projet
J'ai du choisir un outil de gestion de projet au cours de ma formation. Celui que j'ai souvent entendu parler est Jira. Le prolème avec les outils de gestion de projet est qu'ils sont souvent très limités dans leur version gratuite. Avant d'utiliser cet outil, je m'étais familiarisé avec Plane (opens in a new tab), qui est un outil de gestion de projet très performant et surtout open-source ! C'est cela qui m'a convaincu de l'utiliser. Cependant il n'est pas encore assez mature pour être utilisé en production.
J'ai donc choisi Jira, car il est souvent utilisé dans les entreprises. Le choix de Jira se portait surtout sur le fait qu'il me serait favorable de savoir l'utiliser pour mon futur. J'utilise les deux outil de gestion de projet en parallèle, car j'aime les projets open-source et je trouve que Plane peut être un fort compétiteur de Jira dans le futur. Souvent les projet-opensource se font par l asuite de l'argent en propsant de simplifier le déploiement de l'outil en production. Ce qui est avantageux pour les personnes qui ne veulent pas s'embêter avec la configuration de l'outil. Pour ma part je préfère avoir un contrôle total sur l'outil et je préfère donc utiliser la version open-source.
L'interface de Plane est quasiement identique à celle de Jira, ce qui est un avantage pour les personnes qui veulent switcher d'un outil à l'autre.
