O'PLAYGROUND
Introduction
Objectifs
- Permettre à l’utilisateur de trouver un terrain via un formulaire de recherche basé sur la zone géographique recherchée (commune)
- Permettre à l’utilisateur d’accéder à toutes les informations du terrain choisis
- Permettre à l’utilisateur de créer un évènement sur ce terrain
- Permettre à l’utilisateur d’avoir accès aux informations d’événement sur un terrain
- Permettre à l’utilisateur de rejoindre l’auteur d’un événement
Contexte
Cette application est née d’une réflexion entre amis, qui voulaient faire un “after-work” sous la forme d’un basketball pour se détendre après une longue journée de travail. Evidemment la pratique d’un
tel sport nécessite un terrain pour le pratiquer, ainsi que savoir quelles sont les conditions d’accès.
Ces amis ont cherché un terrain sur internet et sur des applications en ligne mais sans succès.
Outre la réflexion de ces amis, ne peut-on jamais vouloir pratiquer un sport tout en rencontrant de nouvelles personnes ayant la même envie que nous ? est-ce qu’un foot, un rugby ou même une petite
session de pétanque entre passionnés ou simples amateurs est impossible ?
Cette application tend à répondre à l’objectif suivant : recherche de terrain de sport de tout type avec les conditions d’accès et proposition de rencontre entre utilisateurs de l’application.
Processus de développement
Méthodologie de développement
Gestion de projet faite en cohérence avec l’application de la méthode Agile SCRUM. Le concept de méthode AGILE est un concept philosophique mettant toujours le client au centre des intérêts du projet et au coeur de la conduite de celui-ci. La méthode SCRUM basée sur cette dernière est un cadre de développement proposant une structure de gestion de projet. Nous pourrons notamment retrouver des cycles de travail nommés Sprint.
Conception et architecture
Architecture système
Côté backend, nous avons créé une architecture MVC avec le Framework Express.
Fonctionnalités de l'API
- Routes d’accès et actions à la bdd
- Gestion d’erreur
- Authentification renforcée avec l’utilisation de la technologie JWT
- Gestion de la migration de la base de donnée avec l’utilisation d’un gestionnaire nommé Sqitch
- Documentation Swagger et JsDoc
- Validation des données à l’appel de l’API
Conception de la base de données
Cette application a besoin de plusieurs entités pour se structurer. Nous avons pensé au terrain (équipement sportif), à l’événement que créera ou pas un utilisateur, l’utilisateur en lui-même avec ses infos et savoir s’il participe ou non à l’événement.
- Un terrain peut avoir 0 événements ou plusieurs (N)
- Un événement doit être lié à 1 et 1 seul terrain
- Un événement doit avoir au moins 1 participant mais il peut en avoir plusieurs (N)
- Un événement doit être lié à 1 et 1 seul auteur (membre qui crée l’événement)
- Un membre peut ne participer à aucun (0) événement comme il peut participer à plusieurs
- Un membre peut ne pas avoir créer d’événement comme il peut en avoir créé plusieurs
Implémentation
Outils et technologies utilisés
Côté back-end nous sommes sur le Framework server-side Express basé sur NodeJS, permettant de créer une API très rapidement avec les services http et routing qu’il propose. Nous avons organisé celui-ci en respectant le design pattern MVC (Model View Controller).
Pour la connexion à la base de données, nous avons utilisé le module de node-postgres : PG. Celui-ci nous permettant de nous connecter à une bdd sous postgreSQL.
Pour gérer nos changements dans la bdd, nous avons utilisé un service qui s’appelle Sqitch, nous permettant de définir une version à chaque changement et donc de pouvoir rapidement revenir d’une version à une autre en cas de problème, ou bien de pouvoir déployer une modification sans que cela n’impacte trop fortement la base de données.
En termes de sécurité propre à l’application nous avons utilisé Dotenv pour pouvoir créer des variables d’environnement et les utiliser, CORS, pour pouvoir limiter les clients qui ont le droit d’appeler notre API. Concernant la sécurité propre aux données cette fois-ci, nous avons utilisé Bcrypt pour hacher et comparer les mots de passes, JOI pour pouvoir valider les données envoyées à l’API et enfin JWT pour pouvoir gérer l’identification de l’utilisation en créant un lien de confiance entre le client et l’API.
Notre API s’appuie sur une autre API sur laquelle il y a plus d’information mais nous avions besoin d’avoir une réponse claire et exempte de toute information superflue. Pour faire appel à cette API au début nous avions pris Node-Fetch car fetch ou Axios ne sont pas natif à NodeJS. Cependant, après recherche il s’avère que Fetch est présent en natif dans nodeJS depuis la version 18, donc assez récente.
Nous avons dû également faire une documentation détaillée pour la partie cliente sur l’utilisation de notre API. Nous avons utilisé Swagger et JsDoc pour cela.
Côté Front, nous sommes sur du ReactJS, avec Tailwind et une extension : DaisyUI
Pour la gestion du projet nous avons utilisé Google Drive : documentation collaborative en ligne nous permettant de travailler sur le même cahier des charges, Trello : outil de gestion de projet collaboratif qui nous a servi à organiser notre travaille sous forme de tâches, Figma : outil de maquettage qui nous à permis de créer les wireframes de l’application.
Et pour finir, cette application est déployée sur Heroku.
Conclusion
Ce projet m’a permis de me challenger en équipe sur un plan relationnel et de gestion de projet. J’ai bien aimé la discipline que l’on s’est donné pour faire les réunions le matin et les échanges que l’on a eu entre nous. Le pair-programming est aussi une bonne chose pour ne pas être seul devant notre écran et devant nos propres décisions et problèmes.
Prochaines étapes
Les prochaines étapes de ce projet est d’aspect technique : il faudra revoir l’étude de marché et les réelles attentes des potentiels utilisateurs sur ce type d’application. Faire également un portage sur mobile.
