DEV Community

KREO
KREO

Posted on

Every table you create becomes an instant REST + GraphQL API

I keep rebuilding the same backend.

Postgres, then auth, then a little CRUD API on top, then a cache once it gets slow, then websockets when I want live updates. By the time that's working I've burned a week and haven't touched the actual idea yet. Did it enough times that I got annoyed and made the thing that does it for me.

It's called KREO. You write your tables in SQL and the API is just... already there.

You make this:

create table todos (
id bigserial primary key,
task text not null,
done boolean default false
);
and it's a REST endpoint right away:

curl "https://app.kreo.work/api/rest/todos?done=false&limit=20" \
-H "x-kreo-api-key: $KEY"
Filtering, sorting, pagination are just query params, I didn't wire up anything. Same schema also gives you a GraphQL API with a playground (no resolvers to write):

{ todos(where: { done: false }, limit: 5) { id task } }
Auth is built in (passwords, passkeys, MFA, plus API keys you can lock to an IP for scripts). There's realtime if you subscribe to a table, a Redis cache you flip on per table, serverless functions, file storage, pgvector if you're doing AI stuff. It's a normal Postgres schema underneath, so your own indexes/views/constraints still work.

Instead of making you sign up to see any of it, I stuck the actual dashboard behind a throwaway demo project that already has data in it:

https://app.kreo.work/demo

Go run some queries, hit the API. It's read-only so you can't break anything.

Free right now while it's in beta, 100k requests a month, no card. Docs: https://app.kreo.work/docs

I work on it so obviously I'm biased, but I really do want to know what other people think. If you were starting something tomorrow, what would actually stop you from using this? What's missing?

KREO:
https://kreo.work

Top comments (0)