CAW1 2018 Projet de Cyril DUSSERT et Théo JEANJEAN

De Ensiwiki
Aller à : navigation, rechercher
Project schedule.png
Titre du projet Bonjour Pâquerette
Cadre Ensimag
Page principale CAW1 Demonstration Realisation

Encadrants Sébastien Viardot


Bonjour pâquerettes est un site de partage des plus belles photos de fleurs entre passionnés. Chaque post comporte un titre, une photo ainsi qu'une description. Les utilisateurs, une fois connectés ont la possibilité de créer un post. Les posts soumis seront accessibles à tous, et des votes pourront être donnés sur ces photos.

Objectifs

[X] Gestion des utilisateurs et des comptes (création de compte, connexion, déconnexion)

[X] Voir les dernières photos

[X] Trier les photos

[X] Liker une photo

[X] Partager une photo

Cas d'usage

Administrateur :

  • Supprimer un post
    80 %
  • Modifier un post
    90 %

Utilisateur :

  • Envoyer une photo
    100 %
  • Modifier une photo précédemment envoyée
    80 %
  • Liker une photo
    100 %
  • Se déconnecter
    100 %

Visiteur :

  • Voir la page d'accueil
    100 %
  • Créer un compte
    100 %
  • Se connecter
    100 %

Diagramme des UseCases

Les cas d'usage par rôle se résument avec le schéma suivant : Usecase paquerettes.png

Schéma d'interface

InterfacePaquerette.jpeg


Modèle de données

Paquerette datamodel.png

Choix techniques

Le Backend est propulsé par la technologie Node.js avec le framework Express, très efficace pour mettre en place rapidement et simplement des API. La disucssion avec la base de données s'effectue à l'aide de l'ORM Bookshelf [1].

Les mots de passe stockés en base de données sont cryptés à l'aide de bcrypt. Les sessions sont quant à elles gérées par un système de token unique par utilisateur, échangé entre le backend et le frontend.

Les tests côté backend sont réalisés à l'aide de Mocha et de Chai, avec l'extension chai-http pour effectuer des requêtes sur l'API.

Nous voulions travailler avec un SGBD relationnel, c'est pourquoi la base de données liée au backend est du type MySQL (version 5.X ou MariaDB).

Le frontend a été construit avec le framework Angular, pour découvrir la technologie et se familiariser avec. Étant aujourd'hui un incontournable dans le monde du développement web, nous avions à coeur de nous plonger dedans et réaliser un projet concret avec.

Fonctionnalités

Webservice

Appel à un générateur de texte aléatoire (Bacon Ipsum) : https://baconipsum.com/json-api/ Le service est appelé côté Backend dans le fichier ./controllers/postController.js, lors de la création d'un Post. Une description va être générée aléatoirement en utilisant l'API uniquement si l'utilisateur, lors de la création n'en a pas explicitement spécifié une.

Rôles

- Utilisateur

- Admin

- (optionnel) Visiteur

Spécificités techniques

Architecture

L'application est construite en suivant une architecture en micro-services. C'est à dire que chaque composant (backend, frontend et base de données) sont indépendants. Si l'un d'entre eux tombe en panne, les autres continueront de fonctionner (avec néanmoins un service dégradé).

Backend

Le backend suit plus où moins une architecture MVC, les vues étant les routes.

Répartition des fichiers :

.
├── bin
├── config                 => Configuration des composants de l'application
├── controllers            => Contrôleurs
├── db_scripts             => Le script de création de base de donnés et de population de la base
├── middleware             => Middlewares utilisés (ex: Authentification, gestion des rôles..)
├── models                 => Models
├── node_modules
├── public                 => Fichiers générés pour l'accueil
├── routes                 => Définition des routes
└── tests

Frontend

Le frontend suit, quant à lui plus une architecture MVVM. Chaque composant possède 4 fichiers: le style(css), la vue(html), le contrôleur(typescript) et les tests unitaires (spec.ts). Nous n'avons pas implémenté les tests unitaires qui côté front sont très longs à mettre en place et peu utiles. Seule la génération auto est présente. Chaque composant a un style. Ce style est apppliqué que pour ce composant et n'impacte pas toute l'application. Sauf le style.css à la racine de src/.

.
├── Dockerfile                             => Non entièrement fonctionnel
├── e2e/                                   => Fichiers relatifs aux tests e2e
├── package.json                           => différentes dépendances npm
├── protractor.conf.js                     => configuration des tests e2e (faits avec protractor)
├── README.md                              => infos pour le dev
├── src/
│   ├── app/
│   │   ├── app.component.css              => Style du composant App
│   │   ├── app.component.html             => Vue du composant App
│   │   ├── app.component.spec.ts          => tests unitaires du composant App (non utilisés)
│   │   ├── app.component.ts               => Contrôleur du composant App
│   │   ├── app.module.ts                  => Tous les imports de l'appliation
│   │   ├── app-routing-module.ts          => Les différentes routes de l'application =>
│   │   ├── components/                    => Différents composants
│   │   ├── guards/                        => Les "gardiens" qui autorisent ou non une route
│   │   ├── mock/                          => données bouchon pour pouvoir développer sans le backend
│   │   ├── models/                        => différents modèles de données renvoyées par le front
│   │   └── services/                      => Services d'authentification, de récupération des posts...
│   ├── environments/                      => environnements pour le dev
│   ├── index.html                         => fichier principal html
│   ├── styles.css                         => Style global
└── tslint.json

API

Documentation Swagger : http://paquerette-back-paquerette.193b.starter-ca-central-1.openshiftapps.com/api-docs/ (L'application étant en pause si elle n'est pas utilisée, ne pas hésiter à être patient et à réessayer en cas de Timeout).

Sinon, une fois l'application lancée en local, vous pouvez accéder à la documentation à l'adresse /api-docs

Gestion des rôles

Les rôles sont gérés uniquement au niveau du backend. Lors d'une action utilisateur, le frontend va envoyer le token de session au backend. Le backend va ainsi vérifier si l'utilisateur à le droit d'accéder à la route demandée. Si oui, la requête est exécutée. Sinon, une erreur est retournée. La gestion des permissions est assurée par un middleware défini route par route sur le backend. Ce système comporte actuellement deux rôles (ROLE_USER et ROLE_ADMIN), mais peut très facilement en accueillir de nouveaux. Le tout est de bien assigner les rôles aux utilisateurs qui, par défaut n'ont aucun rôle.

De plus, nous avons une seconde vérification afin de déterminer si l'utilisateur est connecté ou non. Cette vérification vient en plus de la vérification des rôles, elle est assurée par un autre middleware jwt-authenticate, et en grande partie gérée par la librairie Passport.js. Les tokens de session respectent le standard JWT, l'utilisateur étant stocké dans la partie Payload du token (sans le mot de passe).

Jeux de tests

Backend

Un jeu de tests non exhaustif a été mis en place côté backend. Il s'agit avant tout de tests fonctionnels, c'est à dire que les tests vont se comporter comme un frontend qui effectuerait des appels sur les routes du backend. Cela permet de vérifier la consistance des retours avec ce qui est présent dans la spécification de l'API.

Les tests fonctionnels sont la pour vérifier que le code répond bien aux spécifications du produit.

Ces tests testent notre application comme une “boîte noire”. Techniquement ils pourraient être développés dans un autre langage que le code à tester.

Les tests ont aussi été configurés pour calculer la couverture de code effective. Cela permet de se rendre compte des lignes qui ont été parcourues lors des tests, ou non, et donc de savoir ce qu'il reste éventuellement à tester. Cependant, il faut être conscient qu'avoir une couverture de code à 100% n'est pas forcément gage de qualité des tests, mais signifie seulement que les tests exécutent au moins une grosse partie du code, sans forcément traiter tous les cas possibles.

Pour démarrer les tests, assurez-vous d'avoir bien démarré la base de données, placez-vous à la racine du dossier backend et exécutez la commande npm test.

Frontend

D'un point de vue frontend, le jeu de tests en place exécute des tests d'interface en utilisant Selenium. C'est à dire qu'un navigateur, contrôlé par script va exécuter des actions et vérifier des assertions. Pour exécuter ces tests, il faut vous placer à la racine du dossier contenant le code du frontend et exécuter la commande ng e2e.

Démonstration

La démonstration vidéo de l'utilisation de l'application est disponible ici : https://youtu.be/B1BWtNSUZHU