Remote schema stitching strategy

[axelmm]

Scenario:
I'd like to merge (one or more) external graphql service, f.e. external informations about current user's assets.
Of course I'd like to hide this dependencies on server to avoid client side changes.
I suppose that some parts of externals could be available by proxy but some queries/mutations have to be transformed/decorated passing user informations, credentials ... additional informations from current service.

From what I found there is apollo-engine used - secondary origin could be suitable for proxy?
Modules exports schemas but api\schema.js uses makeExecutableSchema - this is the place where I should merge local and remote schemas (makeRemoteExecutableSchema, introspectSchema or copied schema)?

Another scenario:
I'd like to use subscriptions for some of external mutations while remote api doesn't support them.
Resolve and process this mutation locally (only sending results to update remote db) having ability to notice client directly (kind of filter/transform) or wait for external response?
How to call external api from local resolver (one mutation) and pass other queries/mutations only decorated with authenticated user id?

[larixer]

@axelmm These questions are too project-specific and are outside of the scope of the kit.

[axelmm]

I'm aware they are specific and not expect such options to be ready/configurable now.
I'm asking about suggested points where such features could/should be realised or how to make this project suitable for such modifications/extendings, more universal.
I already redirected all queries to external api (not supported batching, subscriptions) but would like to use more of its backend possibilities. I recognize this project like CRA, 'batteries included' and simply worth support.

Api aggregation, mashups or simply using external apis aren't unusual situation. Consuming rest apis is simple. Merging remote graphql or resolving queries using mixed local and remote schemas isn't. As most complete [referral] apollo project it could contain this kind of elements. While not expecting ready solution I'm only asking about tips, hints or best practices in quite common scenario.

I'd like to see this project 'more open' like 'opening doors for extensions' in LB4, more composable, interchangeable, replacabple, more SOLID. Being 'universal' stops earlier? Problem even not worth discussion?

[larixer]

@axelmm This project is open to such modifications/extending - you add the module which will be an example implementation of the topic that you describe and add it to the kit. API aggregation, mashups is not an unusual situation. I'm failing to understand how can we add some "generic" example of merging various APIs together, it highly depends on the nature of APIs you will merge. I think it is both too API and project specific and it is too broad to bring some example that will fit all

[larixer]

In other words, I do not currently understand what you want, the problems you described are too broad.

[larixer]

Closing because of inactivity