DEVELOPMENT ENVIRONMENT

~liljamo/deck-builder

2acaf16c7ac759eeef7d89403e78f188cd6adcc0 — Jonni Liljamo 1 year, 9 months ago fb43c0a
docs: wip README.md changes
1 files changed, 36 insertions(+), 3 deletions(-)

M README.md
M README.md => README.md +36 -3
@@ 1,11 1,44 @@
# Deck Builder (code-named 'laurelin')
See `dev` branch for latest changes.
---
A deck building game with multiplayer over a web API.
A multiplayer deck building game.

Personal project turned into school project.
## Shortest possible explanation of the structure
```
Client <-> Server <-> API <-> Persistent database (PSQL)
                      API <-> Session store (Redis)
```

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

Things to remember: