Juniper: Add EmptyQuery helper

[Guara92]

Is your feature request related to a problem? Please describe.
I have a schema with no query but with some mutation, with juniper 0.15 I'm forced to expose at least a query, otherwise the macro graphql_object panics.

Describe the solution you'd like
As already implemented with EmptyMutation and EmptySubscription, juniper should expose a EmptyQuery

Describe alternatives you've considered
expose a dummy query

[LegNeato]

Sounds like something we should add, would love a patch with a simple test / example and it added to the book!

[kunjee17]

If I remember correctly at least one query is required by GraphQL specification. In other frameworks it is like that only. But again I am telling from historic knowledge. Don't know the latest specs.

PS: But Dummy Query may be exposing juniper version can be added when Empty Query is that. It is good idea, but again don't know the specification part.

[Nocturem]

I ran into this issue where I had a rocket based graph server handling queries and mutations but had requests to extend it with subscriptions for a basic pub/sub event based view update on the front end.
with Rocket not yet supporting websockets I wrote the subscriptions on a seperate server on Actix and ended up with:

pub struct QueryRoot;

#[juniper::graphql_object(Context=Context)]
impl QueryRoot {

    pub fn a(_context: &Context) -> Option<String>{
        None
    }

}

just to get past the constraint.

[LegNeato]

Hmm, from https://spec.graphql.org/June2018/#sec-Root-Operation-Types it does appear that a query always needs to be defined.

[tyranron]

@LegNeato I guess we can leave that as an user code decision. Let's let the implementor to decide wherether he wants to apply with a spec or hack around it to satisfy its immediate needs. Though, it should be a huge WARNING in docs/book about that.

[tyranron]

Hmm, from https://spec.graphql.org/June2018/#sec-Root-Operation-Types it does appear that a query always needs to be defined.

A reason behind that, I think, is that despite the lack of user-defined queries in schema, there is still introspection stuff to be queried.

[tyranron]

As an another way around, we could define an EmptyQuery as a valid GraphQL Object, with a single dumb field. This way we don't hit the spec violation, while simultaneously satisfy the ergonomic needs.

[Guara92]

Hmm, from https://spec.graphql.org/June2018/#sec-Root-Operation-Types it does appear that a query always needs to be defined.

My fault, I was hoping that one of between Query, Mutation or Subscription was needed.
Perhaps, at this point is better to force the user to decide what should be the dumb object to expose, but if you prefer to add an helper with a dumb object I will try to implement it in my free time.