RelayGO

RelayGO is a Go, Fiber, Redis, PostgreSQL, and WebSocket realtime chat service.

The project is designed for production-oriented development. Before mass-user deployment, the production gates in this repository must pass: secure configuration, durable data modeling, scalable WebSocket fanout, tests, CI, observability, and operational runbooks.

Portfolio Value

RelayGO demonstrates realtime backend engineering: authenticated WebSocket sessions, Redis-backed coordination, PostgreSQL persistence, REST endpoints, readiness checks, metrics, Swagger/OpenAPI documentation, Docker Compose startup, and a clear path toward multi-instance fanout.

flowchart TB
    Client[Web / Mobile Client] --> HTTP[Fiber HTTP API]
    Client --> WS[WebSocket Endpoint]
    HTTP --> Auth[JWT Auth Middleware]
    WS --> Auth
    Auth --> App[Chat Service]
    App --> Postgres[(PostgreSQL)]
    App --> Redis[(Redis)]
    Redis --> Presence[Presence / Fanout / Rate Limits]
    App --> Metrics[Health, Readiness, Metrics]

Loading

Skills Demonstrated

• Go service design with Fiber.
• WebSocket connection lifecycle modeling.
• JWT-secured REST and realtime endpoints.
• Redis usage for realtime coordination and cache-like data.
• PostgreSQL persistence with GORM.
• Production planning for metrics, load testing, runbooks, and deployment.

Current Stack

• Go 1.20
• Fiber HTTP server
• Fiber WebSocket
• Redis for realtime coordination, cache data, and fanout
• PostgreSQL with GORM for user data
• JWT authentication
• Swagger/OpenAPI generated files in docs/

Quick Start

Install these local dependencies:

• Go
• Redis
• PostgreSQL

Create local environment configuration:

cp .env.example .env

Update .env for your machine, then run:

go mod download
go run main.go

The app listens on http://localhost:8080 by default.

You can also run the local service stack with Docker Compose:

docker compose up --build

The Compose stack starts the app, PostgreSQL, and Redis. It enables RUN_MIGRATIONS=true so local schemas are created automatically.

API Overview

• POST /register: register a user.
• POST /login: login and receive a JWT.
• GET /verify-contact: verify a contact for the authenticated user.
• GET /chat-history: fetch chat history between two users.
• GET /contact-list: fetch the authenticated user's contacts.
• GET /ws: open a WebSocket chat connection.
• GET /healthz: process health check.
• GET /readyz: Redis and PostgreSQL readiness check.
• GET /metrics: basic HTTP and WebSocket service counters.

Generated Swagger files are available in docs/swagger.yaml and docs/swagger.json. The production-facing API contract is documented in docs/API.md.

Production Documentation

Read these documents before making production changes:

• docs/ARCHITECTURE.md: current architecture, target architecture, and component responsibilities.
• docs/ROADMAP.md: phased plan toward production-ready service.
• docs/IMPLEMENTATION_STATUS.md: current implementation progress and remaining blockers.
• docs/BUILD_PRINCIPLES.md: engineering principles for the next implementation phase.
• docs/PRODUCTION_READINESS.md: deployment gates for security, reliability, scale, quality, and operations.
• docs/FINAL_PRODUCTION_GATE.md: current launch-gate evidence and remaining blocked checks.
• docs/DEPLOYMENT_PLAN.md: target deployment topology, release process, rollback, and infrastructure assumptions.
• docs/OPERATIONS.md: secret management, dashboards, alerts, incident runbooks, and rollback policy.
• docs/PASSWORD_MIGRATION.md: migration/reset plan for legacy plaintext passwords.
• docs/LOAD_TESTING.md: HTTP and WebSocket load-test targets and result template.
• docs/API.md: REST API behavior and error conventions.
• docs/WEBSOCKET.md: WebSocket authentication, message schema, delivery, reconnect, and scaling notes.
• docs/REDIS_SCHEMA.md: current and proposed Redis key model.
• docs/DATABASE.md: PostgreSQL ownership, schema direction, migrations, and indexes.

Production Direction

The target production architecture keeps durable product data in PostgreSQL and uses Redis for realtime coordination, presence, cache-like data, rate limits, and cross-instance WebSocket fanout.

Before serving a large user base, the project must pass these gates:

• No hardcoded secrets or plaintext passwords.
• Durable conversation and message schema with migrations.
• Concurrency-safe WebSocket connection lifecycle.
• Multi-instance delivery through Redis Pub/Sub or Redis Streams.
• Health checks, graceful shutdown, structured logging, metrics, and alerts.
• Unit, integration, WebSocket, and load tests.
• CI pipeline and documented deployment/rollback process.

Development Principle

Build the production foundation before adding features. The next implementation phase should start with configuration, authentication, error handling, and data model fixes, because every later scaling decision depends on those foundations.