Support for subscriptions

[michael-infinitusai]

Are there any plans to support inspecting GQL subscriptions in addition to queries and mutations?

[warrenday]

At the moment I am adding mocking support but will take a look into subscriptions afterwards. It is on the roadmap but I felt it wasn't high priority.

[anthonydelage]

+1 for mocking, I can't find anything out there to do this and it'd be a huge help for what I'm currently working on.

[robertherber]

Great extension! So much easier and quicker than the network tab to get an overview for GraphQL data. But really missing the subscriptions, so a big +1 on this feature request :)

[warrenday]

It would be great to get an idea of how everyone is working with subscriptions at the moment.

Which libraries are you using? Do you communicate over websockets or another protocol?

The end goal of this feature is to be platform/protocol agnostic. But it would be great to get an idea of where to start. As not everyone is using Apollo. :)

[robertherber]

I'm currently using Apollo, but moving towards urql. Not sure how you've implemented the plugin but I suppose you can derive everything by just looking at the network requests, right? Or does the Client Library matter? :)

For the subscriptions I'm currently using websockets.

[warrenday]

@anthonydelage I thought you'd like to know mocking is now available through a desktop version of the app. If you're on mac you can use this to proxy/intercept traffic from any site where introspection is possible.

https://graphproxy.com

It's still in early beta but let me know what you think!

[robertherber]

@warrenday Hmm, I think I like this better as a browser extension on Desktop tbh.. :) Although an interesting prospect would be to have it on iPad/iPhone to look at requests inside apps since DevTools aren't available.

Just tried out the desktop app - and I still don't see subscriptions there - not sure if it's supposed to work there?

[warrenday]

Right now the main benefits of desktop are mocking and support for other apps/browsers. But if all you need is the inspector on chrome then that's the better choice :)

Subscriptions are the next major feature to add now this is out of the way. I'll update the thread when it's ready.

They'll be included to both the desktop and chrome plugin.

[anthonydelage]

Thanks for the update!

I'm having issues mocking some (but not all) GQL requests using the trial version. Is there a way to add auth to the introspector UI so I can mock internal APIs?

[warrenday]

You could add a query string ?token=1234 to the url if auth to your server is possible that way. There's currently no way of handling auth with headers (something I hadn't considered actually). Is there a particular auth method you need?

[anthonydelage]

We use a session-based cookie for auth. Would there be a way to pass that through the Chrome extension?

[warrenday]

I don't think it would be possible to route through the extension. But if headers are made available when running the introspection query tokens and cookies could be specified there. So i'll look at adding this.

[anthonydelage]

That'd be super helpful, thanks 👍

[OmarBurney]

Has there been any movement on support for subscriptions?

[brendanmorrell]

I would also very much like to see support for subscriptions. great library by the way.

[warrenday]

It is 100% in the roadmap. But I don't yet have a deadline.

[warrenday]

Closing as beta feature for subscriptions now added in 2.18.0. Let me know what you think and please raise any issues here on GitHub.

During beta the feature is disabled by default. Enable by selecting the subscription filter in the footer.

[brendanmorrell]

thanks for the quick turnaround! so, perhaps there is some setup that I am missing, but I do not seem to see any messages in the GQL network inspector despite their being there in the actual chrome network tab. screenshots attached show the subscription headers and messages. there are a lot of messages in the chrome network tab, but none in the extension unfortunately. I also notice that in the attached screenshot @warrenday posted above, the subscription seems to have had zero bytes travel over the wire, so wonder if it is not working there as well.

[dontsave]

love this feature but also having the issue of seeing 0 bytes over the wire, with events coming through but empty in the extension

[warrenday]

Could you share some details of what you see in the standard network tab Vs the GraphQL tab?

[brendanmorrell]

Basically, I have maybe 4 subscriptions running, and the WS section of the actual network inspector shows many messages going back and forth. I am highlighting one in the screenshot so you can see they aren't just keep alive messages, but instead that there is actual data being sent from the client and then data being returned. Despite this, gql inspector is showing zero kb transferred/no messages. Can send any more details you need. just let me know specifically what you'd like to see.

[brendanmorrell]

I also notice that it is picking up non-graphql subscriptions (see this image where it is grabbing a pub sub messaging subscription we use as well as webpack hot reloads (I am running our app locally in this screenshot)

[brendanmorrell]

if you need to look for yourself, the app in question is

https://app.realize.me/

you will need to create an account/sign in for the subscriptions to fire

[warrenday]

Thanks @brendanmorrell this is helpful. I'll update soon.

[warrenday]

@brendanmorrell I've looked at the main issue of requests not showing, and I've found the problem. Will release a fix shortly. It was purely that we were making strict assumptions on what shape the data should be in, which I've now made more flexible.

However, in the case of showing messages that are not GraphQL, this is more difficult to resolve.

For messages sent, it's not a problem, we can check the websocket payload and validate if it contains a graphql query. But for messages received, it's typically just JSON.

Even in the case of messages received over the graphql socket wss://api.realize.me/v1/graphql there are still lots of ping/pong messages, amongst other messages.

It's not possible to know which received messages are desired to be shown or not. Potentially we could add a filter input to give control over to the user.

[warrenday]

It does seem sensible to assume received messages will contain a "data" key, which is very common in most graphql servers. Here is the subscription view with the new updates.

[brendanmorrell]

Working great! Thanks @warrenday !

[jramiresbrito]

Hey guys, thanks for the great work on this extension and supporting the subscriptions. Unfortunately, I'm not able to see anything in subscriptions

Here's what I see in the network tab:

Any thoughts?

[warrenday]

Hey @anthonydelage that is unusual. Could you setup a basic example, repo or live service I can clone or visit.

I'll be able to debug and deploy a patch.

[anthonydelage]

I think you meant to tag jramiresbrito?

[warrenday]

Oops sorry! Thank you.

[jramiresbrito]

@warrenday we managed to discover the problem. In your pr you was expecting the endpoint to contain graphql, we as rails users, were naming it as cable (because of action-cable). We simply added the graphql prefix it and worked!

kudos to @tatosjb

[warrenday]

We should probably make this more explicit. Potentially could provide an input to change the target endpoint, or just target any endpoint until we see GraphQL data stream through.