Clojurians Log v2

Why do you need to replace variables ? They are first class in graphql, you send them separately.

GraphQL is pretty simple in itself. And if you move to subscriptions a lot of libraries are breaking. Not Lacinia 😀.

But it would be nice, not that hard to build, and usefull to do generative tests on a GraphQL endpoint using introspection. I'm not aware something like it already exists.

@kwladyka if you are interposing strings, you're doing it wrong. See https://graphql.org/learn/queries/#variables

5 years GraphQL 🎆 🍰 https://youtu.be/s8meG38iZAM

https://graphql.org/learn/queries/#operation-name what is the point of operations name while response doesn’t use them in data structure?

Is :operationName useful? I see libraries generate them for request.

{:operationName "get_shops",
 :query "query get_shops($uuid: String!) {\n  shop(uuid: $uuid) {\n    uuid\n    name\n    engine\n    config\n  }\n}",
 :variables {"uuid" "00000000-0000-0000-0000-000000000000"}}

Is it happening only with multiple queries? why?

it sounds like make this more complex

your query can define multiple operations, and in your request you can specify which one you want to call

The operation name is a meaningful and explicit name for your operation. It is only required in multi-operation documents, but its use is encouraged because it is very helpful for debugging and server-side logging. When something goes wrong (you see errors either in your network logs, or in the logs of your GraphQL server) it is easier to identify a query in your codebase by name instead of trying to decipher the contents

sure, but it seems to be strange it doesn’t return response with my operation name when I use 1 query. Just curious why do this for multiple queries, but not for 1? It make extra work for parsing.

you can do it for one query as well, if you decide you want to do something with that information in your graphql server

i don’t think it really adds much overhead to the parsing

To be honest, I don't see the need for operationName myself, but it is part of the spec.

Feels like Facebook UI guys wanted to have one big document with all the possible queries/mutations they would need in one place.

But that's not, IMO, the best way to use GraphQL.

It makes slightly more sense if Facebook internally uses something like server-stored queries.

Which, BTW, are easy to implement, but hard to do properly in a fully generic, pluggable way, which is why it's not part of lacinia-pedestal (at least, not yet).

But with the way Lacinia operates, operationName adds some unwanted complications to server-stored queries.