How do authentication and authorization work? Like Firebase?
(I haven't used a system like that. I'm intrigued by the idea of a backend that's just a database but it weirds me out not to have to write a layer that says who can read what. Exposing the database that nakedly feels super dangerous.)
Similar to Firebase it's multi-strategy based. You can use a combo of email/password or OAuth/OIDC (internally using https://github.com/panva/oauth4webapi) – currently there are 2 pre-configured (Google, Github), but it's easy to extend, so requests are welcome.
On the Authorization side, you can create roles and attach permissions to it. Those roles then get attached to users.
Claims are transported via JWT, you can configure its lifetime, secret and hashing. Currently it's stateless, meaning the token is not checked in a session store. But if there is demand, I'd prioritize adding this. I'm mainly exactly looking for feedback to prioritize next additions.
> (I haven't used a system like that. I'm intrigued by the idea of a backend that's just a database but it weirds me out not to have to write a layer that says who can read what. Exposing the database that nakedly feels super dangerous.)
In my (closed) product that exposes the database to the frontend, the "exposure" part has, effectively, row-level access control.[1]
[1] Also role-based using groups. I additionally mark the read-only queries as read-only and these are executed on a read-only replica.
Broken (missing) auth is pretty common with Firebase/Supabase. It's a developer mistake that could happen in any kind of back-end, but I think that traditional back-end frameworks usually have better conventions that make the mistake less likely.
Since you can embed bknd into any stack, and you can hook into system events, there are plenty of options to customize authorization according to your needs.
I think the project is saying, in cases where you are deploying the Frontend with server side serving, then you can include this. Given projects like NextJS have a server side serving for react server-side-rendering and for APIs this project uses the server side to add additional services as mentioned in the post.
Yes, I agree, but it's really hard to find the right words. How would you describe it better?
That bknd is "embeddable" doesn't mean it has to. Backends such as Supabase or Firebase run on separate deployments. Especially for Supabase, if you want to self-host it, you run multiple services including your frontend. I tried to express that if you host your app on Vercel, CF, etc. – your backend (excluding database) can be deployed together with it.
Of course you can deploy it separately, e.g. fully on Cloudflare using Workers, D1 and R2.
I think the language probably assumes some knowledge specific to that ecosystem, particularly the more recent trend of server rendering react.
To someone that works with more traditional server rendering frameworks like Rails and Phoenix, embedded to me implies storage will be clientside.
I'm guessing it might makesense to a frontend developer but people like me might be scratching our heads for awhile.
I'm assuming this is an alternative to using nextjs (or whatever flavor) with an orm. There's a lot of word salad in the why? that kind of suggests that. Maybe you can simply compare alternatives?
bknd would be the "backend part" of your application, managing the schema, exposing REST APIs to access it, secure it, handling media uploads.
The database (postgres, libsql, d1, etc.) is hosted as usual. Fullstack frameworks like Next.js, Remix, Astro, etc. would run bknd on the server side exclusively.
But I see the issue. I should've written "inside your fullstack app" – my bad!
I frequently use pocketbase because I love its extensibility and simplicity. Is this product like pocketbase but you can edge-deploy it? (i.e more infinitely scalable?)
Yes, e.g. you can fully host it on Cloudflare using Workers, D1 and R2. There is an example in the repo and CLI starter to get started quickly (`npx bknd create -i cloudflare`)
Can it be used without React?
Why make it React-dependent/focused?
How's it better than going with synch engines, like eg. Zero?
Didn't look at code, sorry, on the go now.
Yes it can, a lot of people just choose a React fullstack framework, and it integrates specifically well inside those – so it's just a focus. But it can also be deployed using Docker, Bun, Node or Cloudflare Workers. There's an integrated SDK for TypeScript, but since it's all just REST APIs, it'll work with any stack.
Not familiar with Zero, but it looks interesting, will check it out.
How do authentication and authorization work? Like Firebase?
(I haven't used a system like that. I'm intrigued by the idea of a backend that's just a database but it weirds me out not to have to write a layer that says who can read what. Exposing the database that nakedly feels super dangerous.)
Similar to Firebase it's multi-strategy based. You can use a combo of email/password or OAuth/OIDC (internally using https://github.com/panva/oauth4webapi) – currently there are 2 pre-configured (Google, Github), but it's easy to extend, so requests are welcome.
On the Authorization side, you can create roles and attach permissions to it. Those roles then get attached to users.
Claims are transported via JWT, you can configure its lifetime, secret and hashing. Currently it's stateless, meaning the token is not checked in a session store. But if there is demand, I'd prioritize adding this. I'm mainly exactly looking for feedback to prioritize next additions.
Hope this helps.
> (I haven't used a system like that. I'm intrigued by the idea of a backend that's just a database but it weirds me out not to have to write a layer that says who can read what. Exposing the database that nakedly feels super dangerous.)
In my (closed) product that exposes the database to the frontend, the "exposure" part has, effectively, row-level access control.[1]
[1] Also role-based using groups. I additionally mark the read-only queries as read-only and these are executed on a read-only replica.
Sources here if you ae curious: https://github.com/bknd-io/bknd/tree/main/app/src/auth
Core auth feature progress is tracked here: https://github.com/bknd-io/bknd/issues/6
Broken (missing) auth is pretty common with Firebase/Supabase. It's a developer mistake that could happen in any kind of back-end, but I think that traditional back-end frameworks usually have better conventions that make the mistake less likely.
Yeah, I've never understood this. I can't think of any operation where I wouldn't want some backend logic in between. Firebase rules don't cut it.
Since you can embed bknd into any stack, and you can hook into system events, there are plenty of options to customize authorization according to your needs.
It does.. I know postgrest is like this though
What does this mean?:
> bknd runs directly inside your frontend app — no separate backend required.
> It supports Postgres
How is the postgres credentials kept secret from the client?
I think the project is saying, in cases where you are deploying the Frontend with server side serving, then you can include this. Given projects like NextJS have a server side serving for react server-side-rendering and for APIs this project uses the server side to add additional services as mentioned in the post.
Yeah, the messaging isn't very clear.
Yes, I agree, but it's really hard to find the right words. How would you describe it better?
That bknd is "embeddable" doesn't mean it has to. Backends such as Supabase or Firebase run on separate deployments. Especially for Supabase, if you want to self-host it, you run multiple services including your frontend. I tried to express that if you host your app on Vercel, CF, etc. – your backend (excluding database) can be deployed together with it.
Of course you can deploy it separately, e.g. fully on Cloudflare using Workers, D1 and R2.
I think the language probably assumes some knowledge specific to that ecosystem, particularly the more recent trend of server rendering react.
To someone that works with more traditional server rendering frameworks like Rails and Phoenix, embedded to me implies storage will be clientside.
I'm guessing it might makesense to a frontend developer but people like me might be scratching our heads for awhile.
I'm assuming this is an alternative to using nextjs (or whatever flavor) with an orm. There's a lot of word salad in the why? that kind of suggests that. Maybe you can simply compare alternatives?
bknd would be the "backend part" of your application, managing the schema, exposing REST APIs to access it, secure it, handling media uploads.
The database (postgres, libsql, d1, etc.) is hosted as usual. Fullstack frameworks like Next.js, Remix, Astro, etc. would run bknd on the server side exclusively.
But I see the issue. I should've written "inside your fullstack app" – my bad!
> Edge-Optimized
I frequently use pocketbase because I love its extensibility and simplicity. Is this product like pocketbase but you can edge-deploy it? (i.e more infinitely scalable?)
Yes, e.g. you can fully host it on Cloudflare using Workers, D1 and R2. There is an example in the repo and CLI starter to get started quickly (`npx bknd create -i cloudflare`)
cool. may try it out later!
Can it be used without React? Why make it React-dependent/focused? How's it better than going with synch engines, like eg. Zero? Didn't look at code, sorry, on the go now.
Yes it can, a lot of people just choose a React fullstack framework, and it integrates specifically well inside those – so it's just a focus. But it can also be deployed using Docker, Bun, Node or Cloudflare Workers. There's an integrated SDK for TypeScript, but since it's all just REST APIs, it'll work with any stack.
Not familiar with Zero, but it looks interesting, will check it out.
Bknd is great. Thank you for creating this, Dennis!
Thanks a lot Cam! :)
Why so complicated? A torch should suffice for a basic fire.
[dead]