Comments (7)
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
from router.
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"?
from router.
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?
from router.
@garypen yes, the overview ticket is apollographql/apollo-rs#144
from router.
@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?).
from router.
@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:
- 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.
- Add it to the board and add appropriate GH Project metadata to it — iteration, size, etc.
- Edit #309 to indicate that it closes that new issue. (It'll be necessary for the review to make sure it ticks the boxes, ya?)
- 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?)
from router.
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.
from router.
Related Issues (20)
- Helm chart: allow specifying extraEnvVars as a map
- Allow disabling introspection responses going to cache HOT 1
- Allowing an instrument selector to impl Drop
- Lock introspection to a specific query
- Coprocessor health check as part of overall router health
- Forward GraphQL request extensions to subgraphs with YAML
- Entity cache: make the common redis configuration option visible
- Redis: add an exponential backoff on reconnection
- Entity cache: only cache data if the subgraph returns a Cache-Control header or if a TTL is configured
- Warm up 100% of operations for query planning HOT 1
- Timed out subgraph requests do not trigger `SubgraphResponse` coprocessor requests HOT 1
- Header added to request in rhai does not propagated into logs trace_id field HOT 3
- QUERY_PLANNING_FAILED related to multiple @key directives
- Apollo Router query plan is different vs @apollo/gateway and causes an error HOT 2
- Make `router service call failed` a more specific/helpful error
- axum_factory::tests::test_supergraph_timeout should not use a hardcoded port number
- Router panic in query planning on 1.43.2 HOT 2
- Add Rhai sha256 hashing function HOT 1
- new graphql data representation HOT 2
- Global rate limiting error messages being incorrectly returned
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from router.