Comments (11)
@helfer yea this makes sense to me. I'd use something like this for user permissions and auth. Logging is helpful too. Nice work!
from graphql-tools.
@jbaxleyiii Yeah, I wanted to use @, but then people will confuse it with directives. The two concepts should really be merged, but unfortunately directives are very narrow and not reusable at the moment, and they come after the thing they modify, which I think looks really weird with decorators.
from graphql-tools.
@helfer I like the +
usage since the decorators give additive value.
I think something like @depreciation
should be added to the schema spec but in the interim, this works great.
I'm a fan. 👍
from graphql-tools.
What's the plan for adding the +
syntax? Do we have to fork the parser?
from graphql-tools.
Yeah, we have to fork the parser (and maybe buildASTSchema), but if my latest PR gets merged, it will produce schemas that are 100% compatible with the current version of graphql-js.
If we want to return that data in the introspection query as well, then we have to create our own versions of some other stuff as well. I think it's worth it though, because those features will eventually make their way into GraphQL, and temporary forks will give us an opportunity to iterate much much faster.
from graphql-tools.
Moved here: https://github.com/apollostack/graphql-decorators
from graphql-tools.
are graphql decorators included in current release/npm version?
from graphql-tools.
@emmanuelbuah no, we haven't done anything in that direction yet.
from graphql-tools.
Thanks for the quick response.
from graphql-tools.
I'm imagining a way to change schema by a mutation:
When doing RESTful endpoint wrapping, some endpoint will return a huge amount of data, and thus I need to do some caching at the wrapping layer.
So I can write:
+cache(period: 3600)
type ConfigType {
alarmTypes(forceUpdate: Boolean): [AlarmCodeType!]!
}
To describe that this type of data can be cached for 3600ms at wrapping layer. And if needed, it can be forced update.
But if there are some emergency, and at this kind of time, other people will probably update lots of alarmCode to the server, but I still don't want to query REST endpoint every time I query graphQL layer. So client side caching time should be shortened for this period of time.
Can I write this? :
type CacheTimeType {
time: Int!
}
+cache(period: time on CacheTimeType)
type ConfigType {
alarmTypes(forceUpdate: Boolean): [AlarmCodeType!]!
}
I'm not very clear about it, just imagining : )
from graphql-tools.
I think it's useful to set a shorter cache timeout sometimes, but I think it doesn't make sense to add a lot of additional complexity to the schema, like dynamic decorators. But for this kind of decorator you could definitely have a variable cache timeout. Rather than saying something like time on CacheTimeType
, I would then give it a full query, which can be run against the same schema at the time of query execution, or is sent to the client, which then sends the query.
However, I think this may still not solve your problem, because those clients that got the old cache timeout will not refetch for one hour, at which point your emergency might already be over. And anyway, I think in those cases you could also manually update your schema to have a shorter timeout, so I'm not 100% convinced that this is a great use-case.
from graphql-tools.
Related Issues (20)
- GraphQLSchema from stitchSchema causes scalar values to be parsed twice HOT 1
- Allow sorting only top level declarations in schema HOT 1
- `@graphql-tools/mock` - controllable randomness when mocking out union types
- processImport seems unnecessarily slow due to graphql.print HOT 1
- SSE stream breaks when response data is large HOT 2
- Allow for empty objects in mock store HOT 2
- Apollo Subgraph entities are not resolved when using `wrapSchema` HOT 13
- getLoader in batch-delegate uses a non-unique cacheKey HOT 1
- graphql-ws executor does not resolve `connectionParams`
- Project Roadmap HOT 2
- Drop dependency on fast-url-parser HOT 2
- DEBUG=1 results in console.time() warnings
- @graphql-tools/mock does not work with Vitest HOT 5
- Deterministic (seeded) enum values
- Stitching: object field is null when all selections are delegated
- Http Executor encodes headers into query parameters which can leak Authorization headers
- Ability to get names of all the stitched queries in a middleware
- requireResolversToMatchSchema: 'warn' throws an error
- Support .astro file loading on graphql-tag-pluck HOT 1
- Troubles with connectionParams on subscriptions
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-tools.