Show HN: ZenStack – open-source toolkit simplifying your Prisma ORM stack
zenstack.devWe have been polishing ZenStack for the past few months with the community. As it has been successfully used in production by some of our users, we think it’s time to share our beta with you.
ZenStack is built on top of Primsa ORM, extending it with a powerful access control layer that simplifies the development of a web app's backend. By defining authorization policies and validation rules right inside the data schema, your database client can automatically enforce these constraints at runtime.
Why we built this:
Based on our experience developing several commercial SaaS products, we have observed that a significant portion of code is wrapping around the database and providing an access-controlled CRUD API. These boring boilerplate codes are both tedious to write and error-prone to maintain because it is scattered within the codebase.
Utilizing our previous experience with DSL, we created ZenStack to bring the below clear benefits:
- Centralized access control for better security and maintainability
- Less code to be written
Some other benefits you can also enjoy:
- Automatic CRUD APIs - RESTful, tRPC
- Generating client-side data access libraries (aka hooks) - SWR, TanStack Query
- A plugin system for 3rd party extension
We are still in the early stages and greatly value your feedback and insights as we strive to build the best DX toolkit for developers.
Website: https://zenstack.dev/
Github: https://github.com/zenstackhq/zenstack
Discord: https://go.zenstack.dev/chat I am a big proponent of DSL. I like the approach of using the schema as the business model, with the authorization part added on through Prisma. However, how do you keep up with changes to Prisma? Specifically, how long can I expect to use a new feature released by Prisma in ZenStack? Thanks for the comments. Great point about Prisma compatibility/future-proof. First of all, ZenStack doesn't include or depend on any specific version of Prisma. You can freely use any version >=4.0.0. Our decision to base ZenStack on Prisma has two implications:
1. We need to keep up with the changes in Prisma schema (design-time)
2. We need to keep up with the changes in Prisma Client (runtime) For #1, Prisma's schema has been quite stable, at least since it reached V4. New features barely result in changes in the schema language. Quite often, they're guarded with the "previewFeatures" option, and that's pretty much it. For #2, at runtime, ZenStack enhances Prisma client by creating a transparent proxy around it and intercepting CRUD calls that need to be guarded/injected. Again, that part of runtime API has been very stable for quite a few releases, so as long as the semantics of those APIs don't change, nothing needs to be done for new Prisma releases. However, there're cases where we need to keep up with new features. E.g, the new release of Prisma Pulse added a new "subscribe" API for live changes subscription, and we're working on adding it into the scope of access control. That said, we need to (and do) keep a close eye on any schema/runtime changes that may require a timely follow-up. Hope this explains, and let me know if anything is unclear. clear enough, thanks. Do you support geo queries? currently only way to do it in prisma is using raw query? Hi, we don't change Prisma's query syntax as of today, so there's no native support for geo queries. We may start to extend the query syntax in the future, though. GIS query is a very popular ask. congrats on launch! q: how are you different from convex.dev? Thanks, and great you brought up convex.dev. I really like the product. Here're a few key differences: - ZenStack (MIT) and Prisma (Apache-2.0) are open-source, convex announced the plan to open up, but most of it seems still close-source. - Convex is a hosted service with a built-in relational database. ZenStack requires you to have a separately hosted database - the benefit is that you can use any supported database type and choose from many hosters. - Schema is optional for convex.dev, but mandatory for ZenStack. Not requiring a schema may speed up initial prototyping, but you'll almost always need one when your app goes beyond a toy, and adding it at a later stage may cause inconsistency. - Authorization is the user's responsibility when using convex - you define queries as JS/TS functions and should implement access control in those. ZenStack promotes modeling authorization declaratively inside data schema, so you can centralize them - easier to manage and evolve down the road. In short, convex.dev makes it easy for you to write serverless functions to access databases. ZenStack focuses first on providing an access-control-enabled database client and, based on that, gives you an automatic API layer. My apologies for the long answer. Just trying to cover every important aspect .