-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Providing an array of resolvers #3
Comments
@helfer Now I have a better understanding of how mocks work I'm finding it a suitable solution. Merging resolvers might be useful in some situations though and for anyone wanting to do that I can recommend just deep merging them. Perhaps this could be mentioned in the docs if you don't think think it's too obvious? This can be closed. If you want me to submit a PR to the docs to mention this just let me know and I will. |
@ciwolsey Yeah, I think adding it to the docs would be great! You can add a couple lines here: http://docs.apollostack.com/apollo-server/resolvers.html |
…rver-env (#1259) * Export polyfills and types separately * More imports from apollo-server-env * Initial commit * Add .npmignore to avoid ignoring lib when publishing * 0.0.2 * Reorganize code and clean up GraphQLExtension interface * 0.0.3 * Add support for timing callbacks and add GraphQLExtensionStack * 0.0.4 * Downgrade target in tsconfig.json from es2015 to es5 * 0.0.5 * Bump `graphql` peerDependency. (#3) * 0.0.6 * Update dependencies * 0.0.7 * whenResultIsFinished fix for array results (#4) * 0.0.8 * [apollo-bot] Update the Issue/PR Templates with auto label (#6) * Bump `graphql` peerDependency. (#7) * Update `graphql` peer dependency range to allow 0.13.x. (#8) * Update `devDependencies` to latest versions. (#9) * dev: Update TypeScript to latest version, v2.7.2. * dev: Update `graphql` to latest version, v0.13.2. * dev: Update jest & dependencies to latest versions. * dev: Update type definitions for `graphql`, `node` and `jest`. * Allow `undefined` return values to `GraphQLExtension`'s `format()`. (#10) In some cases, it's conceivable that the `format()` method may need to abort its decision to provide extension information at runtime, in the event that it doesn't have the proper information to return a full-result. The `format` method already removed false-y results, so this simply changes the types to allow the same. * 0.0.9 * Fix lifecycle method invocations on extensions * 0.0.10 * Add changelog * Upgrade to TypeScript 2.8 Makes my editor integration happier (a bugfix in tsserver I think) * Add tslint and prettier Same configuration as apollo-engine-js * Remove magic from GraphQLExtensionStack constructor It's not hard to consistently pass in an actual extension object to this low-level API. * New extension API: didStart handlers return didEnd handlers This is a backwards-incompatible change: GraphQLExtension implementations and users of GraphQLExtensionStack (ie apollo-server-core) must change their implementations, if they implement any of the xDidStart/xDidEnd APIs. This allows "didEnd" handlers to refer to closure variables from the "didStart" handler rather than needing to store state on the extension. The new "didEnd" handlers run in the opposite order of the "didStart" handlers, so that they properly nest. * 0.1.0-beta.0 * Changelog * Add magic back into GraphQLExtensionStack constructor But now it actually gets more context (the execution arguments) and doesn't have to be a constructor. * 0.1.0-beta.1 * Export more types * 0.1.0-beta.2 * Fix lifecycle handlers to pass proper "this" * 0.1.0-beta.3 * Pass options directly to start handlers; eliminate factory again * 0.1.0-beta.4 * error handling in didEnd * 0.1.0-beta.5 * pass multiple errors to EndHandler * 0.1.0-beta.6 * add willSendResponse * 0.1.0-beta.7 * prettier * setFieldResolver for custom fieldResolver * reverse * get more initial options into requestDidStart * 0.1.0-beta.8 * 0.1.0-beta.9 * Actually, we already get the fieldResolver! * 0.1.0-beta.10 * work without extensionStack * 0.1.0-beta.11 * 0.1.0-beta.12 * Send errors to willResolveField callback * 0.1.0-beta.13 * willSendResponse can return a result * 0.1.0-beta.14 * Revert 1063be8..56912fc This reverts commit 1063be8..56912fc. * add PQ options to requestDidStart * 0.1.0-beta.14 * 0.1.0-beta.15 * Initialize an empty TypeScript/Jest package Template based on apollo-engine-js * Basic trace node structure building * basic timing * Checkpoint towards signature implementation The new signature implementation does not try to compress whitespace. * Basic signature implementation * progress towards actual reporting * basic checkpoint for reporting * 0.0.0-beta.1 * pull in @types/long, since it is in the external api * 0.0.0-beta.2 * get rid of Long * 0.0.0-beta.3 * debug log request what happened * 0.0.0-beta.4 * 0.0.0-beta.5 * correct url * 0.0.0-beta.6 * request headers * 0.0.0-beta.7 * leave out a few headers * 0.0.0-beta.8 * prettier * move stuff into multiple files, and stop exporting the extension * lots of doc comments * address agent.ts XXX comments * implement privateVariables simplify API by removing flush() and allowing flush-ers to just call sendReport directly * privateHeaders and error tracking * gzip, signals * fix test * 0.0.0-beta.9 * Error handling for reports * 0.0.0-beta.10 * no need to include boring stacktrace * 0.0.0-beta.11 * tweak error reporting * 0.0.0-beta.12 * package-lock update (npm@6?) * Reduce target report size to 512KB from 4MB. Load testing revealed that protobuf encoding for large FullTraceReports could tie up CPU and reduce p99 request latency (eg, to 200ms from 10ms). Reducing the default target report size spreads out the encoding time and mitigates the impact on latency. If this is not acceptable for all users, we may have to investigate reintroducing agent-side stats aggregation to keep report sizes small. * 0.0.0-beta.13 * Encode Traces as they come in This improves p99 times with little effect on p50 times. It also lets us get rid of the heuristic average trace size estimation. * 0.0.0-beta.14 * support PQ fields * npm audit fix * 0.0.0-beta.15 * ignore coverage * Make the default signature more aggressive We'd rather tell people confused by literal removal to tweak the signature than tell people causing outages to do so. * 0.0.0-beta.16 * Remove obsolete files from graphql-extensions and apollo-engine-reporting * Fix dependencies and configs * Fix apollo-server-cloudflare to import from apollo-server-env * Fix compilation and test configs * Get all tests passing again * Switch to Lerna independent versioning * Polyfill promisify for Node < 8 and load polyfills in tests * ES2016 exponentiation operator is only supported in Node > 6 * add dependency cache for circle * add missing env dependencies in REST datasource
* Initial commit * 0.0.3 * Replace endOffset with duration in resolver calls * 0.0.4 * Fix duration * 0.0.5 * Remove unnecessary schema level resolve function and return schema * Update README * 0.0.6 * Update README * Update dependencies * 0.0.7 * Update README * set package.json to point to this repository (#3) * Update dependencies Fixes #4. * 0.0.8 * Add asynciterable support to tsconfig.json * Skip trace collection when context or context._traceCollector is undefined Fixes #5. * 0.0.9 * Rewrite to use graphql-extensions * 0.0.10 * 0.0.11 * 0.1.0 * Update graphql-extensions dependency and downgrade TS target * 0.1.1 * Update README * Update README * Increase version range for `graphql` peerDependency. (#7) * 0.1.2 * Update dependencies * 0.1.3 * [apollo-bot] Update the Issue/PR Templates with auto label (#9) * Update `graphql` peer dependency range to allow 0.13.x. * dev: Update TypeScript to latest version, v2.7.2. * dev: Update jest & dependencies to latest versions. * dev: Update type definitions for `graphql`, `node` and `jest`. * Allow `undefined` to return from `format`. (#12) * Allow `undefined` to return from `format`. TypeScript 2.7 introduced new "Strict Class Instantiation" rules which, as the name suggests, require properties which are intended to be set (eventually, to a type) be set during construction. Before this change, the `TracingExtension` class was deferred setting these private properties (namely, `startWallTime`, `endWallTime`, `startHrTime` and `duration`), but not during instantiation which required setting marking them as optional and guarding their usage in other methods which might use those (temporarily `undefined`, if even for a tick) properties. For example, the expectation that `format` is _only_ called after `requestDidStart` is not guaranteed with this configuration, even if it is expected under normal operation. Therefore, this change adds the additional guarding and updates the `format` method to return `undefined` in the event that it doesn't have the appropriate data. * Update `graphql-extensions` dependency to `~0.0.9`. Specifically, to take advantage of a type which landed in `graphql-extensions@0.0.9` thanks to https://github.com/apollographql/graphql-extensions/pull/10. * 0.1.4 * Update for graphql-extensions@0.1.0 API (#13) * Upgrade to TypeScript 2.8 * Add tslint and prettier * Update for graphql-extensions@0.1.0 API * 0.2.0-beta.0 * Make work with newest API usage format() now gets called before the requestDidStart() EndHandler. * 0.2.0-beta.1 * remove unused files from tracing package * upgrade packages, fix compilation bugs, and add test
Migrate composition work -> apollo-federation package
Migrate composition work -> apollo-federation package
Migrate composition work -> apollo-federation package
It would be really great if we could provide an array of resolvers and have them merged. Found myself in a scenario where I wanted to load the regular resolvers, but if the server was started with a certain flag it would load another set of resolvers which would override parts of the regular ones.
Specifically it would be great on the server to be able to provide an array of resolvers like so:
In my case I needed sandboxResolvers to overwrite any resolvers with the same name in regularResolvers if a certain flag was set at server startup.
I tried with Object.assign but it didn't work in some situations. I'm doing it with deepmerge NPM for now. Would really appreciate any advice on how to do this in the best way until it's actually implemented as I'm out of my depth somewhat.
The text was updated successfully, but these errors were encountered: