anarthal / servertech-chat Goto Github PK

Pasting something like https://imgur.com/a/hBszWqq should automatically create a link to be clicked.

Design a mechanism to run migrations to create/alter tables.

When the user scroll up past the last message loaded by the client, it should request the server for more messages (requestMessageHistory). The server-side part is already done.

We currently run a single-threaded io_context. Consider how we can make it multi-threaded (one context per thread vs. multiple threads and one context).

When the Redis container is deleted and re-created in AWS, messages are lost. Place them in a volume so this doesn't happen.

Redis persistence is by default configured to just use RDB, which doesn't provide enough durability. Redis docs suggest that enabling AOF with the default settings should get us the desired performance/durability tradeoff.

Not having health checks makes deployments slower.

Even if the code hasn't changed, which is supposed to be handled by Docker caches.

Now it's the room first returned by the server.

Create a class that can dispatch to different handling functions depending on the HTTP request target, similar to what express or flask do.

We'd love to hear your feedback!

I you think something's improvable, you're stuck with something, or you've successfully used the app and want to share your experience, please share your thoughts by commenting on this issue!

When the client fails to open a websocket connection or an error is encountered, it should somehow display this information to the user, and try to reconnect.

Returned

There was an unexpected error. Please try again later.

Should be

Email already in use

https://christian-schneider.net/CrossSiteWebSocketHijacking.html

We're currently running Redis without authentication, and MySQL with a blank root password (which almost equals no authentication). This is not terrible because these two services are never exposed outside of the Docker network (so an attacker must gain access to the server host to do anything), but it's not good practice.

MySQL root should have a strong password, and there should be a dedicated user with minimum privilege that's used in the webserver. We can create such user as part of a migration (see #11), and the password can be transmitted using AWS SSM. This requires the EC2 instance to call the AWS API though - so the CloudFormation scripts need to have IAM access to create a role for the EC2 instances.

Implement user registration and login.

User registration

Registration should require an email, a password and a username. All fields should be validated.

A set of password validation rules should be defined and enforced to prevent the user from choosing week passwords.

Email verification (as in sending an email with a unique token and validating it) is not required at this point.

Proposed API:

POST /register
{ "username": "xxx", "email": "xxx", "password": "xxx" }

Login

With email and password.

Suggestion: use a session cookie at least 128bit long, stored in Redis, valid for 7 days.

Document the code internals so other users can read it. Like Beast does with its examples.

This is an optional flow. Should be enabled if the backend gets credentials for the mailing service.

Complementing #43. Discuss the possible approaches in the docs, even if they don't get shown in code.

if accessing with http://ec2-16-171-209-243.eu-north-1.compute.amazonaws.com/chat it allow you to skip setting a username and gives a random one

With email and password.

Suggestion: use a session cookie at least 128bit long, stored in Redis, valid for 7 days.

Otherwise it may seem this is a Boost library.

shared_state.hpp contains includes for multi_index and a compile-time heavy instantiation. Consider how we can move it to a TU.

Asciidoc (or GitHub markdown) documentation about the project architecture and best practices, as described in this document. Should be accessible from the "Docs" tab.

Consider using Redis channels.

Messages are currently stored using Redis streams. A stream per room (per "whatsapp group")
Messages are inserted with XADD, history retrieved with XREVRANGE

After a while the size will grow, and is time to store in mysql
Evaluate the usage of XTRIM, which IIRC is intended for the offloading process

• Simulate N connection (say 10K client), all registering to the same channel, measure the time to fan out (IE delivery) a message to all the connected client. This will not take into account network problem that will require retry. Client should be on a separated machine.

• Same as above but vary the number of client, to have a fancy scaling graph.

Implement a client class to interact with an external mailing API. It will be used for signup & password recover flows. It should demonstrate how to call external APIs using Boost. We can consider using the not-yet-in-boost Requests library.

When a websocket session starts, we may receive a message while we're sending the hello event. Avoid this.

Hashing passwords is expensive, and shouldn't be handled in the main thread. This can be an opportunity to show strategies for #43.

As per this and this ML suggestions, there are some times where "do all async" isn't viable (e.g. because the database you're talking to has only a sync API). Demonstrate how this can be handled, e.g. by dispatching to a thread pool.

Currently, we're creating, connecting, closing and destroying a MySQL connection for every request. This is inefficient. A connection pool can be much more efficient.

Not required anymore

We currently have Redis health checks disabled to reduce log verbosity - configure this correctly.

If I'm not mistaken, this is because we're not waiting for the services to be healthy. Re-introduce health checks in docker-compose and use docker compose --wait

Currently, startMessage is being passed to Redis without proper validation, which can cause vulnerabilities.

The proper way to implement room history requests is using a REST endpoint, not a websocket event.

We currently run unit tests without sanitizers because Alpine Linux uses musl-libc, which doesn't support them. Consider other Linux distributions.

Integration tests are built in Release mode. We can consider running them with sanitizers enabled, but it can make sense running them with the same container build used for production.