43 lines
2.3 KiB
Markdown
43 lines
2.3 KiB
Markdown
|
model: deepseek-reasoner
|
||
|
|
prompt: model-tests/01-architectural-risk.md
|
||
|
|
date: 2026-06-04
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
1. fedify/activitypub from day one, federation off
|
||
|
|
|
||
|
|
the risk is paying a nontrivial complexity tax (uri-based ids everywhere, fedify's
|
||
|
|
type system coupled to elysia, ap protocol shapes in the data model) for a
|
||
|
|
feature that's gated behind an off flag. fedify is a small team and its bun/elysia
|
||
|
|
binding may not keep pace with runtime changes. you'll debug fedify internals
|
||
|
|
before you ever federate a single post. mitigation: wrap all fedify calls behind a
|
||
|
|
thin repository/port interface in the domain layer. if fedify breaks or stalls,
|
||
|
|
you swap to a minimal ap implementation without touching business logic. don't let
|
||
|
|
fedify's types bleed into your controllers.
|
||
|
|
|
||
|
|
2. sqlite with "postgres-ready" schema
|
||
|
|
|
||
|
|
the classic migration trap. sqlite and postgres differ in transaction semantics,
|
||
|
|
query planning, type coercion, and concurrency (wal vs mvcc). writing sql that
|
||
|
|
performs well on both is harder than committing to one. the specific pattern i'd
|
||
|
|
watch: bun:sqlite is synchronous — sqlite calls block the elysia event loop. for
|
||
|
|
5-50 users it's fine, but the moment you need queries that use postgres-specific
|
||
|
|
features (jsonb, partial indexes, ctes for complex follows) you'll have rewritten
|
||
|
|
significant code anyway. mitigation: commit to sqlite fully. use wal mode, measure
|
||
|
|
whether event-loop blocking matters at your scale, and only design a thin query
|
||
|
|
adapter — not a dual-runtime schema. the "just swap the connection string" plan
|
||
|
|
doesn't survive contact with real query differences.
|
||
|
|
|
||
|
|
3. tus.io resumable uploads from the first alpha
|
||
|
|
|
||
|
|
the biggest hidden complexity in the stack. tus is a protocol, not a plug-in. on
|
||
|
|
the flutter side you need: platform-specific background upload services
|
||
|
|
(urlsession on ios / workmanager on android), a chunk-state machine, and resume
|
||
|
|
logic. on the server: chunk reassembly, temp storage for partial uploads, cleanup
|
||
|
|
of abandoned transfers. for 5-50 users posting a few photos a day, a simple
|
||
|
|
multipart upload with exponential backoff covers 95% of the same use case with a
|
||
|
|
fraction of the surface area. mitigation: ship the alpha with plain multipart
|
||
|
|
upload behind a clean interface. add tus only when real-world users on bad
|
||
|
|
connections demonstrably need it. you'll know when because they'll tell you — 5
|
||
|
|
people on a train is a clearer signal than any architecture doc.
|