graphql 2022-01-07 | Slack Archive

Thanks @hlship - I will try next week to run them through our CI.

I'm looking at com.walmartlabs.lacinia.pedestal2/query-parser-interceptor in lacinia-pedestal. Does that mean that if our frontend runs the same 20 queries again and again, lacinia will cache them in their parsed form? Is the default cache key just the string representation of the query?

hlship17:01:40

Yes, that's correct. The key is on the query document but not the variables (or the combination of query document and operation name). In our application, we tend to see about 100 distinct queries from our clients. Parsing doesn't make a significant difference in any single request (perhaps a couple of ms) but in the aggregate, it can be noticeable, especially in terms of reduced churn of short lived objects for the GC.

Daniel Craig16:01:09

I'm a little new to Lacinia but I was able to use the tutorial to guide me to create a graphql service that works great over http. I want to start using websockets and subscriptions, but I'm not sure whether my app is set up correctly. When I want to GET , I get a 404 response. How can I get my graphql-ws endpoint working?

Daniel Craig17:01:59

https://lacinia-pedestal.readthedocs.io/en/latest/subscriptions.html

Daniel Craig17:01:08

I think I might have figured it out

Daniel Craig17:01:04

Maybe I spoke too soon.. I'm still seeing errors

Lennart Buit18:01:13

Web sockets usually have ws:// or wss:// as protocol

gklijs18:01:31

The easiest to validate is probably with GraphiQL https://github.com/walmartlabs/lacinia-pedestal#graphiql it's a specific protocol over websockets, so not easily tested with just curl or something alike.

Lennart Buit19:01:16

I can also recommend the chrome devtools themselves. If you click on a ws connection, you'll see the messages sent over it

2022-01-07

Channels