Home
Our project idea is to build a react based web version of a popular cards game. The rules of the game are listed below:
- There are two players. For our basic version of the game, we will have one user player and a computer player as the opponent, while only the player selects features to compete on.
- Each game consists of a fixed number of 10 rounds, thus there are 20 movie cards in one game deck.
- In every round, both players get assigned a card randomly from the deck.
- Card decks are randomized samples of cards generated from The Movies Dataset (Kaggle). For every game, we sample 20 cards from the dataset for a given year range and genre.
- Every card includes the movie poster, a small description of movie and some features of the movie, e.g., revenue, budget, year of release, number of languages, ratings
- In each round, the user selects a feature on their card on which to compete on, while the features on the computer's card are hidden. Up until the user has selected a feature, the computer's card only reveals the movie title and poster.
- If the feature selected by user has a better value than his/her opponent, the user wins the round and gains a point.
- The player with the highest amount of points at the end of 10 rounds wins the game.
- Python Flask for building the REST API (very efficient to expose REST APIs using an extremely lean syntax in Python).
- ReactJS for designing the game UI (well-established stateful JS framework)
- MongoDB as the database (document store, optimal for saving & querying semi-structured data)
- GitHub Actions as the continuous integration tool (extremely-well integrated into GitHub, is relatively new and we wanted to try it out)
- CodeCoverage, Coveralls as the code quality tools, we use coveralls because it is the most popular coverage application which provides easy integration for github projects and CI. It is also free to use on public repositories.
- Dockerfiles to specify Docker images for each of the three architecture parts (can be configured efficiently, when basing images on popular, existing ones)
- Docker compose to connect all three parts on DockerHub (easy-to use when it comes to let Docker-ized microservices interoperate with eachother)
The frontend would need to query the API to get information about cards, so the API calls that we would need are
- get_card_information (params)
- get_randomized_deck (params)
-
Count movies based on filtering condition
-
Path and method
/yearFrom/yearTo/genre/moviesCountmethods=['GET'] -
Returned value
Integer -
Additional Info
- Year Range bound: (1915, 2016)
- All genres:
['Documentary', 'History', 'Mystery', 'Family', 'Fantasy', 'Horror', 'Animation', 'War', 'Adventure', 'Music', 'Comedy', 'Western', 'Action', 'Drama', 'Science Fiction', 'Crime', 'Romance', 'Foreign', 'Thriller']
-
-
Fetch movie card information
-
Path and method
/game/yearFrom/yearTo/genremethods=['GET'] -
Keys of the returned document
['rating', 'imdb_id', 'poster_path', 'revenue', 'popularity', 'budget', 'title', 'runtime'] -
number of returned objects
20 (10 cards for each player) for one game
-
- Actor and Director card and deck
- Randomized deck, that contains a mix of actor, director and movie cards
- Hint option i.e letting human player know some characteristic of computer card so they can make a better move.
The documentation of our weekly sprint meeting discussions can be found on wiki page Sprint-Documentation. Here we also discuss some challenges faced in each sprint and what solution we used to overcome the challenges.
- All three repositories feature a Dockerfile, which gets triggered upon merging pull requests into the develop or master branch and can be used to build Docker images on which the microservices will eventually base on.
- Using GitHub Actions in the respective repositories, the images for the server as well as for the database part are built upon commits being pushed to the develop branch and uploaded to DockerHub.
- With a docker-compose.yml file in the client's repository, we let the three microservices parts interact with each other, by retrieving the images for the server and the database part from DockerHub.
- To scale the application, it would be possible to do so by scaling all three microservices (client, server, database) using e.g. a Docker Swarm, in which the number of running containers per service can be dynamically scaled and thus, the workload be balanced. Scaling is possible for all of the three microservices, as the application is state-less, meaning that since the application neither writes onto the server nor onto the database, we could scale the number of autonomously running containers without running into consistency issues.
During the project, we loosely followed a Kanban strategy. More specifically, we organized work in weekly sprints and planned and tracked progress using Kanban boards. Lists of up-to-date-kept Kanban boards can be found on the respective repositories under tab Projects.
The below image show the projects for server repository. As can be seen we divided our work into three projects namely, CI, API, & testing.
We used the following kanban board for our work which incorporate the review phase.
We followed the Gitflow strategy:
- For individual features/tasks, we worked on a new branch and then created pull requests into the develop branch as soon as done.
- Pull requests are reviewed by at least one of the peer group members and then merged directly on GitHub.
- Versioning/Tagging: Given the fact that we only have to the deliver the application once, we only tagged version numbers at the final stage of the project. The final version tagging on the develop then provides the occasion to merge branch develop into master and freeze development.
- Client: We decided against testing the ReactJS-based Client code, since the industry tends to advise not to spend resources on testing well-established, thoroughly tested JavaScript frameworks. However, ReactJS provides a live linting-tool out of the box, which was used regularly during frontend development.
- Server: We use pytest for testing the code which is written in python. Pytest is a popular library for testing and provide good functionality of mocking as well. It can generate coverage file that can be used by coveralls. Our test code coverage for Server is 82%.
- Database: We don't develop a test suite for the database because it is simply an unmodified mongodb instance that holds the movies data. Although smaller tests for checking proper insertion of data from CSV have been done.
This wiki page is the main documentation of the project. Further documentation can be found in the following places:
- Top-level-README: Project overview, Quickstart, etc.
- Repository-READMEs: Mostly Docker instructions for building and running Docker containers containing the respective code, locally.
- Sourcecode: We decided against an automated documentation tool, as since this application is not intended to be used e.g. as a white-box framework, there is no use in providing documentation for every single method resp., function part of the code. Furthermore, we avoided commenting functionality, which reveals itself obvious, when studying the code. Hence, we provided in-code comments only when actually useful, e.g. to explain to the reader from where data is fetched, for putting TODOs, or explaining complex constructs, etc.
