kapilagrawal95 / go-random-chat

Modern real-time random chat with high performance and linear scalability, written in go.

Go Random Chat

Modern real-time random chat with high performance and linear scalability, written in go.

Features:

• Real-time communication and efficient websocket handling using Melody.
• Microservices architecture. All services can be horizontally scaled on demand.
  • web: frontend server
  • user: user account server
  • match: user matching server
  • chat: messaging server
  • uploader: file uploader
• Use gRPC for inter-service communication
• Use cobra and viper for CLI and configuration management respectively.
• Dependency injection using wire.
• Observability using client_golang and opentelemetry-go.
• Stateless messaging with the help of Redis Pub/Sub.
  • Redis Pub/Sub provides only at-most-once delivery, so there is chance of data loss during matching and chatting stages.
  • If you prefer at-least-once delivery for message Pub/Sub, please refer to this branch where Kafka is used as the message broker.
• Message retention for a certain period.
• User matching with idempotency.
• Message seen feature.
• Auto-scroll to the first unseen message.
• Automatic websocket reconnection.
• File uploads using object storage.
• Responsive web design.

System architecture:

Usage

Prerequisite:

• Docker-Compose v2
• Root permission

To run locally, execute the following command:

cd deployments
sudo ./run.sh run

run.sh needs root permission to alias minio to localhost in /etc/hosts.

This will spin up all services declared in docker-compose.yaml. Visit http://localhost and you will see the application home page.

Example configuration: config.example.yaml.

Deploy with SSL

A common scenario is that one deploys the application behind a reverse proxy with SSL termination. If that is your case, remember to correctly configure your proxy for websocket. For example, in Google Cloud Platform, for websocket traffic sent through a Google Cloud external HTTP(S) load balancer, the backend service timeout is interpreted as the maximum amount of time that a WebSocket connection can remain open, whether idle or not. Therefore, you may want to use a timeoutSec value larger than the default 30 seconds in your BackendConfig.

Docker Tagging Rules

Event	Ref	Docker Tags
pull_request	refs/pull/2/merge	pr-2
push	refs/heads/master	master
push	refs/heads/releases/v1	releases-v1
push tag	refs/tags/v1.2.3	v1.2.3, latest
push tag	refs/tags/v2.0.8-beta.67	v2.0.8-beta.67, latest

Screenshots