Integrate GraphiQL explorer in Studio

[nirinchev]

As a first step, we should just open a studio window pointing to http://REALM-URL/graphql/explore/PATH and set the Authorization header to the access token.

[bigfish24]

@nirinchev @kraenhansen do you think we can do this before the launch next week as well?

[fealebenpae]

I think we could use this for https://github.com/realm/raas/issues/373.

[nirinchev]

@roberhofer can we prioritize this? I don't expect it'll be incredibly difficult, but not having it makes it hard for people to start with Cloud/GraphQL and has come up again and again.

[kraenhansen]

I have a branch laying around where I got pretty far on this. From a UX perspective it might be hard to tell the story on when to use the Realm Browser and when to use the GraphQL explorer.

[nirinchev]

I would say that the GraphQL explorer should be used when one wants to test out GraphQL queries not for exploring the data.

[kraenhansen]

I've rebased and pushed the branch https://github.com/realm/realm-studio/tree/kh/graphiql-editor - give it a spin if you have a moment at some point :) You open the explorer from the sidebar in the server administration window when you've selected a Realm.

I previously had subscriptions working as well (it could connect over websocket, but because https://github.com/apollographql/GraphiQL-Subscriptions-Fetcher is outdated I would need to fiddle a bit more (perhaps downgrade some of the other packages) to get that to work.

[roberhofer]

@nirinchev . @kraenhansen : I have no problem if you go ahead and implement this if this is lightweight and does not distract (too much) from the main Sprint goals. Especially since it seems almost done as per Kraen comment.

This reminds me of the following discussion: https://github.com/realm/raas/issues/1423
And this ticket: https://github.com/realm/raas/issues/1430
@nirinchev : Do you see this as equally important?

[nirinchev]

I believe all three are important. 1430 and this one relate to usability of the feature and how easy it is to get started. On cloud there's a lot of friction before you can get to the "aha" moment of using the GraphQL service and playing with the queries. This ticket will resolve that. Then 1430 will allow people to enable/disable some of the options without having to contact us. This is not something that many people have needed to do but it again reduces friction, especially for customers moving from self hosted to cloud.

Finally, 1423 is about optimizing how we run things internally - improving performance and potentially reducing costs. It will have little effect on the user experience but will affect the load on our servers.

If I had to sort them, I would go for this one, then 1430, then 1423, because that's the order both in terms of difficulty to implement (from easy to hard) and provided value to the customer (from high value to low).

[roberhofer]

Thanks for updating the docs as well with this.....