Backend server for Modraw — a hand-drawn style collaborative whiteboard application. Provides REST API for resource management and WebSocket-based real-time collaborative editing with CRDT conflict resolution.

• Go 1.17+
• PostgreSQL 12+ (with uuid-ossp extension)

# Clone
git clone https://github.com/trainking/modraw-server.git
cd modraw-server

# Configure environment
cp .env.example .env
# Edit .env — set DATABASE_URL and JWT_SECRET

# Install dependencies
go mod download

# Build & run
go run ./cmd/server

The server starts on :8080 by default. Migrations run automatically on startup.

cmd/server/main.go           Entrypoint & dependency wiring
internal/
  config/                    Environment-based configuration
  database/                  PostgreSQL connection pool & migration runner
  model/                     Data structs (User, Canvas, Folder, etc.)
  repository/                Raw SQL database queries
  service/                   Business logic & authorization
  handler/                   HTTP request handlers (Gin)
  middleware/                JWT auth, CORS, panic recovery
  ws/                        WebSocket hub/room/client for real-time collaboration
  crdt/                      CRDT conflict resolution for canvas operations
pkg/
  jwt/                       JWT token generation & validation
  httputil/                  JSON response helpers
migrations/                  SQL migration files (auto-run at startup)

Explicit dependency injection — main.go creates repos → services → handlers → routes. No DI framework.

Request → Middleware (CORS, Auth) → Handler → Service → Repository → PostgreSQL
                                              ↘ CRDT (in-memory, per canvas room)

See API.md for full endpoint documentation.

Connect to /ws?token=<access_token>. The server uses a message-based protocol — all frames are JSON with { "type": "...", "payload": {...} }.

Client → Server messages:

Server → Client messages:

Operations sent via op messages use a state-based CRDT with LWW (Last-Writer-Wins) semantics:

{ "op": "element_add",    "elem_id": "uuid", "version": 1, "props": {...} }
{ "op": "element_update", "elem_id": "uuid", "version": 2, "props": {...} }
{ "op": "element_delete", "elem_id": "uuid", "version": 3 }
{ "op": "elements_reorder", "elem_ids": ["uuid1", "uuid2", ...], "version": 1 }
{ "op": "canvas_update", "version": 1, "props": { "background": "grid" } }

Each element carries a monotonic version. Higher versions overwrite; stale versions (≤ current) are acked but not applied. Property merging is shallow per-key.

All API responses follow a consistent envelope:

// Success
{ "ok": true, "data": {...} }

// Created (201)
{ "ok": true, "data": {...} }

// Paginated list
{ "ok": true, "data": [...], "page": 1, "limit": 20, "total": 42 }

// Error
{ "ok": false, "error": "ERROR_CODE", "message": "Human-readable description" }

PostgreSQL with UUID primary keys via uuid-ossp extension. Tables:

• users — accounts with bcrypt-hashed passwords
• folders — self-referencing tree structure (parent_id)
• canvases — JSONB data column stores the full scene state
• libraries — reusable asset libraries (JSONB)
• share_links — shareable canvas access links with optional password & expiration
• canvas_collaborators — per-canvas user permissions (readonly/collaborate)
• refresh_tokens — token rotation with revocation support

Migrations in migrations/ run sequentially by filename on server startup.

MIT