← ClaudeAtlas

app-dev-practiceslisted

Practical guide for building Fusebase Apps apps. Use when: (1) Creating a new app, (2) Setting up project structure, Vite config, or authentication, (3) Building or registering apps, (4) Configuring permissions or public access, (5) Navigating between apps, (6) Fetching user details, (7) Troubleshooting build issues.
fusebase-dev/fusebase-flow · ★ 2 · AI & Automation · score 75
Install: claude install-skill fusebase-dev/fusebase-flow
# App Dev Practices ## Always Scaffold First Run `fusebase scaffold --template spa --dir apps/<name>` before writing any app files. This generates the canonical React + Vite + Tailwind v4 + shadcn/ui project structure. For apps needing a backend, also run `fusebase scaffold --template backend --dir apps/<name>`. Customize from there — never recreate boilerplate by hand. ## Multi-User by Default **Every app is multi-user.** Multiple users access the same deployed app simultaneously, each with their own identity (app token). Never design for a single user. **Rules:** - **Per-user state** (OAuth tokens, preferences, selections) must be stored **per-user** — use httpOnly cookies (set by the server, scoped to the user's browser) or dashboard rows keyed by user ID - **Shared env vars / Fusebase secrets** are global — they are the **same for all users**. Never use them for per-user credentials or settings - **In-memory backend variables** are shared across all requests from all users — never store per-user data in module-level variables - When integrating third-party APIs with OAuth, each user must go through their own auth flow and get their own tokens - **Stable partition keys only:** when storing per-user rows, the partition key must come from a **stable identity** (`userId`, `orgUserId`, email if immutable), not from session/token artifacts. - **Never use token-derived keys** (e.g. `ft:*`, JWT fragments, rotating session IDs) as persistent `user_key`/partition keys — they