Briefly checked out the repo and demo, looks neat!
Bookmarked to keep a tab on for future reference.
I noticed that SQLAlchemy (an ORM) is part of the stack, and that “Postgres support” is in the roadmap. For people coming from Supabase and the like which is Postgres-first, some upfront clarification around which database is already supported, would be helpful.
You're right. Since I use SQLAlchemy, the core is already database agnostic. Swapping the connection string to Postgres actually works for most features right now.
I listed it as "Roadmap" only because I haven't finished the full end-to-end test suite for Postgres yet, and I wanted the default "Quick Start" to be a zero dependency SQLite setup. I am also working on native read/write splitting so that the system can properly leverage scaling architectures (like Amazon Aurora's single-writer / multi-reader clusters) out of the box.
I'll make sure to clarify in the docs that it's currently "experimental" rather than missing. Appreciate the feedback!
Keybase's Merkle approach is elegant for their use case (efficient proofs without revealing the full chain), but I went simpler with a linear chain because:
1. Audit trails are inherently sequential - they're ordered by time and typically read/written in order. Merkle trees shine for unordered data where you need efficient inclusion proofs.
2. Verification simplicity - with a linear chain, integrity verification is just "walk the sequence and check that each entry's previous_hash matches the prior entry's checksum." O(n) and dead simple.
3. Storage efficiency - each entry stores two SHA-256 hashes as strings. No tree overhead.
4. Regulatory fit - for GxP/CFR Part 11 compliance, the requirement is tamper detection, not zero-knowledge proofs. A linear chain detects any modification equally well.
That said, if I ever need selective verification (prove entry #500 is valid without transmitting the full chain), I'd revisit Merkle. The implementation is in src/snackbase/infrastructure/persistence/repositories/audit_log_repository.py if you're curious.
On the custom DSL:
This was the biggest architectural decision in SnackBase. Here's the honest breakdown:
Why not just use existing options?
>Approach: Python eval()
>>Why I didn't choose it: Security nightmare - can't safely let users store arbitrary code in the database
>Approach: CEL (Google's Common Expression Language)
>>Why I didn't choose it: Battle-tested, but heavy dependency and less control over semantics
>Approach: JEXL/JSONLogic
>>Why I didn't choose it: Another runtime to learn, harder to integrate with my macro system
>Approach: Pure JSON rules
>>Why I didn't choose it: Becomes unreadable for complex expressions
What drove the decision:
1. Permissions are database-storable - rules live as strings in the permissions table, editable via API and admin UI. I needed something safe to parse and evaluate at runtime.
2. Sandboxed execution - the DSL only exposes specific operations (==, in, @has_role(), etc.). No imports, no file access, no arbitrary code. Even if someone compromises the admin UI, they can only express logic within the vocabulary I provide.
3. Syntax for non-programmers - "@has_role('admin') and @owns_record()" is more approachable than Python lambdas when you're building permissions in a web UI.
4. Macro integration - the @ prefix ties into my SQL macro system, letting users define reusable business logic like @is_department_head() that executes database queries.
The trade-off:
It's 700+ lines of lexer/parser/evaluator code I have to maintain. Every edge case (null handling, type coercion, short-circuit evaluation) needs explicit test coverage. Debugging a failed rule means returning syntax errors at position X rather than a stack trace.
If I were starting fresh today, I'd give CEL harder consideration. But since permissions are a core differentiator for SnackBase, having full control over the semantics has been worth it—especially for field-level access control and the wildcard collection system.
Implementation files if you're interested in it:
- src/snackbase/core/rules/lexer.py - tokenizer
- src/snackbase/core/rules/parser.py - recursive descent → AST
- src/snackbase/core/rules/evaluator.py - async evaluation with short-circuiting
Hmm, I guess I did Keybase a disservice. They do use a chain per user, and also store each leaf in a global Merkle tree, and then also store new Merkle tree root hash in a blockchain (previously Bitcoin, currently Stellar).
Although I think there are ways to make Merkle trees append-only (see e.g. the Certificate Transparency protocol [1]). This should be a suitable audit log implementation, even if a bit more tricky. That said, it is probably an overkill for most scenarios!
As for the DSL, I think I’m more interested in the specific usecases for changing the rules in the runtime, considering that you have to change the code to e.g. add a new endpoint. Is it perhaps a common thing to tweak for each tenant or something?
Personally, I’m considering pgfga [2] for my next project, though the rules will probably live in the codebase for now :-)
So much of new open source code feels like folks just sharing their Claude tokens with each other, after the fact. I’m having fun just gluing stuff together with my Claude tokens.
It’s unfortunate that so many of these projects just whither away, blasts of commits with hundreds of files but nothing changed in months.
I completely get the fatigue. We’re seeing a lot of "one-shot" projects right now that look great for a week and then die because there was no actual design behind the prompt.
For SnackBase, I actually spent the majority of my time on the architecture and compliance logic rather than just generating boilerplate.
Compliance Core> Getting the immutable hash-chain for audit logs to work correctly with async SQLAlchemy while ensuring it doesn't kill database performance is something I had to iterate on manually. AI is great at writing a function, but it's notoriously bad at keeping a consistent "Clean Architecture" across hundreds of files without a human steering the ship.
Custom DSL> I built the DSL specifically to solve the maintenance problem you mentioned. It acts as a single source of truth for the DB, API, and UI. This makes the project much easier to maintain long-term because you aren't manually updating three different layers every time a schema changes.
I built this because I actually need it for my work in Life sciences domain. My goal isn't a blast of commits but a rock-solid foundation that can survive a GxP audit.
Honestly, I picked AGPL mainly to prevent "cloud wrapping". I definitely don't intend for your business logic to get infected by it.
In my view, the custom hooks and schemas are "content/configuration" rather than derivative works, but I get that running in-process makes that legally murky.
To clear that up, I'll add a specific linking exception (like the Classpath Exception) to explicitly exempt user-defined hooks from the license. I want this to be safe for commercial teams to self-host, just not safe for cloud providers to resell.
This looks fantastic. I’m working on a project I wrote in plain Flask. Wish I had seen this previously. I spent an ungodly amount of time on organizations, users, permissions, 2fa, password reset, organization invites.
Thank you! That is exactly the "boilerplate tax" I’m trying to eliminate.
I think every developer has a story about spending months on those exact features. Organizations, RBAC, Auth, etc. before they ever get to write a single line of code for the actual business problem they were trying to solve.
Since you are coming from plain Flask, you would likely find the SnackBase architecture very familiar. I chose FastAPI and Pydantic specifically to give that same "get out of my way" developer experience, but with the compliance-first features (like the immutable audit logs) baked into the core so you don't have to think about them.
If you ever have a chance to play with the demo or the repo, I’d love to know if there are any specific missing pieces from your Flask implementation that you think should be in SnackBase.
Thanks for the reply. At this point I am so deep down the rabbit hole of code and tests (completed) switching frameworks would put me back another couple months. I'm focused on business logic and growing users.
Though shameless plug, if you're interesting in the stock market or crypto here is my app. It's basically a diary to document your thoughts on trades or daily market activity. Think Notion for trading. It supports ticker symbols with TradingView widgets, full Markdown, and some convenience features. Would love feedback if that interests you.
For a moment I thought I was looking at the Supabase site. There is a lightning icon within the landing page too. Hope you dont get their lawyers attention.
That's actually just a standard component from Mintlify, which I'm using for the documentation. It’s a very popular framework for dev tools right now, so a lot of sites end up sharing the same standard icon set like "Zap" icon in this case.
I promise I’m much more focused on the "Compliance & Python Hooks" logic under the hood than icon design. I'm glad to hear the documentation looks professional, though Mintlify really does a lot of the heavy lifting there!
Briefly checked out the repo and demo, looks neat!
Bookmarked to keep a tab on for future reference.
I noticed that SQLAlchemy (an ORM) is part of the stack, and that “Postgres support” is in the roadmap. For people coming from Supabase and the like which is Postgres-first, some upfront clarification around which database is already supported, would be helpful.
Thanks for the kind words and the bookmark!
You're right. Since I use SQLAlchemy, the core is already database agnostic. Swapping the connection string to Postgres actually works for most features right now.
I listed it as "Roadmap" only because I haven't finished the full end-to-end test suite for Postgres yet, and I wanted the default "Quick Start" to be a zero dependency SQLite setup. I am also working on native read/write splitting so that the system can properly leverage scaling architectures (like Amazon Aurora's single-writer / multi-reader clusters) out of the box.
I'll make sure to clarify in the docs that it's currently "experimental" rather than missing. Appreciate the feedback!
This is really cool. I probably won’t be using it directly, but will definitely study some architecture and implementation decisions.
> Compliance Core: Immutable audit logs with blockchain-style hashing (prev_hash) for integrity.
Had this in the back of my mind for a while now, too. In terms of prior art, Keybase had been doing something similar, but with Merkle trees.
> I’d love feedback on the DSL implementation
Could you tell in a bit more detail why you decided to go with your own DSL here? :)
Great question!
Keybase's Merkle approach is elegant for their use case (efficient proofs without revealing the full chain), but I went simpler with a linear chain because:
1. Audit trails are inherently sequential - they're ordered by time and typically read/written in order. Merkle trees shine for unordered data where you need efficient inclusion proofs. 2. Verification simplicity - with a linear chain, integrity verification is just "walk the sequence and check that each entry's previous_hash matches the prior entry's checksum." O(n) and dead simple. 3. Storage efficiency - each entry stores two SHA-256 hashes as strings. No tree overhead. 4. Regulatory fit - for GxP/CFR Part 11 compliance, the requirement is tamper detection, not zero-knowledge proofs. A linear chain detects any modification equally well.
That said, if I ever need selective verification (prove entry #500 is valid without transmitting the full chain), I'd revisit Merkle. The implementation is in src/snackbase/infrastructure/persistence/repositories/audit_log_repository.py if you're curious.
On the custom DSL: This was the biggest architectural decision in SnackBase. Here's the honest breakdown:
Why not just use existing options? >Approach: Python eval() >>Why I didn't choose it: Security nightmare - can't safely let users store arbitrary code in the database
>Approach: CEL (Google's Common Expression Language) >>Why I didn't choose it: Battle-tested, but heavy dependency and less control over semantics
>Approach: JEXL/JSONLogic >>Why I didn't choose it: Another runtime to learn, harder to integrate with my macro system
>Approach: Pure JSON rules >>Why I didn't choose it: Becomes unreadable for complex expressions
What drove the decision:
1. Permissions are database-storable - rules live as strings in the permissions table, editable via API and admin UI. I needed something safe to parse and evaluate at runtime. 2. Sandboxed execution - the DSL only exposes specific operations (==, in, @has_role(), etc.). No imports, no file access, no arbitrary code. Even if someone compromises the admin UI, they can only express logic within the vocabulary I provide. 3. Syntax for non-programmers - "@has_role('admin') and @owns_record()" is more approachable than Python lambdas when you're building permissions in a web UI. 4. Macro integration - the @ prefix ties into my SQL macro system, letting users define reusable business logic like @is_department_head() that executes database queries.
The trade-off:
It's 700+ lines of lexer/parser/evaluator code I have to maintain. Every edge case (null handling, type coercion, short-circuit evaluation) needs explicit test coverage. Debugging a failed rule means returning syntax errors at position X rather than a stack trace.
If I were starting fresh today, I'd give CEL harder consideration. But since permissions are a core differentiator for SnackBase, having full control over the semantics has been worth it—especially for field-level access control and the wildcard collection system.
Implementation files if you're interested in it: - src/snackbase/core/rules/lexer.py - tokenizer - src/snackbase/core/rules/parser.py - recursive descent → AST - src/snackbase/core/rules/evaluator.py - async evaluation with short-circuiting
Happy to go deeper on any of this!
Hmm, I guess I did Keybase a disservice. They do use a chain per user, and also store each leaf in a global Merkle tree, and then also store new Merkle tree root hash in a blockchain (previously Bitcoin, currently Stellar).
Although I think there are ways to make Merkle trees append-only (see e.g. the Certificate Transparency protocol [1]). This should be a suitable audit log implementation, even if a bit more tricky. That said, it is probably an overkill for most scenarios!
[1]: 2.1.2. Merkle Consistency Proofs: https://datatracker.ietf.org/doc/html/rfc6962#section-2.1.2
As for the DSL, I think I’m more interested in the specific usecases for changing the rules in the runtime, considering that you have to change the code to e.g. add a new endpoint. Is it perhaps a common thing to tweak for each tenant or something?
Personally, I’m considering pgfga [2] for my next project, though the rules will probably live in the codebase for now :-)
[2]: https://github.com/isaacharrisholt/pgfga
So much of new open source code feels like folks just sharing their Claude tokens with each other, after the fact. I’m having fun just gluing stuff together with my Claude tokens.
It’s unfortunate that so many of these projects just whither away, blasts of commits with hundreds of files but nothing changed in months.
I completely get the fatigue. We’re seeing a lot of "one-shot" projects right now that look great for a week and then die because there was no actual design behind the prompt.
For SnackBase, I actually spent the majority of my time on the architecture and compliance logic rather than just generating boilerplate.
Compliance Core> Getting the immutable hash-chain for audit logs to work correctly with async SQLAlchemy while ensuring it doesn't kill database performance is something I had to iterate on manually. AI is great at writing a function, but it's notoriously bad at keeping a consistent "Clean Architecture" across hundreds of files without a human steering the ship.
Custom DSL> I built the DSL specifically to solve the maintenance problem you mentioned. It acts as a single source of truth for the DB, API, and UI. This makes the project much easier to maintain long-term because you aren't manually updating three different layers every time a schema changes.
I built this because I actually need it for my work in Life sciences domain. My goal isn't a blast of commits but a rock-solid foundation that can survive a GxP audit.
I'm not sure the AGPL license is a good choice for this.
None of Django, Rails, Pocketbase or Supabase, which I think count as competitors, use AGPL.
Unless you can clarify that custom hooks and schemas are outside of the AGPL license, SnackBase may be a non-starter for commercial use.
Fair point.
Honestly, I picked AGPL mainly to prevent "cloud wrapping". I definitely don't intend for your business logic to get infected by it.
In my view, the custom hooks and schemas are "content/configuration" rather than derivative works, but I get that running in-process makes that legally murky.
To clear that up, I'll add a specific linking exception (like the Classpath Exception) to explicitly exempt user-defined hooks from the license. I want this to be safe for commercial teams to self-host, just not safe for cloud providers to resell.
This looks fantastic. I’m working on a project I wrote in plain Flask. Wish I had seen this previously. I spent an ungodly amount of time on organizations, users, permissions, 2fa, password reset, organization invites.
Thank you! That is exactly the "boilerplate tax" I’m trying to eliminate.
I think every developer has a story about spending months on those exact features. Organizations, RBAC, Auth, etc. before they ever get to write a single line of code for the actual business problem they were trying to solve.
Since you are coming from plain Flask, you would likely find the SnackBase architecture very familiar. I chose FastAPI and Pydantic specifically to give that same "get out of my way" developer experience, but with the compliance-first features (like the immutable audit logs) baked into the core so you don't have to think about them.
If you ever have a chance to play with the demo or the repo, I’d love to know if there are any specific missing pieces from your Flask implementation that you think should be in SnackBase.
Thanks for the reply. At this point I am so deep down the rabbit hole of code and tests (completed) switching frameworks would put me back another couple months. I'm focused on business logic and growing users.
Though shameless plug, if you're interesting in the stock market or crypto here is my app. It's basically a diary to document your thoughts on trades or daily market activity. Think Notion for trading. It supports ticker symbols with TradingView widgets, full Markdown, and some convenience features. Would love feedback if that interests you.
https://marketdiary.app
For a moment I thought I was looking at the Supabase site. There is a lightning icon within the landing page too. Hope you dont get their lawyers attention.
Haha, good eye!
That's actually just a standard component from Mintlify, which I'm using for the documentation. It’s a very popular framework for dev tools right now, so a lot of sites end up sharing the same standard icon set like "Zap" icon in this case.
I promise I’m much more focused on the "Compliance & Python Hooks" logic under the hood than icon design. I'm glad to hear the documentation looks professional, though Mintlify really does a lot of the heavy lifting there!