Comments (16)
Another possibility (alluded to by @KyleAMathews) is adding a __duration
field to every field:
query {
viewer {
__duration
name {
__duration
}
}
}
Might be too complex/backwards-incompatible (i.e. now name
can either be a scalar or an instrumented type). But it has the benefit that now all you need to do is traverse the GraphQL data response to get instrumentation data, instead of a per-implementation API
from graphql-js.
And the live updating monitor of queries would also be huge to use during development as it'd give a lot of insight to what's actually happening under the hood. Very helpful to those new to GraphQL (read everyone) to help understand how the system works and also very helpful when prototyping new types.
from graphql-js.
+1 to this.
from graphql-js.
Wow, that's a great idea! Even if it doesn't make it into the spec, seems like servers could implement it and expose it through the extensions
key (http://facebook.github.io/graphql/#sec-Response-Format)
from graphql-js.
@rmosolgo as I understand it, there wouldn't need to be any changes to the spec. The metrics gathering / logging would be handled internally and be exposed as built-in types e.g. queryLogType
from graphql-js.
So you could do queries something like:
query slowQueries {
queryLog(durationGreaterThan: "100", since: "2015-08-08T18:58:27+00:00") {
type
duration
fields {
name
description
duration
}
}
}
from graphql-js.
We do something really similar to what's proposed here!
We actually do not query the results of query executions using GraphQL itself, but we do have a logging interface throughout GraphQL which allows us to measure access and performance on a per-field basis.
from graphql-js.
@leebyron do you see value in standardizing a type or two for exposing this data? I think that'd be a boon to the GraphQL ecosystem as it'd allow a lot of new or existing Ops tools to be build on top of or integrated with GraphQL which is absolutely necessary for widespread adoption.
from graphql-js.
I think it's way too early to standardize that. We have our internal representation of this which is extremely specific to our internal metric tools. Standardizing what we have would mean no one would pay attention to the standard. Standardizing something else would mean the thing we have is not really standard.
If a standard emerges across many implementations that tools are taking advantage of, then we should consider a standardization effort. Otherwise I think this fits well into the realm of experimentation.
from graphql-js.
It's also not entirely clear to me that this kind of metadata needs to be exposed through GraphQL itself. We have lots of ops tools that measure GraphQL usage but do not expose their data through GraphQL since our client applications do not need access to that information - but our infrastructure ops systems do and GraphQL is not the right tool for their data access needs.
The important piece that I'm excited to add here is a logging interface which will allow for flexibility in connecting any type of ops service to measure GraphQL usage.
from graphql-js.
I agree with your argument that it'd be too early to standardize any sort of types. I'll experiment with creating types internally and report back.
from graphql-js.
Huey Petersen just wrote this http://hueypetersen.com/posts/2015/11/06/instrumenting-graphql-js/
from graphql-js.
I used the information above and hackily implemented a simple API in GraphQLHub.
Some ideas on a first-class API:
// on the Schema objects
let schema = new GraphQLSchema();
schema.instrumentation((instrumentation) => {
});
// at the graphql fn level
// opt-in is probably best to remove perf overhead
graphql(schema, query, { instrumentation : true }).then((result) => {
console.log(result.instrumentation);
});
// perhaps support it at the express-graphql level, which returns it inside `extensions.instrumentation`)
graphqlHTTP({ schema: MyGraphQLSchema, instrumentation: true });
// or via a callback
let handleInstrumentation = (instrumentation) => ...
graphqlHTTP({ schema: MyGraphQLSchema, instrumentation: handleInstrumentation });
from graphql-js.
I think Apollo Optics is the first one to do it.
we can get some insights from them
from graphql-js.
Any progress on this? Any suggestions for instrumenting graphql-js?
from graphql-js.
I think #1516 would a good first step and allow 3rd-party dev to produce middlewares that will work with any graphql-js
based server. After that as Lee suggested we need to observe and standardize emerging pattern.
It's the only realistic goal that we have ATM so I'm closing this issue in favor of #1516
from graphql-js.
Related Issues (20)
- Detect subscription successfully started HOT 1
- Errors thrown when iterating over subscription source event streams (AsyncIterables) should be caught HOT 2
- graphql resolver circular dependency type error (bi-directional relation) HOT 1
- Current main is up to 50% slower than previous major version HOT 10
- Type definition for `DefinitionNode` appears to be wrong HOT 4
- AST: `IntValueNode` and `FloatValueNode` store values as string HOT 2
- Array-type resolvers: an intuitive solution to the n+1 problem HOT 1
- Performance of stack traces in errors results in high response latency (>1 second) HOT 1
- Support for deep input graphs HOT 4
- https://github.com/graphql/graphql-spec/pull/793#issue-742412159
- Support Nodejs 20 LTS HOT 1
- Hi @Cito, I'm @github-actions bot happy to help you with this PR 👋
- https://github.com/graphql/graphql-js/issues/4047#issue-2228685707
- Hey really.org
- Hey
- Global HOT 1
- Depending on the scale a few more fields could result in a lot more function calls in the resolvers. That coupled with Node.js / JS single threaded nature might be problematic.
- IHeyReally
- IHeyReally.org
- IHeyReally.org
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 graphql-js.