A question on the business logic here: A tag can be private (Tag.isPublic !== true) but shared, hence the need for point 3? If that’s not the case, then the query you have would accomplish it.
Filters on the count of an edge can be done in a custom query or in DQL. Or you can use the query you have and do these checks from your app.
Yes, could be private and still shared individually.
Trying to keep extra logic out of app, i am already dealing with a lot there and just want to pass a query to build a select form without having to also pass a function to filter the results.
Probably will just build a one-off custom query for this within a lambda to keep auth logic. As we already have an extensive schema with a lot of queries and mutations, I don’t think this is the best way going forward for every unique spin off when the API could be made a little more flexible to handle so much more without the extra work on clients and custom queries. For instance, what if I want to have the rest of the GraphQL API generated filters available with my custom queryPrivateTags query? Then I have to also rework all of that logic as well. And then what if I need a one-off such as all all private group tags with my actual group based ACL logic. Then I will have to build another custom query with tha additional work of adding the same filters. And this access logic and query is not limited to just tags, but also other types such as Contacts, Events, Categories, Tasks, etc. Then I will need a custom queryPrivate* for each type. You see where this leads… a lot of redundant work.