From what I gather, there is currently no native way of enforcing a namespace / multi-tenancy aspect that’s required for any modern SaaS project.
Is there a way to introduce middleware into the Dgraph server that would allow us to wrap / constraint any query / mutation by assessing for example a JWT auth token and wrapping the incoming query with a
That post is literally a year old… Any updates since then?
And what about my question, is there a way to manually introduce a middleware until the native ACL is ready?
There is an internal paper with update on this, the only update I can pass is that it has already started some work on this. But there is no date, as there are many other issues to be worked on.
I have no experience with docker, but I was wondering if a docker farm could do the job until then. Like, one docker for each customer database, each one listening on a different port, and having some logic on app login to redirect the connection for each user. This could be a fix for a while (on a small scenario?).
If that can be done, would you have any docs or good practical examples to share of how to do that?
In theory, yes can be done. In practical, too way complex to deal and I don’t think has examples for this available anywhere. Cuz is unusual this way of thinking tenancy usage.
And we can not spend time on this to create an example, as there are plans already for ACLs.
But, instead of this, you could create a Graph Structure inside Dgraph to simulate DBs. Like graph branches. Each branch your code would consider as a Client DB. You’d sharing the same DB for all costumers.
A Graph DB is a blank slate and you can painting as you want.