#Deck Builder (code-named 'laurelin')

#See dev branch for latest changes.

A multiplayer deck building game.

#Shortest possible explanation of the structure

Client <-> Server <-> API <-> Persistent database (PSQL)
                      API <-> Session store (Redis)

The client only communicates with the server.
The server is authorative, and has the final say in ALL things.
The server communicates with a web API that handles all database
functionality.
The API is not exposed publicly (thus, it will not require authentication
or authorization for most endpoints), and all request go through the server.

#Client

The client creates a connection to the server on startup.

#Server

When a client connects to the server, it can't do much at the start,
because the user has to send account credentials to authenticate.
These are then sent to the API, which will create a session and return
a cookie. The cookie should then be passed to the client.

Should the cookies for both users in a game be stored on the server as well? In-memory, but just so the user doesn't have to send it with every request, to save on the traffic.

#API

The web API has access to a PSQL server and a Redis server.

#PSQL and Redis

PostgreSQL is used for storing/persisting data.

Redis is used for storing user sessions.

#Commit conventions

Commits after 09.01.2023 MUST follow Conventional Commits 1.0.0.

Things to remember:

• everything lowercase
• allowed scopes are shared, client, server and api