What a developer receives from LobLogix
For whoever builds the frontend. The connection points a built backend offers, how they are described, and how its users sign in.
This page is for whoever builds the frontend: a developer, an agency, or you with an AI coding tool. LobLogix builds the backend, and the frontend connects to it.
Two ways to connect
A built application offers two standard interfaces, both generated from the same specification:
- JSON:API, for straightforward reading and writing of records.
- GraphQL, when a screen needs several linked records in one request.
A description you can generate from
Every record and action available over JSON:API is described in an OpenAPI document. It stays in step with the application, because both come from the specification. Use it to generate a typed client. AI coding tools read it too.
GraphQL is not in that document. It describes itself through its own schema, which GraphQL tools read from the endpoint, so a typed GraphQL client comes from that schema.
Pages to try requests
Open app in the workspace opens the application’s own pages for exploring both interfaces and sending requests by hand.
Sign-in and permissions
The application’s users sign in to the application itself. What each role may see and do is decided by the specification and enforced by the application, so a screen does not have to enforce it again. A request the rules refuse comes back as a refusal.
What stays stable
The version running in Stage is the exact one that passed the agreed checks. When the business changes the specification, a new version is built and checked, and the description changes with it.
Where to start
Read the Living Spec first. It tells you what the business agreed, in the business’s words. See What LobLogix builds, and what it doesn’t.
What it is built on
Elixir on the Erlang virtual machine, with records in PostgreSQL. See The technology underneath.