Site d'enchères

Arrivé sur cette mission, la code base était déjà en place. De bon choix techniques avaient été fait :

• NextJS
• Typescript
• React Query
• React hookForm
• Husky

Refacto de la codebase

L'une des premières choses que j'ai proposé de faire fut de ranger intégralement la codebase. En effet, même si la stack était bonne, sa mise en application l'était moins. 

React Query était utilisé de manière brouillon, les fichiers étaient éparpillés et beaucoup de 'any' empéchaient un typage correct. Grâce à ma force de proposition et à ma capacité à construire des architectures scalables, j'ai rapidement pris le rôle de techlead. 

Mise en place archi avec React Query

React Query est une bibliothèque adaptée aux applications utilisant React pour la gestion de l'état des requêtes de données. Voici pourquoi l'utiliser :

1. Gestion simplifiée du cache : React Query gère automatiquement la mise en cache des données récupérées, ce qui permet de minimiser les appels réseau répétitifs et d'améliorer les performances.
2. Synchronisation en temps réel : Les données peuvent être resynchronisées en fonction des événements spécifiques comme la remise en avant de l'application, la reconnexion réseau, etc.
3. Gestion des états de chargement et d'erreur : React Query fournit des outils pour gérer facilement l'état de chargement (loading) et les erreurs (error) sans avoir à écrire beaucoup de code personnalisé.
4. Invalidation et actualisation des données : Vous pouvez invalider et actualiser les données en fonction de certaines actions ou événements utilisateur, ce qui assure que vos données restent à jour.
5. Pagination et infini-scrolling : Elle permet de gérer facilement la pagination et le défilement infini, deux fonctions courantes dans les applications consommant des API.
6. Amélioration de la performance : La bibliothèque utilise les requêtes en arrière-plan et la mise à jour optimiste pour une meilleure réactivité de l'application.
7. Support pour la déduplication de requêtes : React Query empêche que plusieurs composants déclenchent la même requête en parallèle.
8. API flexible : L'API de React Query est flexible et extensible, permettant des intégrations avec d'autres bibliothèques comme Redux si nécessaire.
9. Faible effort pour les requêtes côté serveur : Elle permet également de gérer les données pré-fournies par SSR (Server-Side Rendering) ou SSG (Static Site Generation) sans beaucoup de configuration supplémentaire.

En somme, React Query facilite la gestion des requêtes de données dans les applications React, en proposant une approche déclarative et efficace pour le chargement, la mise en cache, et la synchronisation des données.

‍

Si vous voulez en savoir plus, je vous invite à consulter mon article sur ce sujet :

www.phdr.dev/blog/react-query-comment-organiser-son-code

‍

Gérer l'instantanéité des enchères

Le nerf de la guerre sur ce projet, c'est les enchères. Or, pour qu'une vente se passe bien, il faut absolument que tous les utilisateurs aient la même information au même moment. C'est pour cela que j'ai choisi d'utiliser le protocole EventSource au lieu du classique Websocket. En voici les raisons :

1. Simplicité d'utilisation :
   • EventSource est plus simple à utiliser et à mettre en place pour les cas d'utilisation où le serveur envoie uniquement des mises à jour au client. Il utilise des requêtes HTTP standards et repose sur un modèle de connexion unidirectionnel.
2. Protocole HTTP :
   • EventSource fonctionne sur le protocole HTTP (et HTTPS), ce qui peut simplifier les configurations de réseau, de pare-feu, de proxy, et d'équilibrage de charge. Les WebSockets, en revanche, nécessitent souvent une configuration supplémentaire pour fonctionner correctement à travers certains pare-feu et proxys.
3. Reconnect automatique :
   • EventSource gère automatiquement la reconnexion en cas de déconnexion, avec le code client qui essaie de se reconnecter progressivement sans besoin de gestionnaire de reconnexion personnalisé.
4. Flux de données textuelles :
   • EventSource est conçu spécifiquement pour envoyer des flux continus de mises à jour textuelles. Si votre besoin se limite à envoyer des messages de type texte du serveur vers le client, EventSource est souvent plus adapté.
5. Compatibilité avec HTTP/2 :
   • Les Server-Sent Events peuvent bénéficier des avantages de HTTP/2, comme le multiplexage des connexions et la compression des en-têtes, ce qui peut améliorer les performances.
6. Moins de surcharge côté serveur :
   • EventSource peut être moins exigeant en termes de ressources serveur pour des applications où seules des mises à jour du serveur vers le client sont nécessaires, contrairement aux WebSockets qui maintiennent une connexion bidirectionnelle ouverte.

Une navigation ultra rapide grâce à NextJS

Next.js est un framework qui offre une navigation ultra rapide grâce à son rendu côté serveur (SSR) et à la génération de sites statiques (SSG). En pré-rendant les pages et en utilisant la récupération de données au moment de la construction, Next.js réduit considérablement les temps de chargement. Associé au préchargement automatique des pages lors de la navigation et à une optimisation des performances, Next.js garantit une expérience utilisateur fluide et réactive.

‍

Gérer différent niveaux d'accès

Un autre défis rencontrer fut la gestion de 3 niveaux d'accès : Vendeur, Acheteur, Invité. Plusieurs parties du sites n'étaient donc accessibles qu'à certains utilisateurs. Cela pouvaient être des pages mais aussi des éléments des pages. 

Pour faire ça de manière propre et centralisée, j'ai utilisé à fond le potentiel du middleware de NextJS pour rediriger correctement l'utilisateur, notament l'ors de la phase d'oboarding. 

‍

‍

‍