README.md

MyWatchlist

Semester project for Web Engineering lecture at DHBW in 2022.

Short description

The idea behind the MyWatchlist web application is to offer users a simple and centralized way to keep track of movies and series they have already watched or saved for later. In addition, the website offers a provider-independent search function and the feature to manage multiple lists separately. The watchlists can be shared with friends via their own profile, even if they do not have their own account at MyWatchlist. Apart from the search and the suggestions on the movie detail pages, further recommendations can be discovered on the start page. These films and series, which change daily, follow the current popularity ratings or trends and can also be added to a watchlist directly from the slider with just a few clicks.

In the implementation, a special focus is on a clear and modern UI design, which allows the user to intuitively condition the website. A special concern are also the aspects of security and data minimization.

Technology overview and architecture

Frontend: ReactJS, TypeScript, TailwindCSS
Backend/Server: Spring Boot, Java, PostgreSQL, Caddy, Docker

Figure 1: Architecture of MyWatchlist

Figure 1 shows the architecture of the web application and the backend. The client calls the application via the URL https://mywatchlist.server-welt.com and gets it delivered by Caddy. The web application also makes requests to the backend and the API. To ensure that the connection to the backend is also secure through HTTPS, another URL is used for this purpose. This URL is also received by Caddy. However, Caddy only acts as a reverse proxy and forwards the request to the backend. This then processes the request and sends back a response. For security reasons, only the backend has access to the database. Thus, there is only a connection locally on the server. Caddy, the backend and the PostgreSQL database all run in a Docker container on the Ubuntu server.

Components and implementation

Frontend

The frontend is divided into different subpages, at least virtually, which means that only one page is delivered from the web server, but a specific page can be called up under a defined path. This routing or subpages, was implemented with the help of the library "react-router". These subpages can be called partially only if the user is logged in. If the user is not logged in, he will be redirected to the start page. This also looks different if the user is logged in or not.
This functionality is also implemented in the user's profile. Depending on how the user has set it, the profile is publicly viewable or not. By default, the profile is set to private. If the profile is public, the lists of the account will be publicly visible and can be shared with others.
Several methods have been implemented for handling the JSON web tokens that the frontend gets back from the backend on login. The token and the corresponding username are initially stored in local storage, so they are always retained if the page is reloaded or similar. Unlike cookies, however, they are not retained after the browser is closed and the user must log in again accordingly. If the token has expired, it will not be accepted and the user will have to log in again.
The profile picture is generated automatically with the help of the library "DiceBear". You only have to specify a seed, which in our case is the username, which is always unique. The images are all licensed under Creative Commons 1.0 (CC0 1.0 Public Domain) and therefore freely available.
For icons we used the library "Heroicons", because they are available for free. For alerts or notifications we used two libraries. For the alerts or modals, for example to add a movie or series to a list, we used the library "sweetalert2". For the so-called toast, for example to display a small notification at the bottom, the library "react-hot-toast" was used.
For all requests, whether to the backend or to the TMBD API, the JavaScript internal fetch API is used, with which HTTP requests can be made.

Backend

The architecture was divided into three parts, as shown in the figure. The top layer is the frontend and sends HTTP requests to the backend. The backend is the second layer and is responsible for the logic, accepting HTTP requests and database access. This ensures that data storage is separated from the frontend and database access can be managed centrally. The architecture of the backend is also divided into three layers. This logically separates the areas of responsibility and thus makes the software more maintainable. The first layer of the backend called "API Layer" takes care of the HTTP requests. It forwards the incoming requests to the next layer and sends the response back to the frontend. The next layer "Service Layer" is responsible for validating the requests and prepares the response. The last layer "Database Access Layer" takes care of the database access and e.g. makes changes in the database or searches for certain entries. The lowest layer is the database and is responsible for data management.

Database

Figure 2: Database modelling

• user-account: Will hold all user data
• watchlist: All watchlists of a user are stored here
• watchlist_entry: All title entries are stored here and assigned to a specific watchlist
• title_type: Each watchlist entry has a type (show or movie).
• tv_info: If a title is a show, all episodes and to which season it belongs are stored here

Screenshots

Figure 3: Welcome page

Figure 4: Start page

Figure 5: Movie detail page

Figure 6: Search page

Figure 7: Edit/manage lists

Figure 8: Public user profile

Figure 9: Settings page

Legal notice

This product uses the TMDB API but is not endorsed or certified by TMDB.