@hlship Thanks, I was having trouble understanding it too! I deleted my target folder and as if by magic, the issue went away

I always assumed that I could do a mutation and a query at the same time, but it turns out that’s not true 😞 Seems like a GraphQL constrain — you can do multiple mutations, multiple queries, but not mutations and queries.

@orestis You can't do multiple mutations or queries at the same time. Every request must specify exactly one operation, either implicit by having only one operation or explicit by sending an operation name.

Conceptually, a mutation is just a query where the top-level field has special treatment. The fields returned by the mutation are just query fields. Essentially, a mutation is a write followed by a read.

Really? What’s that talk then about queries been (potentially) done in parallel while mutations being sequential? This is what got me confused.

Ah, so perhaps I misunderstood what you meant by multiple. Apologies. You can have a single mutation execute multiple mutation fields and that does need to be executed serially. In that sense you are correct that a request cannot be for both a mutation and a query at once.

This is a total hack but you could, technically, have mutation fields that don't mutate anything, which would behave the same as query fields (aside from serial/parallel execution).

Aaah right, I think that the eliding of the top level “constructs” (QueryRoot, MutationRoot) can be confusing.

Agreed

Why do you want to run multiple query fields and mutation fields in one request?

I thought I was able to do something like this:

{ 
  mutation UpdatePartOfThing() { 
    update_thing(...)
  }
  query FetchDependentThang() {
    thang_by_id(...)
  }
}

And my expectation was that UpdatePartOfThing would execute, then FetchDependentThang would execute.

This way if I know about dependencies already, I wouldn’t have to issue a second network request.

I see. So the typical way this is handled is by having update_thing return an object of dependent_thangs

A mutation is a write followed by a read, the return fields of the mutation should be reconciled with the data you already have

Yes, that would be the way to do it.

In some sense GraphQL exposes quite heavily the fact that the way we’ve been building SPAs for quite some time now is very ad-hoc — the fact that it works best with a client-side database means that noone has been using a proper one for quite some time.

I mean “reconcile with the data you already have” is not a trivial thing to write.

Sometimes I just want to stop doing all that SPA stuff and issue GraphQL queries server-side, then just render a whole bunch of HTML 🙂

It's not at all. That's why writing a 99% correct stateful GraphQL client is incredibly hard.

Perfectly valid technique 😉 GraphQL isn't only for browser/mobile clients.

@hlship If it's not too much trouble, would it be possible to get a snapshot release for your type system directive PR, now that it's merged? https://github.com/walmartlabs/lacinia/pull/236

I believe Apollo has an extension where you send up a series of GraphQL query documents that are executed serially; the first document can do mutations, the later ones can do queries. We don't support this currently, though it might be possible to accomplish this by injecting an interceptor.

Batched queries? That's a good idea for @orestis. ApolloClient can batch queries (and mutations and maybe subscriptions) and send them to the server in a JSON array. I've used Lacinia (plain, not Pedestal) with this.