llebj / orleans-on-containers Goto Github PK

Description

Currently when a client starts, it automatically attempts to join a chat called 'test'. There is no way for a user to choose to join a different chat, or to leave that chat and then join a second one.

Proposal

When the client application starts a user should be prompted for the name of the chat that they would like to join. When a user leaves a chat they should then be returned to the 'lobby' where they have the option to either join another chat or to terminate the application. Additionally, when a user either joins or leaves a chat, a message should be sent to all other connected clients notifying them of the event.

Tasks

• Notify chat grain observers when another observer either subscribes or unsubscribes.
• Allow a user of the Client to join and leave chats that they specify.

Description

Both the Silo and the Client support using Postgres as an Orleans clustering provider, requiring a connection string to access the database. Currently the only way to provide this connection string when running in Docker is by using environment variables, which is not an appropriate way of handling a secret, such as a connection string.

Proposal

Support reading the connection string out of a mounted Docker secret file. The file path will be provided to an application through an environment variable and then the connection string will be read from that file.

Description

When the client application is running as a Docker container and a signal is sent to stop the container (either by using the CLI or Docker Desktop), the application does not terminate gracefully. Instead, it returns a 137 exit code after the timeout period expires.

To reproduce

1. Start the containers by running docker compose up -d from the directory containing compose.yaml.
2. Run docker compose down from the same directory.
3. Running docker container ls -a will show the container exited with a 137 status code.

Cause

This issue is caused by a call to Console.ReadKey() in src/OrleansOnContainers/Client/Services/ChatHostedService.cs. This call is blocking and stops the application from being able to respond to the shutdown signal.

Description

Currently the console client application connects directly to the orleans silo. There are a number of issues with this architecture:

1. Connections between orleans clients and silos are unsecure.
2. A postgresql database is currently being used as a clustering provider. Providing direct database access to all connected clients is a significant security concern. The number of clients is also limited to the maximum number of concurrent connections that the database supports, limiting scalability.

Proposal

Introducing frontend web servers that sit between the silo backend and the console clients has the potential to greatly improve the security and scalablility of the system. A web API can be used to ensure that only authenticated users can join a chat, while a separate web server dedicated to handling SignalR connections will ensure that persistent web socket connections do not impact the performance of the web API. These two web servers will protect both the silo server and the database from unsecure direct access. Using web servers also greatly increases the number of supported client connections before database connection limits become an issue.

Tasks

• Create a web API that allows user registration and authentication.
• Add API endpoints for interacting with chat rooms.
• Create a web app for handling SignalR functionality.