gramanicu/cooking-crisis-api

The backend server for the Food Crisis game

Grama Nicolae

I am a Computer Science and Software Engineering Undergraduate, passionate about technology & programming. I am a fast learner, very ambitious, good at searching and finding solutions to different problems.

cooking-crisis-api's Issues

Research automatic code styling methods

Implement ELO system

Short description

The elo system is used to rank (and eventually, match) players.

There are a few important formulas.

// Having two players. "a" and "b"

Ea = 1 / (1 + 10 ^ ((Rb - Ra)/400)
Eb = 1 / (1 + 10 ^ ((Ra - Rb)/400)

// Where Ea, Eb is the "Expected result" and Ra, Rb is the "Rating"
// E has a value between 0 and 1 (0-100%).

new_rating = rating + k_factor * (score - E)

// The "score" can be either 1 or 0 (win or lose) and "E" is the expected result.
// K factor is the maximum amount of points that can be earned. 32 is a default value
// but it can be lowered to 16 when the elo is high enough.

The starting elo value is arbitrary. Ok values are 1000, 1200 and 1500 (probably will chose 1500).

Implementation

The elo system will be a service mostly, linked to the ranking one. The new elo's are computed on match endings, and the updated in the user data. The "ranking" will be updated when the leaderboard updates.

Implement "Public" user routes

• GET ../users/exists/<username
• GET ../users/status/<username>
• POST ../users/signin
• GET ../users/change_device
• POST ../users/new
• GET../users/activation/<activation_link>

"Modularize" the documentation

The api documentation should be separated by routes, and the main readme should only contain generic information about them (method and url).

Research https & http2.0

Research if https (or http2) is needed and how to use it in express

Implement websockets

Use "Socket.io" for bidirectional server-client communications. This will be used for notifications, matchmaking, chat and multiplayer features.

Don't show code error to the API client

The error thrown inside try/catch blocks that use the "error middleware" is shown to the user. Instead, a simple Error 500 should be shown. The actual error should be logged inside the server.

Another thing is that the stack trace is not printed, so it's quite hard to find the source of the error

Research authentication methods

Research the safest and simplest way to authenticate/login a user into it's account (and send all the "private" requests).

Implement "Private" user routes

These routes require a valid JWT to be accessed.

• GET ../users/account
• PATCH ../users/refresh_token
• PATCH ../users/signout
• PATCH ../users/password

Separate server specific code from the db code

Separate components of the server (server/index.js for the express app, database/index.js or db.js for the mongoose "client")

Implement leaderboard creation service

Specification

The leaderboard will be updated periodically. Only the first 100 players will be shown, but any player can see his ranking. To create the leaderboard: search through all the players, and order them by their elo. The IGN-ELO pairs will be added to the leaderboard, in a "sorted set".

The leaderboard can be recreated at a set interval, or when the server starts.

Markdown "json" styling

The json styling for the "code blocks" isn't looking too good. Try to replace it (maybe .js) ?

Change user schema

The user "records" should contain the elo (which was previously only stored in leaderboard).

How will ELO/leaderboard work

After each game, the new elo of the players will be computed. This is updated inside the users collection.

To create the leaderboard, a "service" will be run on the server every "x" minutes (maybe 10), and create the leaderboard, ordering the players.

Add Unit Testing

Research methods to scale the server

Add copyright to the Readme

Research Redis and Redis Caching

Research how Redis works, how to set it up, how to add it on heroku and how to use it for caching (beside using it as a key-value store)

Remove redirect to `/docs`

The routes should not redirect to docs. Even '/' (home).

Whitelist jwt access tokens

The access tokens must be invalidated when signing out. So, they must be stored in a db, and invalidated there

API specific documentation

Write the documentation for the api routes, which will be returned when accessing the /docs routes

Implement "report punishments" functionalities

These are used to hand out punishments to players:

• chat restrict - for a defined period, the player can no longer use the chat
• account lock - for a defined period, the player can't access his account
• bans - for a undetermined period, the player is suspended

The punishments can't be appealed. They are progressive, in duration, and in "importance":

• 3 chat restricts (1, 3 and 7 days)
• 3 account locks (1, 3 and 7 days)
• final ban

The banned accounts are not deleted, to not allow the user to reuse his email address. However, the username is "freed" (more research needed related to the way this will be implemented)

Document new features

Document the socket api
Document the new models
Update the user model documentation and other changed features

Research possible CI

Implement Redis Caching

Implement a redis caching middleware and use everywhere it is suitable

Implement "find a game"

Matchmaking refers to both "private" (with friends) and "public" games. Match search refers to the public games.

The players will be added in a queue. If we want to try to match players of similar skill:
(elo range - max queue times)

• 100 elo range - 15 seconds
• 200 elo range - 45 seconds
• 300 elo range - 1min 30 seconds
• unrestricted - anything over that

After the players are matched, the process is similar to the one used for the private games.

From a "api" perspective, they will send the request, and wait for the response. NOTE: in the meantime, some kind of animation + the current queue time should be displayed. When the match is found, they are immediately sent to the "game page"

Use ES6 `Promise`'s

Where possible, make functions use ES6 Promise

Implement JWT for "private" routes

As defined in issue #15, the private routes are only accessible by a logged in user. For this reason, they must be authentified, and after a bit of research (see #21), I decided that JWT are good for our use case.

They must be implemented into a middleware, that will verify every "private" request. The JWT will be created when the user logs in, and then destroyed. The token is destroyed:

• if he is older than 24 hours
• if the user connection was lost (and he hasn't reconnected for a specified amount of time) - this feature needs more research and consultation with the frontend developers
• if the users signs out

Add "lowercase_name" field to the users

To be able to have IGN's with both upper and lowercase chars, but keep them unique (no "user" and "User" at the same time), add another field, which will be used for the database searches (as the IGN is unique, no matter the account type)

Load env vars using `dotenv`

Add the dotenv library and use it to load the environment variables from a .env file.

The loading should be done in the app.js, before anything else is ran.

Use Objects inside the modules

e.g. server/index.js

Implement "friend list"

The following functionalities must be added:

• send invite to a player
• respond to a friend invite. If accepted, the 2 players are added to each other's friend list.
• get all friends
• remove a friend

A new route will be created: "friends" (private, access token required):

• PUT ../friends/add/:username
• PUT ../friends/answer/:req_id
• GET ../friends/all
• DELETE ../friends/:username

Also, messages must be sent from the server to the client (new friend request, new friend). This will need a "socket.io" implementation.

Server documentation

The "Readme.md" documentation should contain information about setup/installation, running, routes and pretty much everything :)).

Research all the routes that should be implemented

Think about all that data that could be requested by the webclient and try to prepare the API for the requests