Fork me on GitHub
#graphql
<
2020-03-13
>
orestis05:03:20

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

gklijs07:03:02

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

👍 1
gklijs07:03:28

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.

oliy08:03:33

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

kwladyka21:03:17

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

kwladyka21:03:04

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"}}

kwladyka21:03:14

Is it happening only with multiple queries? why?

kwladyka21:03:32

it sounds like make this more complex

chrisulloa21:03:52

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

chrisulloa21:03:24

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
in that same page you linked

kwladyka21:03:56

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.

chrisulloa21:03:59

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

chrisulloa21:03:02

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

hlship22:03:36

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

hlship22:03:33

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

hlship22:03:01

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

hlship22:03:32

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

hlship22:03:02

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).

hlship22:03:51

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