app-backendlisted

Guide for adding a backend layer (REST API, WebSockets, cron jobs) to Fusebase Apps apps. Use when: (1) An app needs a server-side API beyond the Dashboard SDK, (2) Adding REST endpoints or WebSocket support, (3) Setting up the backend/ folder structure, (4) Scheduling cron jobs for periodic tasks. The backend is OPTIONAL — only add when the app genuinely requires server-side logic.
fusebase-dev/fusebase-flow · ★ 2 · API & Backend · score 75

Install: claude install-skill fusebase-dev/fusebase-flow

# App Backend ## Multi-User Architecture **Apps are always multi-user.** The backend serves requests from many users concurrently. Every design decision must account for this. **Per-user vs. shared state:** | Storage | Scope | Use for | | --------------------------------- | ----------------------------------- | -------------------------------------------- | | httpOnly cookies | Per-user (per browser) | OAuth tokens, user preferences, session data | | Dashboard rows (keyed by user ID) | Per-user (persistent) | User settings, saved state | | Fusebase secrets / env vars | Shared (all users) | API keys, service-account credentials | | In-memory variables | Shared (all users, lost on restart) | Short-lived caches only | **Common mistakes:** - ❌ Storing a user's OAuth token in an env var or in-memory config → all users share one token - ❌ Storing a user's preference in a module-level variable → last user's preference wins for everyone - ❌ Using env vars for per-user settings or selections → same value for everyone - ❌ Using session/token-derived values (`ft:*`, JWT pieces, rotating token IDs) as persistent row partition keys - ✅ Store per-user data in cookies or dashboard rows keyed by user - ✅ Use env vars only for credentials/config shared across all users (