#Deck Builder (code-named 'laurelin')

#See dev branch for latest changes.

A multiplayer deck building game.

#Current major issues

#Quite a few unwraps in use

All should be handled, with sane error responses.

#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 once the user gives their account
credentials, either for an existing account, or a new account.

This connection may be rejected if the credentials are not valid.

#Server

When a client connects to the server, it sends the account credentials to
authenticate (or an existing cookie on the client side).
These are then sent to the API, which will create a session
(or verify the previous one) 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 schema, shared, client, server and api