My read is that this is a service to make it easy to setup and share databases. You might want to simplify your headline, as when I saw "multi-tenant database" I clicked expecting to see a database system that makes it easier to build multi-tenant application patterns. E.g. a system where each "customer" has it's own database, but all databases share either the entire schema or a common subset.
So, you've built a CLI client and an HTTP API server that wraps around SQLite.<p>How does this actually work in the real world, though? Like, if I run an ayb node somewhere, do I then share out individual tables (or slices of tables, or views) to other apps in an OAuth kind of way? How does that happen? What's the permissions/ACL model, and how do you keep that from getting too confusing for the average person? And even if you can tackle the connectivity and auth problems, how can the "requesting" app know what schema to expect?<p>And while we're on the subject of the "difficulty floor" here, what makes your CLI wrapper that accepts SQL (or your HTTP API that accepts SQL) any easier for average users to consume than just installing SQLite themselves and running the exact same SQL? It seems like you're trying to target average users in terms of your ambitions, but your approach to get there is _extremely_ developer-oriented, which is one step _beyond_ "power user".<p>(I ask these questions not because I think you have a stupid idea, but because I'm hoping to learn that you have good answers for them -- I really want to see a world where users own their data and just "permit"/"deny" access to it, rather than having third parties own data about users)
I really love this project and exactly what it’s trying to do.<p>There’s many things like this that I wish existed that make prototyping easier and faster and infrastructure a little bit nicer to use.<p>My concern is that because it’s a Nerfed version of the most basic/powerful/flexible implementation that is expected for a RESTful LAMP/SOAP application, it’s not gonna find its way into production applications, and as a result is going to be stuck as kind of prototyping tool.<p>My question to the author is have you figured out how to prevent that?
I'm not sure if I fully understand what exactly "Ayb" is. Maybe a diagram/visual image would help to clarify the flow and architecture?<p>From the example it seems like it is a CLI that will create SQLite databases, and then runs an HTTP server that passes through queries to the underlying database?<p>Not trying to be critical but a few questions:<p>- What is the appeal of a CLI for creating SQLite databases when you can create one by making a new file like "my_db.sqlite3"?<p>- If it's meant to make the DB setup process easier for students, how does it create and run Postgres or MySQL etc? It seems like you have to already have a running DB server and then configure the credentials, versus something like starting a server using Docker and auto-wiring the credentials.<p>- For exposing an HTTP API on top of databases, as a heads-up there are tools like Apache Avatica which let you query any DB that has a JDBC driver over HTTP, JDBC, and gRPC. <a href="https://calcite.apache.org/avatica/docs/json_reference.html" rel="nofollow noreferrer">https://calcite.apache.org/avatica/docs/json_reference.html</a>
Not to steal the light from this release, which looks fantastic, but this looks similar to an approach I have been working on: <a href="https://github.com/dynamoRando/treaty-mono-repo">https://github.com/dynamoRando/treaty-mono-repo</a>
I think we need more go/rust HTTP wrappers around SQLite<p>Will keep an eye on this one, could definitely see myself using it once the access control stuff is sorted<p>we sorely need a go/rust postGREST equiv. for SQLite.<p>Until then, pocketbase, while perhaps heavyweight, might be the best option
I thought that multi-tenant means that the project offers solutions to multi-tenancy problems like noisy neighbor, fair resource allocation among tenants, fault-tolerance, access control...<p>But nope.