Thanks @amaster507. Yeah, as I mentioned, you can flip it if that’s the sole filter to query, but if you are trying to do richer filtering with multiple filters, you’re out of luck it seems.
Example: List all nodeX’es that have related nodeY’s = 123 and related nodeZ’s = 456 and…
In other words: rich relationship querying and mutations.
Which is what I thought I was getting when turning down tried-and-true SQL-based GraphQL APIs and coming to a graph database-based GraphQL API. @JatinDevDG do you have a rough ETA for this or no? Thanks.
For what it’s worth, I completely understand that new services have to work through a backlog of features. But in this particular case, no matter when the feature comes, it now makes me super nervous to think that a graph database-based GraphQL API that is trying to separate itself from competitors that use more traditional, popular databases has launched without this kind of (fundamental?) node/edge relationship management as a fundamental core part of its offering?
I could be a dummy, but 'm not sure of the benefit of graph databases vs SQL competitors in this current GraphQL scenario? Despite Slash’s usage of a graph db, it seems to be at a big disadvantage, not an advantage? In other words, the rich node/edge relationship benefits promised are not the benefits delivered?
Add this to the more proprietary-than-others semi-lock-in of the Dgraph database and I think I’ve lost confidence that this is the right choice of team and technology to hitch my wagons to at this moment. Turns out the risk is higher than anticipated. And I’m unable to easily accomplish an important piece of my app. I do like many other things about Slash, but I guess I have to reexamine and reconsider options…
Thanks everyone for the help