Studio Agent

[abernix]

Requirements

TBD. An agent which communicates with Studio and acts as the foundation for operation (signature-based), field (shape) and latency (trace) stats to power Apollo Studio functionality.

Relevant Subtasks / Links

These are likely components/candidates of this agent!

• Studio Uplink integration #442
• studio: Field usage reporting #67
• studio: Schema reporting #70
• CORS support for Apollo Client Awareness headers #127
• Tracing support (incl. Resolver timing; might be implemented via opentelemetry tracing or Apollo Tracing (e.g., inline tracing support) #74)

[Geal]

relevant links for how data must be filtered for privacy reasons:

• https://www.apollographql.com/docs/studio/data-privacy/#what-data-does-apollo-server-send-to-apollo-studio
• https://www.apollographql.com/docs/studio/performance/#signature-algorithm

[garypen]

I'm working on three components of this at the moment:

• Adding a basic infrastructure to allow usage data to be transferred from the router to studio usage ingress
• Normalising queries so that statistics are reported accurately
• Figuring out which statistics to collect and how to present them in the required format

The second task is mainly relying on work which needs to be done in apollo-rs. @lrlna Is there a ticket for the semantic validation work that I can reference here?

[lrlna]

@garypen yes, the overview ticket is apollographql/apollo-rs#144

[abernix]

@garypen Administratively: #67 (from the original post above) is currently marked as Deferred, though I think it's wound up / inclusive of the stuff you're working on. Is that right? (If yes, would it make sense to mark that more granular issue as "In Progress", update #309 to indicate that it closes that issue and keep this as a higher-level longer-term coordination issue?).

[garypen]

I'm doing the work described as "Phase 1" in the quip document proposal from David. That doesn't include any field usage stuff. To be honest this has evolved fairly dynamically since the original issues were filed. Maybe we need to spend some time "issue wrangling"?

[abernix]

@garypen Ok, that's fair — I agree some issue grooming is in order. I definitely understood that it was just Phase 1 that you were doing — it's absolutely true that phase doesn't include field usage reporting, I just forgot that. In that regard, I think the answer to my question above is merely "No" (and, in retrospect, I could have latched onto that — I was merely doing some cleaning up to make sure that PRs were closing issues.)

Looking at this particular issue, it's possible it's not the right match for what I was looking for, which is "the issue that #309 should close".

With that in mind, I think we're missing an issue for the Phase 1 work. What do you think about:

1. Opening an issue that is just for the operation-based reporting / Phase 1 stuff, documenting what's in the doc. We should communicate (publicly) what the scope of work is.
2. Add it to the board and add appropriate GH Project metadata to it — iteration, size, etc.
3. Edit initial studio agent, client awareness and operation reporting #309 to indicate that it closes that new issue. (It'll be necessary for the review to make sure it ticks the boxes, ya?)
4. Consider leaving this issue open as the umbrella issue that I think it is today — update it to convey the expected follow-up stuff (e.g., phase 2, etc.). Alternatively, consider editing this to just cover the "Agent" part of it, if that's even interesting on its own.

Thoughts? (If you agree, feel free to go for it?)

[abernix]

Most of the items on this parent issue are closed, so I'll close this and leave the child issues to hold their weight in terms of follow-up items.