A backend for frontend developers

cloudconfig is my backend infrastructure project. Its starting point is a familiar frustration: building an interface is straightforward, but the database, validation, routes, access rules and deployment need to agree with each other.

The aim is to express those shared decisions in a TypeScript backend definition and derive the repetitive parts from it.

One definition, several connected pieces

The current project describes model definitions, database migrations, validated REST routes, authentication, access rules and a typed client. The same model definition gives the frontend and backend a common contract.

Nuxt applications use the Nuxt integration. A standalone API is also part of the project. The deployment target today is Cloudflare.

Where the boundaries belong

A typed client helps a developer call an API correctly. Access rules still belong on the server. A generated endpoint needs to enforce the application’s rules whether the request comes from a dashboard, a script or an agent.

That distinction is especially useful when a natural-language interface proposes an action. The proposal is an input to the application, and the backend determines which operations are permitted.

Current status

cloudconfig is in beta, and its API can change before a stable release. Cloudflare is the current platform; broader cloud portability is a direction for the project, not a promise that other platforms already have full support.

Read the project documentation for current setup and deployment details. My article on a backend for frontend developers connects that work to a public post about the idea.

Writing about cloudconfig