Do you have different permissions for each user? I haven’t seen any authorization systems out there really beyond things like a single permission without qualification, e.g. isAdmin kinds of permissions. We pass a user object into the context, but we don’t include the associated authorization, as it would be too big to put into our middleware. A given user might have around 7000 permissions, as a permission might be “can perform this particular action on this particular entity”: we might need to let them view user 359’s status but not view user 598’s status, and we might need to allow them to view user 598’s email address but not user 359’s email address… that’s not our use-case, but things along those lines.
The reason I would jump to “impossible” or at the very least perpetually head-scratching, is that we might have situations like the following, where the user-requesting has access to Beth’s email, like so
query {
user {
friends(name: "Beth") {
id
email
}
}
}
we’d be tempted to say that the resolver for Beth’s properties like “email” be based on the allowance of the ctx.userId user, but consider the following:
query {
user {
friends(name: "Joe") {
id
email
friends(name: "Beth") {
id
email
}
}
}
}
… what if Joe can’t see Beth’s email but the ctx.user.id can… should we show Beth’s email? I think the answer might be more like “it depends” or “maybe”. It confuses me further to determine what we should do in this situation assuming we’ve got the above-two worked out:
query {
users(name: "Joe") {
friends(id: $theUserIdFromOurContext) {
id
email
friends(name: "Beth") {
id
email
}
}
}
}
Maybe we need to take the intersection of the immediate parent and the ctx.user.id requesting it? Maybe not? Maybe we have to consider all parents?
This is just a toy example, but things along these lines does come up when we have administrators that can administer other users’ accounts.
Thanks for this info. It seems like with 7000 permissions, there’s no way to get them all into an API call, and they’d have to be determined on the server regardless of db layer. Is that a reasonable way of looking at this by any chance?
Most people that say that have no clue what GraphQL should be used for. I today’s world where one is rather leaning towards decentralized approach and microservices I hardly see use cases where queries across different types of databases need to be joined.
We have the same setup, mainly for scaling purposes. Our Meteor FE can take over 1000 concurrent users whereas the Meteor BE server can take 6-7 depending on the complexity of the tasks on the smallest AWS Fargate server.
Just as a point of reference I use GraphQL to join queries from my Mongo user accounts table, created by Meteor accounts, to queries from my main PostGres database.
Hey, @dandv! Likewise great hearing from you. Thanks for posting your experiences, which I had totally missed.
Like you I was also a massive Meteor developer advocate for many years. I think these report backs are very interesting and could be insightful for current Meteor development too.
I have some strong (constructive) opinions about these topics which I’d like to post, but ideally I need to read through the other posts about “Meteor 2” etc first. Let’s see.
Anyways great hearing from you and best wishes for all your future projects.
I’ve posted it somewhere but basically they are connected on ports 3000 and 4000. The problem is communicating from the Backend to Frontend, we’re using a package called sendStreamMsg so the Backend is informing the Frontend on events happening and we can give feedback to the user via progress bars and modals. That’s very important on long running tasks which we have quite a lot as we handle DNA data.