Add a graphical representation of the graphs

[jferrettiboke]

My proposal is adding a tab to see a graphical representation of all graphs linked between them. Something like APIs-guru/graphql-voyager.

What do you think?

[asiandrummer]

Hi @jferrettiboke - although the graph looks super cool, I'm not sure if adding a tab with this graph will benefit GraphiQL. If users would use the interactive graph to learn about the schema, I think having another browser tab with graphql-voyager would do. Is there another use case that I'm failing to consider maybe?

Also I'm concerned of the performance implication of adding a tab for this. I've tried the live demo with Github schema and the experience felt laggy.

[jferrettiboke]

Hi @asiandrummer.

IMHO, I think it is worth. Here, some of my points of view.

1. Developers can have another perspective on top of a graphical structure. Remember that a picture is worth a thousand words.
2. This feature can avoid clicking multiple times in Documentation section when developers (let's say Front-end developers) are trying to see/understand what is returned by a specific type and they are not acquainted with GraphQL too much.
3. No all developers who use GraphiQL know about graphql-voyager, so it is worth to add a tab with this feature.
4. Performance can be improved. Keep in mind that GraphiQL is for development purposes, so we do not need a super extra really good performance. I prefer to have this feature without a really good performance rather than omit it.

[asiandrummer]

cc @leebyron @wincent @AGS- in case I'm mistaken/am understanding something incorrectly/have other opinions about this.

@jferrettiboke - I should clarify myself by mentioning that, in my personal opinion, adding a feature (in this case graphql-voyager and a tab) in GraphiQL should mean that it provides a high value and is generically useful for most of GraphQL developers using GraphiQL. Because of this, I think a graphical representation of the schema looks && sounds cool, but I don't believe GraphiQL is the right place for that.

I agree with you that being able to look at the type relationships in one look is helpful, but I think this is true for small schemas only. Take Github schema for example - the schema contains < 100 types and it's already difficult to benefit from the picture.

Keep in mind that GraphiQL is for development purposes, so we do not need a super extra really good performance.

I would disagree - GraphiQL is used in many places (including Facebook) and should not have any extra performance hinderance as there might be other performance-related implications for each use case. For instance:

• There might be a large query/response being rendered in GraphiQL
• An introspection result/a schema passed in has a lot of types
• There may be services running in addition to GraphiQL that might consume a lot of system resources

Because of this (and other reasons around the purposes of GraphiQL), we're intentionally trying to keep GraphiQL as lean/generic as possible.

Having said all this, I do see some action items forming from your request:

Understand what is returned by a specific type

This is possible with #276, but I realize there isn't a clear documentation about it - we should add the instructions how to make use of this awesome feature!

a picture is worth a thousand words

I can see how, for cases with a smaller schema, the graphical representation can be helpful. I think we can consider a few options to incorporate this in GraphiQL (not limited to these options):

• Include an optional prop to opt-in for including/rendering a component with this
• Extend the doc-explorer and create a "plugin" library that includes the schema representation

[asiandrummer]

I'd also like to point out, although I'm not seeing the clear benefit of including the graphical representation (or graphql-voyager) in GraphiQL right at this moment, I think it's a very interesting idea and we should keep experimenting with it, at least with graphql-voyager. The library currently seems early in its development stage (e.g. it's not available as a published library/component), but the feature to use the custom introspection result should mean that we can keep experimenting with it and consider as a feature request in GraphiQL sometime later, especially with improved performance.

Personally I think we can combine GraphiQL's documentation explorer and graphql-voyager, and serve it as another tool for developers to take advantage of. The library already seems like it's borrowing styling from the documentation explorer - another great collaboration opportunity I believe!

[leebyron]

I mostly agree with @asiandrummer. graphql-voyager is a very cool tool in it's own right, but I don't think there is much value in attempting to include it directly within GraphiQL which has a specific and different purpose. Also, to get the most out of a voyager style tool, it really needs as much screen real-estate as possible, it would be sad to attempt to crowd it into an existing tool. I'd also strongly discourage adding a tabbing interface to GraphiQL to avoid eating screen real-estate.

I'd much rather allow graphql-voyager to continue to experiment and expand, I'd rather not duplicate their hard work. Not all GraphQL tools have to be contained within GraphiQL by default!

Also, GraphiQL is intentionally distributed as a stand-alone React component so that it's easy to create tool mashups or incorporate it into your existing internal tools. It seems like graphql-voyager is taking a similar approach. That means that anyone could implement your idea today by building a simple wrapper around the two projects with whatever tab interface worked best for them.

[leebyron]

Another possible way to achieve this today is to host graphql-voyager at another url in your array of tools, and include a <GraphiQL.Button label="Voyager"> in the GraphiQL toolbar which links to it. There's instructions in the Readme for how to customize GraphiQL's toolbar.

[jferrettiboke]

Thanks @asiandrummer and @leebyron for your responses.

I understand now better your points of view. I agree attempting to keep separated the tools. It is a better idea composing both tools in a one custom project if needed.

Thanks guys.