One backend. Every app you are building.
Web and mobile on the same backend: one set of users, one set of access rules, one place the data lives. Offline sync is in the SDKs, not in your code.
Start with the web SDK today — npm install @koolbase/js. Add mobile when you get there, against the same project.
One backend, several clients
Write the rules once
A collection's access rules are enforced by the API, so they hold for every client that talks to it — your React dashboard, your React Native app, your Flutter build. Add a rule and it applies everywhere at once, including to realtime subscriptions.
- The same users and sessions across web and mobile
- Access rules enforced server-side, compiled into the query
- Trusted claims — a role set once, read by every rule
- Realtime filtered by the same rules as a read
Offline
A write queue you did not have to build
Reads come from a local cache when the network is gone, and writes queue and replay when it returns. A write the server refuses on replay becomes a conflict you resolve — keep yours, keep theirs, merge, or abandon — rather than a silent overwrite.
- Queued writes survive a reload, a restart, a closed tab
- Conflicts are durable and explicit, not last-write-wins
- Offline edits replay in the order they were made
- The same behaviour on the web and in React Native, proven by one test suite
The rest of the backend
Everything the app needs, already there
Auth with email, phone and OAuth. Storage with presigned uploads and image transforms. Functions that run your code with the caller's identity. Search that is semantic, lexical or both. Feature flags and remote config.
- TypeScript throughout, ESM and CommonJS, about 16 kB gzipped
- Semantic, lexical and hybrid search over your own data
- Presigned uploads, CDN URLs, edge image transforms, versioned objects
- Functions invoked with the signed-in user, not a shared key
Where the platforms differ
Said plainly, not implied
The SDKs share an API, not a runtime. Code push patches the Dart VM and is Flutter-only. Push notifications need a native module, so the web uses Web Push through your own service worker. Session storage is a keychain on a device and IndexedDB in a browser, which is not the same guarantee.
- Designer emits Flutter today; React Native and web are next
- Code push is Flutter-only — there is no VM to patch elsewhere
- Browser sessions live in IndexedDB; the README says what that means
- Everything else — auth, data, storage, realtime, functions — is on all three
What people build on one project
A dashboard and a field app
Managers work in the browser, workers on a phone with no signal. Same users, same collections, same rules — and the phone keeps working.
An admin panel for an existing app
The mobile app is live. The web console is a new client against the same project, not a second backend to keep in step.
A POS that survives the network
Sales queue when the line drops and replay when it returns, with conflicts surfaced rather than swallowed.
Internal tools
Auth, a database with real access rules, and file storage — without standing up a backend for a tool five people use.
A marketplace on two clients
Buyers on the web, sellers on mobile, one set of listings and one place the permissions are written.
Anything that needs search
Semantic, keyword, or both fused together, over your own records, without running a vector database.
Questions
Can I use it with React, Vue, Svelte or Next.js?
Yes. @koolbase/js is a plain TypeScript package with no framework dependency — it works anywhere JavaScript runs in a browser. Under server rendering it loads and initializes without crashing, though it is a client SDK: it holds one session per process, so a server should authenticate its own requests rather than sign users in through it.
Do I have to use Flutter?
No. The web SDK and the React Native SDK are the same core composed for different hosts, and neither needs Flutter. What Flutter adds is code push and the Designer, and those are described as Flutter-only wherever they appear.
Is the web SDK the same as the mobile one?
The same core, with the platform pieces swapped: storage, connectivity, lifecycle and session persistence. Auth, database, offline sync, conflicts, storage, realtime and functions behave identically and are proven by one test suite run against both. Push notifications and code push are the exceptions, and they are listed above.
What happens with two browser tabs open?
They share one queue and are coordinated: one tab replays it, and state changes from different tabs cannot overwrite each other. A tab that closes mid-sync hands off automatically.
Can I migrate off it?
Your data is in Postgres and your files are in object storage, both exportable. The SDK is a client, not a lock-in: the API it speaks is documented and you can call it directly.