Appearance
Team Discussion Items
Open decisions that need team input before backend development begins. Each item has options, tradeoffs, and a recommendation where applicable.
For full architecture context, see docs/backend/architecture/overview.md.
1. Hosting
Where do we host the .NET API and PostgreSQL database?
| Option | Pros | Cons |
|---|---|---|
| Azure | Native .NET support, managed Postgres, Blob Storage, easy CI/CD via GitHub Actions | Can get expensive, vendor lock-in |
| AWS | Largest ecosystem (RDS, S3, ECS), most flexibility | More setup/config, less .NET-native tooling |
| VPS (DigitalOcean, Hetzner, etc.) | Cheapest, full control | We manage everything - updates, backups, scaling, SSL |
The architecture is host-agnostic. This decision also drives decisions #4 (file storage) and affects cost.
PO context: Dreamhost is used for the domain. Domain DNS can point anywhere regardless of hosting choice.
2. Authentication
How do we handle user login, registration, password resets, and invitations?
| Option | Pros | Cons |
|---|---|---|
| ASP.NET Identity | Built-in, no external dependency, full control over user data | We build email flows, password reset, and session management ourselves |
| Auth0 or Clerk | Login UI, password reset, social login, MFA out of the box. Free tiers available | External dependency, potential cost at scale, less control |
| Firebase Auth | Generous free tier, good SDKs | Awkward .NET integration, Google ecosystem coupling |
Regardless of choice, the role-based authorization logic (Owner/Storyteller/Player permissions) stays in our code - it's domain-specific.
Key question for the team: Do we want to build auth ourselves for full control, or use a managed service to ship faster?
3. GraphQL vs REST
Should we reconsider GraphQL for the API?
Current decision: REST + custom endpoints. This only changes if someone on the team has hands-on experience with GraphQL in .NET (Hot Chocolate library).
GraphQL would be a natural fit for our nested data (projects > timelines > sections > items) and relationship graph queries. But it adds learning curve and complexity if nobody knows it.
Key question for the team: Does anyone have GraphQL experience, specifically with Hot Chocolate?
4. File Storage
Where do uploaded images live? (character portraits, faction symbols, project art)
| Option | Pros | Cons |
|---|---|---|
| Cloud object storage (S3, Azure Blob, Cloudflare R2) | Scalable, cheap, CDN-friendly, survives server failures | Tied to hosting choice, slightly more setup |
| Server filesystem | Simplest to implement | Doesn't scale, lost if server dies, no CDN |
Recommendation: Cloud object storage. Specific provider depends on hosting decision (#1).
5. Search
How do we implement full-text search across projects, characters, and timelines?
| Option | Pros | Cons |
|---|---|---|
| PostgreSQL built-in (tsvector/tsquery) | No extra infrastructure, already in our DB, good enough for MVP | Basic relevance ranking, no typo tolerance |
| Meilisearch | Great relevance, typo tolerance, fast, lightweight | Extra service to deploy and keep in sync with DB |
| Elasticsearch | Most powerful, faceted search, analytics | Heavy, complex to operate, overkill for our scale |
Recommendation: Start with PostgreSQL full-text search for MVP. Migrate to Meilisearch later if search quality becomes an issue.