Using Global Ids in *ById(s) Resolvers about graphql-compose-relay HOT 2 CLOSED

@yoadsn wow! good catch of graphql-compose principles without Documentation 😅.
Awesome gist. 👍

In my prior lib graphql-mongoose (more powerful reimplementation of graffity-mongoose) I also used processId method from graffiti (https://github.com/nodkz/unpublished-disgusting-graphql-mongoose-module/blob/master/utils/graphql.js#L47). But after some period of time I understood that how ugly became my app code when I tried to realize something complex. The problem was with a mess of relations and configuration approach of API. So I completely change approach on declarative API, rewrite all from scratch, test it on my current app and obtain tons of new features. Declarative API allows writing plugins like your gist. Incapsulate some nasty repeatable code under some method.

But also had removed things that bring some confusing, eg. processId. When I got globalIds I don't know what I to store now in DB mongoId or globalId in the document with relations (if I store globalId then I can not use mongodb aggregations/map-reduce for analytics). Or when I will in my code use TC.addRelation method or wrapResolve what I will have in args.id. Also I want to give an ability to construct schemas only with mongoose (without relay) eg. for some backends API.

The graphql-compose is the next generation of graphql-mongoose and graffity-mongoose. It should allow construct schema exactly what you need and what you want. Just generate. Kick of configs.

So if you globalId coercion with mongoid use it! But be careful, maybe in future, it brings problems like above, which I tried to explain.

My recommendation in your approach to not override standard findById and findByIds resolvers. Make your future more flexible. Simply add new your own resolvers. Just fix one line https://gist.github.com/yoadsn/3d4b432580075ee656a9b92283eed2e0#file-attempt-js-L47

// from
tc.setResolver(resolverName, wrappedResolver);
// eg. to this
tc.setResolver(resolverName.replace('Id', 'GlobalId', wrappedResolver);
// or will be better if you explicitly provide new resolver name
globalizeIdInputFieldForResolver(tc, 'findById', 'findByGlobalId');

Recap: you leave old resolvers untouched and get new findByGlobalId and findByGlobalIds resolvers. 😉

PS. You may create as much resolvers as you want. You are not restricted by current 13 resolvers.
PSS. Recommend to read this comment graphql-compose/graphql-compose#2 (comment) and this graphql-compose/graphql-compose#11 I shared there some best practices based on my experience of building graphql server.
PSSS. Thanks, that praised my work!
PSSSS. Will be happy if you contribute something to graphql-compose. PRs are welcome 😇

from graphql-compose-relay.

@nodkz Thanks for the detailed response + reading pointers.

Last night I did get to the conclusion I should not override the default revolvers, and would definitely do that. I am still considering if processId is more trouble than help - currently I use only global ids with graffiti but it's a mostly 'read only' API maybe with mutations it will bite me in the a$$.
I will today create a new resolver from scratch for the first time for something I need (wrap an aggregation pipeline call). So I hope to know more about reuse of resolvers within resolvers and maybe see the problem you mentioned.
But yes, it's infectious, once you start accepting both id types on the same Input Arg, all API must support it. (including relation args and sorting by it! which could cause a mess).

PS. I would love to send PR's once I find I can improve anything - never used flow but it's so easy to read! Your code is some high level stuff, hopefully I can reach something I could contribute.

from graphql-compose-relay.