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!
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.
> 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? :)
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!
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.
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.