[HN Gopher] Ayb: A multi-tenant database that helps you own your...
___________________________________________________________________
Ayb: A multi-tenant database that helps you own your data
Author : gagejustins
Score : 52 points
Date : 2023-06-26 11:47 UTC (11 hours ago)
(HTM) web link (blog.marcua.net)
(TXT) w3m dump (blog.marcua.net)
| gavinray wrote:
| 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?
|
| 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?
|
| Not trying to be critical but a few questions:
|
| - 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"?
|
| - 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.
|
| - 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.
| https://calcite.apache.org/avatica/docs/json_reference.html
| stan_kirdey wrote:
| 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...
|
| But nope.
| tensor wrote:
| 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.
| marcua wrote:
| (author)
|
| It's so helpful to read the headline through your eyes! While I
| can't change this title on HN, I'll tone down/relegate the
| multi-tenant bits to the features section in the future. Thank
| you for this feedback!
| ubertaco wrote:
| So, you've built a CLI client and an HTTP API server that wraps
| around SQLite.
|
| 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?
|
| 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".
|
| (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)
| marcua wrote:
| (Hi there! Surprised author here---I hadn't realized this made
| its way to the front page)
|
| I love your questions because they get to the heart of how to
| make this stuff easier for more people, and in transparency, I
| only have some of the answers! :)
|
| > What's the permissions/ACL model, and how do you keep that
| from getting too confusing for the average person? (You asked a
| lot more here, but I think this is the root of this question)
| The admittedly naive permissions/ACL model I'm
| envisioning/speccing now is at the database level, similar to
| GitHub at the repository level. If you create a database, you
| can add read/write and read-only collaborators, one of which is
| `public`/`world`, which would make the database accessible to
| unauthenticated users.
|
| Your questions around table slices/views are excellent, and in
| the model I'm proposing, ayb won't be able to help. The model
| I'm proposing will be good enough for "here's my dataset, and
| you can build on it" or "I spun up a project and have a private
| DB that my webapp is gating" but not "I want user X to have
| access to row Y." Row-based auth would thus be pushed into the
| application layer, which seems to come with the territory with
| SQLite as best I can tell. To contrast, something like Supabase
| is able to provide both a database and row-based auth because
| Postgres provides better support natively, and Supabase then
| made it easy to add common auth providers.
|
| > 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 If the goal is to write/learn SQL, I agree that ayb
| offers nothing on top of SQLite. As SQLite is the database and
| ayb is the database management system, the things ayb makes
| simpler are on the "management system" side --- without ayb,
| it's hard to create a new one, it's hard to control access, and
| it's hard to access one from a web application. You're right
| that by that definition, it's more developer-friendly than
| power user-friendly, and I hope we can do better with future
| iterations.
| ubertaco wrote:
| Thanks for the candid answers -- sounds like this hit HN a
| bit earlier than you would've planned, which I realize can
| create a weird awkward tension between planned goals and
| current state and HNers' expectations.
|
| I think it's cool that you're trying to tackle adding
| simplicity to managing a multi-user (if not actually multi-
| tenant, given the lack of row-level permissions management)
| SQL DB. My suggestion then would be to refine your pitch so
| that it matches your project a bit better -- that way you
| avoid the problem of people disappointed to find it doesn't
| do something they expected (but which it was never trying to
| do).
| AndrewKemendo wrote:
| I really love this project and exactly what it's trying to do.
|
| There's many things like this that I wish existed that make
| prototyping easier and faster and infrastructure a little bit
| nicer to use.
|
| 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.
|
| My question to the author is have you figured out how to prevent
| that?
| marcua wrote:
| (author here)
|
| Thank you for your kind words and the great question!
|
| To your compliment: I agree ayb can help with easier
| prototyping today.
|
| To your concern: I would not use ayb in a production setting
| today. To be explicit, while the roadmap [1] is long, I think
| that ayb will be useful in production once we've implemented a
| v1 of auth, permissions, persistence beyond the node, and
| isolation.
|
| To "how to prevent that," here's a rough outline that I'm open
| to feedback on: - Implement the v1 features
| above - Host a public instance (and encourage others
| to, not trying to empire-build) - Build some fun
| applications on top of the public instance myself to stress
| test it - Encourage others to do the same and/or run
| some "learn SQL" classes to better understand where beginners
| get stuck and address those issues
|
| Thank you again for your interest! Please share any feedback!
|
| [1] https://github.com/marcua/ayb#roadmap
| AndrewKemendo wrote:
| I mean the fact that you have, what looks to my senior
| engineering manager eyes as, a coherent technical roadmap,
| puts you further along than almost every hobby level
| prototype tool.
|
| Excited to see where it goes and if there's an associated
| space here for integrating some form of environment
| management to wrap up all those other loose ends around dev.
| dynamorando wrote:
| Not to steal the light from this release, which looks fantastic,
| but this looks similar to an approach I have been working on:
| https://github.com/dynamoRando/treaty-mono-repo
| marcua wrote:
| Fascinating! It's great to see lots of people working on this
| problem. If you have any running examples, I'd love to see them
| to understand how the different actors in your documentation
| work. Thank you for sharing this!
| dynamorando wrote:
| Hello!
|
| There is a very long walk-thru in the Demo.md file -
|
| https://github.com/dynamoRando/treaty-mono-
| repo/blob/main/tr...
|
| Since this has been a hobby project I haven't yet published
| any public docker images, but there are docker files that you
| can pull from the repo and build if you wish.
___________________________________________________________________
(page generated 2023-06-26 23:02 UTC)