Altair: Add tracing visualization

[tspecht]

Expected Behavior

• Once a query was run that returns tracing data, parse it and display a timeline-style drilldown of the queries tracing data

Current Behavior

• New feature, not yet in the app :)

Context

• Tracing data is extremely powerful to properly debug your API and find out where potential bottlenecks are lying, especially with deeply nested structures. Integrating this into the tool itself would allow developers to be more action-aware about this and give more context about potential problems that might seem irrelevant at first but can cause serious issues in production.

[imolorhe]

Hello @tspecht, I'll need an example of this. Unfortunately I haven't worked with tracing data in GraphQL before. I'm assuming it is related to apollo tracing? Or is it part of the GraphQL spec?

[tspecht]

Yes, exactly, sorry, should have been more clear on this, my first feature suggestion so far :)

apollo-tracing is a pretty well-established GraphQL plugin right now that runs on server side.

Small screenshot of how this is rendered in the Apollo Engine so you get an idea of what I'm talking about:

[imolorhe]

Okay. It looks like a useful feature to have when debugging servers. 👍

[imolorhe]

https://github.com/apollographql/apollo-tracing
https://github.com/apollographql/apollo-tracing-js
https://dev-blog.apollodata.com/exposing-trace-data-for-your-graphql-server-with-apollo-tracing-97c5dd391385
https://dev-blog.apollodata.com/the-anatomy-of-a-graphql-query-6dffa9e9e747

[tspecht]

Yeah, that is outlining the integration basically, the visualization of the
output the plugin renders into the response data is a complete different
story unfortunately ...
On Sat, Dec 23, 2017 at 9:29 AM Samuel [e-mail] wrote:

https://github.com/apollographql/apollo-tracing
https://github.com/apollographql/apollo-tracing-js

https://dev-blog.apollodata.com/exposing-trace-data-for-your-graphql-server-with-apollo-tracing-97c5dd391385
https://dev-blog.apollodata.com/the-anatomy-of-a-graphql-query-6dffa9e9e747

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/imolorhe/altair/issues/194#issuecomment-353714056,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAk0CFtXJ2VfnTLXu1YjJd_X5kscV6bZks5tDLnvgaJpZM4Q7gSs
.

[imolorhe]

Oh I know. 😄 I'm only documenting it for use when building the feature.

Requirements:

• [ ] No need to use a chart library. Regular CSS should work.
• [ ] Show (pulse) the tracing visualization button when there is tracing data available.
• [ ] Visualization viewer can be maximized.
• [ ] Add setting for showing or hiding the extensions data in the result.

[imolorhe]

https://github.com/swimlane/ngx-charts

[wraithy]

I just want to chime in and say that this feature is what is preventing me from using altair.

Some thoughts

• Hiding the extensions.tracing portion of the response is a great idea if you are visualizing it anyway. GraphQL Playground does this by exposing a setting, which defaults to hiding that section.
• Some deeply nested queries have large tracing visualizations. Being able to pop that pane out into a separate window (or at least maximize it) would be useful in those situations.

[imolorhe]

@wraithy Thanks for your input. Any other usability feedback regarding this would be useful. Also, is there any example project I could use to visualise and develop this feature?

@wraithy A screenshot of the tracing visualization would be nice, to give me a better picture of what you mean by large tracing visualizations. The examples I've seen are not that big.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[imolorhe]

Still active.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[imolorhe]

.

[imolorhe]

https://github.com/kbrandwijk/graphcool-gateway-apollo-engine-demo#advanced-example

https://github.com/apollographql/apollo-tutorial-kit/tree/server-tutorial-solution

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[imolorhe]

https://www.apollographql.com/docs/engine/features/query-tracing.html

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[smeijer]

unstale?

For me, this is what makes playground more useful than altair.

The first quick win, would be to just hide the "extensions" from the received json. Charts like graphql playground would be awesome, but extensions is making the payload hard to read.

If looking for a generic way, a post-request script could be useful. Just like we now have the pre-request script, but for transforming the returned json ourselves.

[YElyousfi]

When can we anticipate tracing visualization to be implemented? Looking to switch over from playground but their visualizer is very useful.

[smeijer]

Why has this issue been closed? Can we reopen it?

[imolorhe]

The issues get closed automatically after several months of inactivity. I can reopen the issue. If anyone is willing to pick this up, that would be awesome.

Alternatively, if there's a publicly accessible graphql server that uses the tracing visualization (or perhaps a response payload with the tracing extensions data), I could consider taking another look at this. Without that, it's difficult for me to work on this since I only know about it but haven't used it before.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[smeijer]

Ping