FrontierJS

Comparisons

None of the ideas are new. Holding them in one design is.

Every idea FrontierJS builds on was proven somewhere else first. Here is what each of those projects got right, what FrontierJS adds by combining them, and what it cannot claim yet.

Standing on

ProjectWhat they got right
RailsConvention can encode architecture. The relationships between model, persistence, routing and behavior don't need explaining again in every app. Rails made app structure itself readable.
LaravelBatteries belong in the framework. Queues, mail, notifications and auth share one vocabulary instead of five libraries glued together.
ElmMake the underlying model explicit, and behavior follows from it. State, messages, updates and views are one system, not unrelated layers.
Phoenix / LiveViewThe UI doesn't need its own separate world. Server state, events, validation and rendered UI can stay close together.
GraphQLDescribe the information first. A schema defines the types, relationships and operations, and each client takes the part it needs.
OpenAPIOne spec can produce many artifacts. Docs, clients, mocks, tests and types all come from one description.
JSON SchemaMeaning can live in the schema instead of in separate validation code, and the same definition can drive the UI.
PrismaThe data model is something developers read and edit. Migrations and the client API are derived from it.
ZenStackAccess rules belong in the schema. Policies sit next to the fields they protect and are enforced by the client.
Supabase / PostgRESTThe database already knows enough to be an API. Postgres row-level security keeps access rules in the data.
HasuraSchema to API to permissions, with no controllers in between.
DirectusA data model can become a whole app surface: API, permissions, admin UI and forms.
ServiceStack AutoQueryOne declaration can produce many surfaces: a query API, CRUD, UI and typed clients.
WaspOne declaration file can describe a whole fullstack app.
RedwoodJSScaffold from the schema, across API and web, with conventions set in advance.
ConvexThe backend can be reactive by default. Queries stay live without the app wiring any of it up.
dbo.io"The schema is the application": REST API, security, content rendering and messaging all from the schema.
Schema2AIOne schema across many boundaries: server, browser UI, AI tools, docs and validation.
RaisinDBA schema can describe the UX, not just storage. Data structures map to interface patterns.

What FrontierJS adds

  1. One gate for every way in. HTTP, WebSocket, background jobs and the AI agent all go through the same access check at the data layer. There is no bypass key and no second code path.
  2. An agent's permissions are the app's permissions. The MCP endpoint runs inside the API that is already serving and uses the same gate. It is not a separate generated layer.
  3. The schema reaches your product's UI, not an admin panel. A Resource's form, field options and validation come from the model.
  4. Realtime respects each recipient's access. A broadcast is checked against every subscriber's access level, not just sent to a channel that is trusted to be right.
  5. Behavior is declared, not just shape. State transitions, encryption, guarded fields and audit redaction are written in the schema next to the types.
  6. One design, end to end. Data, API, UI compiler, jobs, third-party calls, CLI and deploy are one framework with one vocabulary, not glue between libraries.
  7. No platform. Your app is a file tree and a SQLite file you own.
  8. The doctrine is checked. The vocabulary and the invariants are enforced by tooling and CI, not just written down.