# Rapport Projet 4A
ARMUTLU Ethan - DI LIVIO Bruno - NOUSSE Gaëtan
## Sommaire :
1. [Introduction](#introduction)
2. [Notre cas d'application](#notre-cas-application)
3. [L'architecture et la réalisation](#architecture-et-realisation)
4. [Les technologies utilisées](#les-technologies-utilisees)
5. [La planification et le déroulement du projet](#la-planification)
6. [Présentation du résultat](#presentation-resultat)
7. [Les problèmes rencontrés](#problemes-rencontres)
8. [Les évolutions possibles](#evolutions-possibles)
9. [Conclusion](#conclusion)
## Introduction <a id="introduction"></a>
    Dans le cadre de notre 4ème année d'école d'ingénieur à Polytech Nancy en IA2R option SIR, il nous a été permis de réaliser un projet interne. L'objectif de ce dernier est de développer une application web composée de deux parties : une partie *back-end* et une partie *front-end*. Une contrainte étant que la mise en place du *back-end* devait être la même que celle vue en cours, c'est à dire une *API REST*.
  Pour réaliser ce projet, nous avons décidé de créer une application web, permettant la gestion de visionnage de séries et de films et l'interaction entre utilisateurs de ces derniers, que l'on a nommé **TV ADN**.
> Logo de l'application<br>
  Elle s'inspire d'une application déjà existante : *TV Show Time*. En effet, une application comme TV ADN est très vaste et permet de réaliser nos objectifs en respectant la contrainte. De plus, elle possède un grand nombre de perspectives d'évolutions possibles.
  Ce rapport vous présentera notre cas d'application ainsi que l'architecture et la réalisation de cette dernière. Ensuite, il s'agira de montrer les technologies utilisées et la planification du projet. Enfin, seront exposés les problèmes rencontrés ainsi que les perspectives d'évolutions de TV ADN.
## Notre cas d'application <a id="notre-cas-application"></a>
    Nous souhaitions réaliser une application qui nous plaise, c'est-à-dire une interface attrayante et pratique ainsi que des fonctionnalités plus poussées que les simples lecture et écriture. Pour cela, nous avons utilisé *TV Show Time* comme point de départ. En effet, cette application est très complète et possède de nombreuses fonctionnalités avec des difficultés d'implémentation différentes.
  Afin que notre application soit totalement utilisable dans une première version, nous avons choisi d'implémenter les fonctionnalités suivantes.
* Gestion des films et de leurs genres
* Gestion des séries et des épisodes associés et de leurs genres
* Gestion des comptes utilisateurs
* Gestion des acteurs et des personnages qu'ils incarnent
* Ecriture de commentaires sur tous les médias
* Marquer un média comme vu
* Marquer un film ou une série comme favoris
* Ajouter un film ou une série à la liste "plus tard"
* Rechercher un média par son nom
* Donner une note à un média
* Ajouter des réactions à un média
* Calculer des statistiques par utilisateur sur son activité
  Cette liste nous a donné une bonne base pour réflechir et imaginer notre interface. Nous avons utilisé le logiciel *Figma* pour réaliser la maquette numérique qui nous a, par la suite, grandement aidé durant le développement.
>Page *Accueil*
>Page *Inscription/Connexion*
>Page *Profil*
>Page *Détails*
>Page *Ma liste*
  L'un des avantages de travailler avec des films et des séries est sans doute la disponibilité de ressources sur internet. En effet, nous savions que nous pourrions remplir notre base de données afin d'avoir une application fonctionnelle. Il n'était donc pas nécessaire de passer plusieures heures à récuperer des médias pour les ajouter à notre application.
## L'architecture et la réalisation <a id="architecture-et-realisation"></a>
    Notre projet est la combinaison d'une *API REST* et d'une application *front-end* qui consomme l'API. Evidemment, l'application *front-end* effectue ses requêtes par le biais du protocole *HTTP* et l'*API REST* donne ses réponses au format *JSON*.
L'accès à la base de données relationnelle se fait exclusivement par l'API.
  Il a été important, pour commencer, de bien définir la structure de notre base de données. Nous avons décider de créer une classe *Media* dont héritent les classes *Movie*, *Serie* et *Episode*. En effet, pour réaliser les fonctionnalités que nous avions prévues, certaines relations entre classes devaient se placer directement sur l'objet concerné ou sur l'ensemble des médias. Par exemple, tous les médias possèdent des commentaires, il y a donc une relation *one-to-many* entre les classes *Media* et *Comment*. En revanche, on ne peut pas marquer un épisode comme "à voir plus tard", mais seulement une série ou un film, il a fallu donc créer une relation entre *Movie* et *User* ainsi qu'entre *Serie* et *User*.
  Nous avons également selectionné une ressource pour obtenir des médias et remplir notre base de données. Nous avons choisi l'API *IMDb*, qui contient des millions de titres et dont l'API est plutôt intuitive.
## Les technologies utilisées <a id="les-technologies-utilisees"></a>
Pour réaliser l'*API REST*, nous avons utilisé *Spring Boot* avec les dépendances suivantes :
* JPA
* Spring Boot Web
* Spring Boot Security
* MySQL Connector
  Concernant la partie *front-end*, nous avons décidé d'utiliser *ReactJS*. Bruno l'avait déjà utilisé et Gaëtan connaissait *ReactNative* qui est très semblable. Enfin, Ethan était également intéressé par ce framework. De plus, nous n'avons pas utilisé de framework CSS, car le design de l'application était déjà défini, cela nous a aussi permis de développer des compétences concernant les grilles CSS et Flexbox qui sont simplifiés par les frameworks CSS.
  Nous avons utilisé *MySQL* en tant que SGBD car il est plus flexible qu'une base de données utilisant *H2*, bien que plus compliqué à mettre en place notamment au déploiement.
  Afin de récupérer des films, séries et épisodes depuis l'API *IMDb*, nous avons utilisé *Python*. Ainsi, nous pouvions rapidement remplir notre base de données.
  Enfin, nous avons réussi à déployer l'*API REST* ainsi que la base de données avec Docker.
## La planification et le déroulement du projet<a id="la-planification"></a>
    La première étape dans la réalisation de notre projet a été de réaliser une montée en compétences, pour Ethan et Gaëtan, sur le framework *ReactJS*. Bruno n'a quant à lui pas eu besoin de faire celle-ci puisqu'il avait déjà eu l'occasion d'utiliser ce framework lors de projets personnels.
En parralèle, nous avons réalisé la maquette de notre application sur Figma afin de nous mettre d'accord sur le visuel de celle-ci.
Nous avons également créé un dépôt *Git* sur *Github* afin de centraliser notre code. Ceci nous a permis de partager plus facilement le code mais également de pouvoir revenir sur certains *commits* lorsque nous rencontrions une erreur.
  Après ces étapes, nous avons pu commencer à réaliser notre application en commençant par réaliser la DAO. La base de données et ses tables ont donc été créées. Jusqu'à fin octobre, nous avons également réalisé la récupération de données provenant de l'API *IMDb*.
Concernant la récupération des médias avec cette API, elle est limitée à cent requêtes par jour et par compte. Pour contourner ce problème et obtenir une base de données bien remplies rapidement et en une seule exécution, nous avons créé une base de données tampon différente de celle utilisée par notre application. Il y a donc un premier script *Python* qui consomme l'API *IMDb* et remplit notre base de données tampon et qui peut utiliser plusieurs comptes par jour et ce sur plusieurs jours. Ensuite, un second script remplit la base de données de notre application en une seule exécution à partir de la base de données tampon.
La réalisation de la partie *front-end* de notre application a commencé début novembre avec la création de ses différentes pages. Ceci nous a permis de mettre en place directement la navigation entre les pages. De plus, nous commencions à créer les premiers *controllers* de notre application.
Durant tout le mois de décembre s'est déroulé la mise en place de l'application. En effet, c'est dans cette partie que nous avons réalisé les requêtes API vers la base de données et donc toutes les fonctionnalités comme la récupération des données de chaque médias, les possibilités d'interactions sur ces médias et de les ajouter dans vos listes, etc.
La dernière étape était de finaliser notre application en la testant et en corrigeant les bugs.
>Plannification du projet
  Durant ce projet, nous avons tous les trois travaillé sur la partie *back-end* et *front-end* de l'application mais pour éviter au maximum les conflits lors du développement de l'application, nous nous sommes chacun principalement concentrés sur une partie : Ethan sur la partie *back-end*, Gaëtan sur la partie *front-end* et Bruno lui a contribué aux deux parties.
## Présentation du résultat <a id="presentation-resultat"></a>
    Le projet étant terminé, nous pouvons vous présenter le résultat obtenu sous forme de captures d'écran de notre application web :
>Page *Accueil*
  La page principal de notre application web est présentée ci-dessus. Comme on l'avait pensé sur la maquette, elle présente les médias par genre et sous formes de listes déroulantes. Ici, elles sont en arrière-plan car l'utilisateur réalise une recherche, ce qui fait apparaître les résultats dans une nouvelle liste en premier plan.
  De plus, la barre de navigation présente en haut de la page (elle est présente sur toutes les pages de l'application sauf les pages de connexion et d'inscription), ne possède ici, à sa droite, seulement les boutons permettant de se connecter ou de s'inscrire car l'utilisateur n'est pas connecté.
  Lorsque l'utilisateur s'est connecté, la barre de navigation est différente et permet de naviguer vers les pages dédiées à l'utilisateur (vers les pages *Mon profil* et *Ma liste*). Nous pouvons le voir sur la page *Profil* ci-dessous :
>Page *Profil*
  Quand l'utilisateur consulte sa page *Profil*, il peut faire apparaître sa liste de favoris en cliquant sur le bouton situé en bas de la page, comme nous pouvons le voir sur la maquette présentée précédemment.
>Page *Détails*
  Nous nous sommes rendu compte durant le développement de l'application que nous n'avions pas pensé à un système de notation dans la maquette. Nous l'avons donc placé sous l'affiche du média à gauche de la page *Détails* ci-dessus. Pour réaliser la notation, nous avons utilisé une force de *ReactJS* en reprenant une librairie de composants.
>Page *Ma liste*
  Concernant la page *Ma liste*, nous avons pensé à ajouter une liste *Ce que vous êtes en train de regarder*. Elle comporte les séries dont certains de ses épisodes sont déjà vus.
## Les problèmes rencontrés <a id="problemes-rencontres"></a>
    Nous sommes bien parvenu à bout de ce projet. Nous avons une application web fonctionnel et opérationnel. Cependant, comme tout projet, nous avons rencontré quelques difficultés durant ce dernier.
  En effet, le premier gros problème rencontré fut l'utilisation, pour un service web, de *JPA* et du framework *Spring Boot*. Ceci fut nouveau pour chacun d'entre nous et donc l'appréhension de *JPA* et de *Spring Boot* nous a pris énormément de temps. De plus, il fallait découvrir et rechercher les fonctionnalités nécessaires afin de réaliser ce que l'on souhaitait. Ensuite, *JPA* et *Spring Boot* ne sont pas adaptés pour des requêtes très compliquées. Egalement, les relations *many-to-many* ajoutaient parfois des tables associations entre deux classes même lorsque que les tables existaient déjà. Enfin, nous étions tous habitués à utiliser un autre framework web : *Laravel*. Ainsi, nous essayions de réflechir de la même manière qu'avec *Laravel* pour *Spring Boot* sans s'en rendre compte. Ceci rendait difficile certaines réalisations.
  Ensuite, un autre problème rencontré fut la création de nos classes *Episode*, *Serie* et *Movie* qui héritaient de la classe *Media*. En effet, gérer la création de cette héridité dans la DAO n'était pas évident. Il fallait à la fois trouvé une solution viable mais aussi qui ne perturbera pas l'ajout d'autres fonctionnalités. De plus, il fallait également gérer les liaisons entre les tables dans la DAO afin de ne pas perturber le bon fonctionnement de l'application web.
## Les évolutions possibles <a id="evolutions-possibles"></a>
    Notre application possède un grand nombre d'évolutions possibles. En effet, par manque de temps, nous n'avions pas pu ajouter toutes les fonctionnalités voulues à notre application. Comme nous ne savions pas exactement ce que nous arriverions à réaliser dans le temps imparti, notre but principal a été de coder de manière évolutive afin de faciliter les ajouts et modifications.
Voici les évolutions possibles de notre application auxquelles nous avons pensé :
* Ajouter la possibilité de réagir aux médias avec des émoticônes (la DAO a déjà été réalisée)
* Pouvoir personnaliser son profil comme le souhaite l'utilisateur en modifiant son mot de passe et son identifiant (il est déjà possible de modifier son avatar/image)
* Créer un compte administrateur et des comptes modérateurs qui permettraient de filtrer les commentaires (les rôles utilisateurs sont déjà implémentés dans le *back-end* et sont fonctionnels, mais ne sont pas utilisés dans le *front-end*)
* Ajouter les suivi des utilisateurs et donc la possibilité de voir les profils des autres utilisateurs ainsi que leur médias qu'ils sont en train de regarder, ceux qu'ils ont vu ou encore les notes qu'ils ont donné.
* Créer un algorithme de suggestions de médias en fonction des préférences de l'utilisateur ce qui permettrait à ce dernier de visualiser en premier les médias qui lui correspondent sur la page d'accueil.
## Conclusion <a id="conclusion"></a>
    Ainsi, nous avons pu atteindre les objectifs fixés par ce projet. Nous avons réalisé une application web *TV ADN* avec une partie *back-end* et une partie *front-end*. Nous avons codé la partie *back-end* avec *JPA* et *Spring Boot* et avons bien utilisé une *API REST*. La contrainte fut donc bien respectée. La partie *front-end* fut réalisée à l'aide de *ReactJS*. Malgré l'ensemble des problèmes rencontrés, nous avons réussi à implémenter la quasi-totalité des fonctionnalités prévues. De plus, notre application web est fonctionnelle et opérationnelle.
  Cependant, il reste bon nombre de perspectives d'évolution possibles pour notre application. Non seulement les dernières fonctionnalités que l'on souhaitait implémenter mais aussi de nouvelles améliorations à trouver.
  Enfin, ce projet fut une réelle chance pour nous. Il a permis une montée en compétence pour l'ensemble du groupe. De plus, nous avons amélioré notre compétence à travailler en groupe et appréhendé de nouveaux langages. Enfin, ce projet est un énorme bagage pour nos futurs entretiens d'embauches.
Sign in with Wallet
Connect another wallet