# Deck Builder (code-named 'laurelin')
See `dev` branch for latest changes.
---
A multiplayer deck building game.


## **Current major issues**
### **Session cookie refreshing**
Currently, the cookie is refreshed on every single action which requires\
session auth.\
Okay, that seems pretty normal.\
So, we just save the new one to the `global.user_to_session_map` hashmap,\
and just send an event to the client with the new one, so they can update\
it in the clients presistent storage, right? This can happen automatically\
in the background.

### **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](https://www.conventionalcommits.org/en/v1.0.0/).

Things to remember:
* everything lowercase
* allowed scopes are `schema`, `shared`, `client`, `server` and `api`