@@ -24,17 +24,17 @@
|
||||
|
||||
**Rationale:** Provides security (tokens can be revoked) and aligns with OAuth2 best practices for refresh token management.
|
||||
|
||||
## 5. SQLite for Development
|
||||
## 5. PostgreSQL Everywhere
|
||||
|
||||
**Decision:** SQLite is the default development database.
|
||||
**Decision:** PostgreSQL is used in development, CI and production.
|
||||
|
||||
**Rationale:** Zero configuration, fast for local development, and Prisma abstracts most differences. PostgreSQL migration path is documented in production.md.
|
||||
**Rationale:** One database means one set of migrations; the schema uses JSON columns and serializable transactions that SQLite doesn't support the same way.
|
||||
|
||||
## 6. No WebSockets
|
||||
## 6. Invalidation-Only Live Updates
|
||||
|
||||
**Decision:** Dashboard uses polling (TanStack Query) instead of WebSockets.
|
||||
**Decision:** The API pushes topic names (`tabs`, `commands`, ...) over Socket.IO; the dashboard refetches that data over the normal REST API. It falls back to polling while the socket is down.
|
||||
|
||||
**Rationale:** Simpler implementation, adequate for the expected update frequency (5-30 second intervals), and avoids WebSocket server infrastructure.
|
||||
**Rationale:** Events never carry data, so a socket can't see anything its owner couldn't fetch, and the REST API stays the single source of truth.
|
||||
|
||||
## 7. In-Memory Rate Limiting
|
||||
|
||||
|
||||
Reference in New Issue
Block a user