Multi-runtime content and feature-management API with authenticated service boundaries, revisioned records, cursor-based change feeds, and PostgreSQL persistence.
Several small applications need the same foundational capabilities: users and applications, feature flags, JSON content, machine credentials, change tracking, and a reliable way to synchronize data incrementally. Coersu Store centralizes those concerns behind one API instead of rebuilding them in every client.
Content records carry a revision number and can opt into change tracking. Tracked mutations append an upsert, delete, or purge event with a monotonically increasing cursor and a denormalized snapshot.
This supports incremental synchronization without requiring clients to repeatedly download the entire dataset. The trade-off is additional storage and stricter transactional requirements: record updates and change events must commit together, and consumers must persist their last successful cursor.
Clients can upsert content using the (app_id, user_id, external_id) boundary. This makes retries safe for callers that own a stable external identifier. Conflicting identities return an explicit conflict rather than silently overwriting another record.
Protected routes accept either expiring JWTs or revocable API tokens. Raw API tokens are returned once and stored only as hashes. App-wide rate-limit settings live in PostgreSQL so configuration is shared across processes instead of being local to one worker.
The primary implementation uses Bun, TypeScript, Elysia, Prisma, and PostgreSQL. Go and FastAPI implementations exercise the same service shape and provide a concrete comparison of runtime, concurrency, and database-access trade-offs. They are alternatives, not independent microservices that must all run in production.
The TypeScript service can use multiple local workers or multiple containers behind Nginx. Database pool budgets must be divided across workers, and process-local caches are not automatically coherent. The repository documents these boundaries rather than claiming transparent horizontal scalability.
client
|
v
HTTP validation + authentication
|
v
domain handler
|
+------> record mutation --------+
| |
+------> change-feed event -------+--> PostgreSQL transaction
|
v
cursor-based incremental reads
| Area | Technology |
|---|---|
| Primary API | Bun, TypeScript, Elysia |
| Alternative APIs | Go, Python, FastAPI |
| Persistence | PostgreSQL, Prisma |
| Authentication | JWT, hashed API tokens, Argon2id |
| Contracts | TypeBox validation, Swagger/OpenAPI |
| Packaging | Docker, Docker Compose, Nginx |
| Load testing | Go stress server and browser dashboard |
Requirements:
- Bun 1.3+
- Node.js 22+ for Prisma tooling
- Docker and Docker Compose
cp .env.example .env
docker compose up --buildThe TypeScript API is available on http://localhost:8785; Swagger documentation is served at /swagger. The repository contains generic demo credentials for local exploration only. Replace or remove seeded demo data before any shared deployment.
bun install --frozen-lockfile
bun run db:generate
bunx prisma db push
bun test
bun run lint
bun run buildThe contents integration suite requires PostgreSQL. GitHub Actions provisions an isolated PostgreSQL service, generates the Prisma client, applies the schema, and runs tests, type checking, and the production build.
The included Go stress service can drive high-concurrency API workloads without browser connection limits. Configuration exposes worker counts and database-pool budgets, but the repository does not publish a throughput claim because no controlled benchmark report is committed.
This repository starts with a clean public history. Private deployment configuration, tokens, personal seed data, local endpoints, and internal operational files are intentionally excluded.
MIT