Dans le cadre des cours Architecture Web et Application Web, nous avons du créer un site web permettant à des joueurs de s'inscrire, puis de participer à des parties de jeu contre deux autres joueurs.
Le projet se sépare donc en trois parties distinctes :
...
...
@@ -13,6 +14,26 @@ Le projet se sépare donc en trois parties distinctes :
Cette documentation va se porter sur ces parties du projet, en détaillant les aspects techniques ainsi que des requis pour pouvoir les lancer.
#### Méthodologie
Dans ce projet, nous avons décidé de rester ensemble pour programmer. En effet, l'idée d'être à deux sur l'ensemble du projet présente des avantages qui nous semblaient importants :
-**Compréhension**
Nous avions les deux en tout temps une complète compréhension du projet. Cela nous est arrivé à plusieurs reprises de se rendre compte pendant le développement du Frontend que notre Backend présentait des problèmes et nous avons pu régler rapidement les erreurs.
-**Créativité**
Un mélange d'idées pour une qualité accrue. Nous avons pu, en discutant entre nous, pu faire ressortir diverses idées et garder celles qui nous semblent les meilleurs.
#### Problèmes rencontrés
Cependant notre méthodologie n'était pas vide de problématiques :
-**Temps de développement accru**
En effet, à être à deux sur les mêmes parties et à s'organiser pour être ensemble, nous avons sûrement perdu du temps. On estime qu'environ une à deux semaines supplémentaires nous étaient nécessaires.
-**Manque de préparation**
Comme indiqué dans le chapitre sur l'API REST, nous avions commencé notre système de données d'une mauvaise manière. A revenir en arrière, nous avons fait les choses à la va-vite, et nous avons subi de nombreux problèmes de nommages incohérents entre la base de données, le backend et le frontend.
---
### API REST
...
...
@@ -36,10 +57,10 @@ Dans le code, nous avons une classe qui gère toute la DB. Pour ce faire, nous a
Dans le backend, on a décidé d'utiliser le wrapper `promised-sqlite3`. Il fonctionne autour du module `sqlite3` et permet l'usage des promesses pour sqlite3. Cela nous permet de gérer facilement les retours de la base de données, sans avoir à se soucier de la synchrone.
Pour gérer les appels à la base de données, nous avons créé une API possédant divers routes que voici:
Pour gérer les appels à la base de données, nous avons créé une API possédant diverses routes que voici:
`User - /API/v1/user`<br>
Cette route gère le CRUD des utilisateurs avec respectivement les méthodes post, get, patch et delete (pour les deux dernières, on rajoute l'ID à la route comme ça /API/v1/user/:id)
Cette route gère le CRUD des utilisateurs avec respectivement les méthodes post, get, patch et delete (pour les deux dernières, on rajoute l'ID à la route ainsi `/API/v1/user/:id`)
Lorsqu'on s'y connecte, l'API vérifie si l'utilisateur est admin et, dans le post et le patch, elle vérifie également les identifiant.
`Question - /API/v1/question`<br>
...
...
@@ -52,7 +73,13 @@ Concernant le CRUD des réponses, la particularité se trouve dans le get. En ef
Les catégories ne possèdent pas d'update car nous n'avons pas considéré cette possibilité comme pertinente. Le reste se passe de façon similaire aux utilisateurs.
`Login - /API/v1/login`<br>
La connexion des utilisateurs ne possède qu'une méthode post de par sa nature. En effet, elle ne peut guère faire plus (car tout ce qui concerne les utilisateurs est dans la route user).
La connexion des utilisateurs ne possède qu'une méthode post de par sa nature. En effet, elle ne peut guère faire plus (car tout ce qui concerne les utilisateurs est dans la route user). Cette route prend dans le body un json type User avec le username et le mot de passe et renvoie le token JWT.
### Problèmes rencontrés
Au début du projet, nous avions décidé de gérer les données sous forme de liste in-memory. Cette méthode nous a causé bien des problèmes et nous avons donc décidé d'utiliser SQLite, ce qui nous a largement simplifié la tâche.
Nous n'avons malheureusement que peu géré les erreures de la base de données. Là où elles ne sont pas nécéssairement utile au projet, on en perd en propreté de code et on risque plus les comportements indéterminés.
Il y a un bug dans notre site que nous n'avons pas réussi à régler, même avec de l'aide. À la fin d'une partie, le tableau des scores s'affiche correctement et est détruit si l'on quitte la page. Cependant, si l'admin revient, l'affichage affichera toujours le dit tableau.
