Dependency Graph & Relationships

This is a pragmatic map of dependencies as they exist in code and deployment.

Workspace-level

• apps/server → @sharingexcess/db, @sharingexcess/types
• apps/client → @sharingexcess/types, (build-time) compiled server exports
• apps/docs → standalone
• crons/backup → none internal; uses DB URL, S3, Sentry
• crons/cleanup → none internal; uses S3, Sentry
• apps/storage → none internal; uses S3, serves as file proxy and admin interface

Runtime/data flows

• Client → Server: API over HTTP, Clerk token attached by client; server validates every request
• Server → DB: Drizzle over Neon (primary + read-replica URL available)
• Server → S3: Uploads user images, partner media, backups (via crons)
• Crons → S3: Write/delete lifecycle for backups
• Storage App → S3: File hosting proxy and admin interface

Build/deploy coupling

• Client Docker build compiles server once to ensure Hono exports consumed by client are up-to-date
• Server Docker build runs DB schema generator and serves assets at /schema*
• Turbo enforces client dev depends on server dev locally

Environment coupling

• .env switching scripts at root keep local development consistent with per-env Railway config
• CORS whitelists and Sentry DSNs differ by env

External systems

• Clerk: identity provider; server maps to internal users
• Neon: database hosting with branching; read replica URL available
• Railway: orchestrates Docker deployments per service with custom resource profiles
• S3: object storage for media and backups (hosted by Railway)