Bitfield is a database and a runtime that runs on any device.
You have an idea, then the idea changes. You add a phone screen, a laptop dashboard, a background job, a file, a local mode, and a friend who wants to try it. The hard part is not writing the first feature. The hard part is keeping feature one from trapping feature one hundred.Store
Records and content survive restarts and give the product a place to return to.
+
Run
Runnable pieces can read, transform, render, or answer requests through Bitfield.
+
Use
The account decides which runtime identities can trigger Bitfield with your key.
Why it exists
The usual way of building makes you pick a database, a framework, deployment, sync, offline behavior, files, background jobs, and device strategy before you know what the product will become.That works until the product changes. Then every new feature starts depending on old features. One edit turns into ten.Bitfield changes the dependency pattern. Every feature uses Bitfield’s public names instead of directly importing every other feature.The term ladder
Database.
The durable side. It remembers records and content.
Runtime.
The runnable side. It loads the pieces that do work.
Runtime Kit.
The app-facing package. Your app reads named data and sends named requests through it.
Slot.
A named package target your app can ask to do work. Your app calls the public slot name, not the private implementation.
Package.
A product boundary that can declare records, package-owned bytes, and callable targets.
Active device.
A device or runtime identity that triggered Bitfield in the billing window.
What this prevents
The point
You get structure without giving up speed. You can start small and keep adding pieces without making every feature depend on every other feature.Next
- Understand why database and runtime belong together: Database and runtime
- Make the first app-facing call: Quickstart
- Build the first screen: Package to screen
- Check the speed claim: How Bitfield is this fast