Live data from Hacker News

Show HN: Typebase – A single-folder back end you write in TypeScript

typebase.io

1–10 of 24 posts

Show HN: Typebase – A single-folder back end you write in TypeScript

#1
Hey HN!

I built Typebase, a library that gives you Convex's DX with Supabase's openness.

After trying Supabase I liked how fast it is to spin up a DB and auth, but really didn't like using RLS and SQL for authorization. With Convex I loved how your server "lives" in your code, but disliked the DB model and the realtime-first defaults.

With Typebase you just write TS files inside a typebase/ folder in your existing repo. You can define your DB tables inside a schema.ts file and export server functions that your frontend calls like local functions, fully typed. Auth is built in.

Then one CLI command uploads your server to any of the available providers (Vercel, Cloudflare Workers or Deno Deploy for the servera and Neon for the DB), or generates the code so you can deploy it wherever you want.

Built on top of oRPC, Drizzle, and better-auth.

Happy to answer any questions or feedback!

Show HN: Typebase – A single-folder back end you write in TypeScript
typebase.io

Re: Show HN: Typebase – A single-folder back end you write in TypeScript

#4
I’ve been curious about trying the Supabase type of RLS model for an app but haven’t yet. I like the idea of the db defined api like postgraphile and hasura but had trouble with testing and ergonomics. This looks pretty nice though, it’s cool that you’re thinking about ergonomics for working with coding agents. I feel like a hard thing with that rn is that everyone is kind of figuring out different workflows for AI coding right now so it’s hard to optimize DX. Can you talk a little about your personal agent workflow and how this fits it?

Re: Show HN: Typebase – A single-folder back end you write in TypeScript

#6
This looks great. Question specifically on the Cloudflare Workers target: when you deploy there, does Typebase use D1 for the DB, or does the Postgres/Neon backend stay the same regardless of which server target you pick (Vercel/Workers/Deno) - i.e. is the DB layer decoupled from the server runtime, or does choosing Workers also mean choosing D1? I ask because I've shipped a small Workers+D1 service and the main friction I've hit isn't the server code, it's Workers' constraints around D1 (no long-running connections, HTTP-based driver quirks) - curious whether Typebase abstracts that away or whether you still feel it at the DB layer when targeting Workers specifically.

Re: Show HN: Typebase – A single-folder back end you write in TypeScript

#7
Fake reviews are a hard no-no imo. Really weird addition, but I suppose it wasn't you who got the idea.

Looks an awful lot like a orpc, just built on top of drizzle instead of raw queries. I'm sure some people want this, but it seems like gross duct tape that will bite you in three years

Re: Show HN: Typebase – A single-folder back end you write in TypeScript

#8

This looks great. Question specifically on the Cloudflare Workers target: when you deploy there, does Typebase use D1 for the DB, or does the Postgres/Neon backend stay the same regardless of which server target you pick (Vercel/Workers/Deno) - i.e. is the DB layer decoupled from the server runtime, or does choosing Workers also mean choosing D1? I ask because I've shipped a small Workers+D1 service and the main fric…

I see no code there to automatically pick D1 for the DB when you deploy to Cloudflare.

On Cloudflare, it should use the `@neondatabase/serverless` driver configured here https://github.com/typebase-io/monorepo/blob/fa3af0b71126caa...

Re: Show HN: Typebase – A single-folder back end you write in TypeScript

#9
It’s like next.js but for backend.

Personally not for me. These are very productive once you learn the shape they expect.

But the wheel needs to be reinvented on how to do everything.

I ran have straight forward verbose code with no hidden control flow

Re: Show HN: Typebase – A single-folder back end you write in TypeScript

#10
post #4

I’ve been curious about trying the Supabase type of RLS model for an app but haven’t yet. I like the idea of the db defined api like postgraphile and hasura but had trouble with testing and ergonomics. This looks pretty nice though, it’s cool that you’re thinking about ergonomics for working with coding agents. I feel like a hard thing with that rn is that everyone is kind of figuring out different workflows for AI c…

I've only had experience in one full-stack project with supabase RLS so experience is limited. However it seemed like a mess. Seems much more human-maintainable to have a classic spring/golang backend. For sure in some projects, esp mobile apps, it makes more sense, and fable-level models might also keep it from being full spaghetti.

Also Supabase at that time wasn't reliable and it's not really made for self-hosting. Felt almost as bad as Github stability these days.

Still, based on this limited experience, I've been avoiding RLS and supabase.

Post reply on HN