apollo-datasource-mongodb
apollo-datasource-mongodb copied to clipboard
GraphQLGuide
fix: Always use lean Mongoose documents
With hydrated Mongoose documents they aren't serializable. Therefore caching can't be used, as it serializes the documents.
See https://github.com/GraphQLGuide/apollo-datasource-mongodb/issues/74 for why this is needed for Mongoose documents.
Yes, it is definitely a breaking change!
I updated the test and the change indicates one of the breaking changes. The lean documents don't have these getters like id, so if the code depends on them it will break it.
What do you mean with tests in Typescript? Rewriting the existing tests in Typescript but leave the rest of the code in plain JS?
It should be possible to implement this in a way that is backwards compatible. For example, the constructor could take an optional argument that defined a transform function that would be applied to the query result before being written to the cache. One could supply a function that calls toObject and solve this problem in a more generic way.
We have a large codebase, and it's very difficult to be 100% sure that all of our code will still work with .lean being called on every result. It might not be desirable for other clients of this library for other reasons.
tl;dr Why making a breaking change when you can achieve the same end result compositionally, offer greater flexibility, and avoid the breaking change.
Actually, now that I'm thinking about composition, it seems like the one solution might be to just wrap a cache with a higher order cache which calls toObject in the value passed into set if the value is a mongoose document without requiring changes to this library at all. That's certainly what we would choose to do if the alternative were a breaking change.
Ah, nevermind. I see the library is already doing _bson.EJSON.stringify(docs) inside so we can't fix this by providing a smarter cache implementation. I'll revert to my original take which is that the best way to fix this is by allowing an arbitrary transform function to be passed, and making this library unopinionated about what transformation is applied to the results of the query before being passed to the cache.
It should be possible to implement this in a way that is backwards compatible. For example, the constructor could take an optional argument that defined a transform function that would be applied to the query result before being written to the cache. One could supply a function that calls toObject and solve this problem in a more generic way.
@lorensr I'm not sure if I'll have time for this, but if I put up a PR for a solution of this shape would you accept it?
@doronrk Yeah, a backcompat way to achieve the same goal would be great, thanks ☺️
@lorensr , npm test indicates that several tests are failing on master. Is something wrong with my local setup, or is this true for you as well?
