With GraphQL, every request URL is the same, and it doesn't make sense to lump performance of all of these together. Response codes are not meaningful either. Visibility into request and response bodies is critical to understand what's really going on in production.
Given that Resurface excels at processing request and response body data, providing native GraphQL support is an obvious next step. The goal is to help customers understand what GraphQL queries are the most heavily used, where performance optimizations are needed, and how field usage changes over time. Resurface provides this visibility without ever transferring data a third party like services from Moesif and Apollo.
A key observation is that many GraphQL adopters still expect to have their older REST-style APIs for years to come. Even the most enthusiastic adopters aren't setting the goal of converting overnight. This is an area where Apollo is particularly weak — Apollo only understands GraphQL traffic and provides no help for legacy REST APIs. Adopting Resurface yields visibility into both GraphQL-style and REST-style APIs, which is important since many customers will be using those in concert for some time.
The first piece of our GraphQL story shipped this week — our Node.js logger v2 now integrates with Apollo Server to capture GraphQL requests and responses, which allows Resurface to function as a commercial alternative to the Apollo Trace Warehouse.
Next we're working towards GraphQL extensions for data privacy & security in our loggers, plus native GraphQL indexes and query functions in our database. But more importantly, we're excited to join the fray in the growing GraphQL community, with its highly progressive segment of API developers, and its obvious disruption for entrenched APM vendors.