studio: extend existing router-bridge with more metadata

[garypen]

Requirements

This proposes that we expose more information from the existing router-bridge:

• Signature for reporting purposes
• Parse/Validation
• Possibly field usage data

---

Original text:

A lot of the data required to generate an appropriate signature in the router usage reporting could be accessible across the router bridge. As long as the router-bridge is a requirement in the router, we may as well use this data to fill the gap in functionality until we can totally replace the router-bridge with a rust implementation.

To paraphrase @glasser:

Extending the main router-bridge interface from "returns a query plan" to "returns all the strongly cacheable information that the router needs about the (operation, schema) tuple". Which includes the stats report key, referenced fields list, whether or not validation passed (though that might not be needed if stats report key calculation is in JS), etc. This will mean you can get these calculations consistent with Gateway immediately without having to wait on apollo-rs to give you more tools.

At the very least you'll need to get the "does the validation algorithm pass" boolean from JS because I don't think apollo-rs is anywhere near implementing the 28 validation algorithms defined in the GraphQL spec.

[abernix]

relates to #48!

[glasser]

Howdy team — I'm probably the company's main usage reporting protocol expert and reviewed @garypen 's first round here. I believe @abernix agrees with me that we'll need to get this done for router GA. I'm happy to prioritize reviewing (or even pairing) on this if that's helpful! If you're going to work on this drop me a Slack DM in case there's some more context I can share.

[abernix]

@glasser I believe this is the signature that we'll want to use from router-bridge, is that correct?

https://github.com/apollographql/apollo-server/blob/bf2f70d74b27b0862ad5d282a153f935e0bde5cc/packages/apollo-server-core/src/plugin/usageReporting/defaultUsageReportingSignature.ts#L78-L87

[glasser]

Correct. Feel free to copy-and-paste this into whatever repo for now — let me know where it ends up and I'll eventually factor it out to its own tiny npm package in https://github.com/apollographql/apollo-utils so there isn't a long-term duplication.

[glasser]

(Though note that the full logic includes checks for special error cases and an extra line on top with the operation name; see https://github.com/apollographql/apollo-server/blob/d75c6cf3360a46ebcd944b2113438be8f549ae6f/packages/apollo-server-core/src/plugin/usageReporting/plugin.ts#L646-L672 )

[o0Ignition0o]

I've been able to get the usageReportingSignature in this wip pr but it looks like there's more to it so I'll try to get this information as well!

[o0Ignition0o]

@glasser do you happen to know if introspection queries are subject to usage reporting? I wouldn't expect anything when it comes to referenced fields, but a signature could come in handy ?

[glasser]

There's not actually such thing as an "introspection query". There are merely introspection fields. One could choose to send operations that both run normal app-level code and randomly also ask questions about the schema.

So we report introspection operations in exactly the same way as any other operation, because there's not actually a distinction.

A different question is how are the introspection fields such as Query.__schema treated by our field-specific features. As far as referencing fields are concerned, it looks like we do include these fields in the referenced fields list, though we should have a test for that! (That said, while I do believe this data makes it to Studio's databases, I don't think they actually show up on the Fields page, since that is driven by "iterate over the schema and associate data with each field we find" and the introspection types are not part of the schema that we're looking at.)

On the other hand, the mechanism we use in Apollo Server/graphql-js to instrument field execution doesn't let us see introspection fields, so they are not included in traces or in executed field lists. It's imaginable that non-graphql-js field instrumentation implementations might do something different here (eg graphql-js/federation-jvm).

[glasser]

(I added a test on the version-4 branch: apollographql/apollo-server@88f6c2c)