Support multiple schemas in babel-relay-plugin

[sorenbs]

Now that relay 0.8 supports multiple environments it would be great if the babel plugin could support multiple schemas.

I imagine there would need to be a way to name a Relay.Environment and a way to configure the plugin to use a specific schema for a specific Environment.

Just to make it a little more concrete I will describe our use case:

The graph.cool dashboard allows users to build their graphQL schema in a graphical interface. Information about the user and the schema they construct is persisted in our internal graphql api using relay.
Additionally the user can view and edit data for their application in a data explorer within the dashboard, which is querying the client graphql api.

Currently we implement the data explorer with Lokka, but we would like to transition this to relay.

[josephsavona]

Additionally the user can view and edit data for their application in a data explorer within the dashboard, which is querying the client graphql api. Currently we implement the data explorer with Lokka, but we would like to transition this to relay.

Can you clarify - what kinds of queries would need to be transformed for the data explorer? Are these static queries that exist i.e. in source code, or are these queries that users enter in the UI (along the lines of graphiql)? I'm asking because application code seems likely to be written against the application's specific schema (no need for multiple schemas) and ad-hoc queries typed in a dashboard seem like a natural fit for using raw GraphQL (no library).

[schickling]

It's all static queries in the application source code.

[josephsavona]

@schickling Application code source code would typically be compiled against a specific schema. Can you provide a bit more info on why the need for multiple schemas?

In general, we'd prefer to keep the plugin itself simple since most apps fall into the category of one app + one schema. Rather than change the plugin interface, we're open to making the plugin internals accessible as public API. The RelayQLTransformer class, for example, is given a schema in the constructor and has methods to convert GraphQL documents into code that can be used with Relay. I wrote about this on a related issue - would this approach help?

[sorenbs]

You are right @josephsavona - in our case the second schema is not known at compile time, so clearly the babel transform is of no use. Sorry for using an unclear example.

In the general case though I think it might make sense for one react/relay application to work with multiple backends and schemas and I'm curious to hear your thoughts on this.

The main use case would be consuming third party GraphQL apis as well as your internal api. If pinterest for example exposed a public relay compatible GraphQL endpoint you would need support for two different schemas to integrate it directly in your application

[josephsavona]

@sorenbs Overall, it would ideally be possible to build an app with Relay that targeted multiple schemas. This doesn't seem like a common requirement, though, so we would need to balance making this possible with increasing complexity for the typical case. In general, our preferred approach is along the lines of what we've outlined in #559 - where in addition to higher level APIs like RelayContainer we also provide a low-level APIs for imperative data-fetching. For the plugin, this would mean providing tools to let developers compile queries against different schemas.

tl;dr we should provide just enough primitives in core to let people do this in userspace.

[Globegitter]

Currently it seems there exists only one appraoch: https://github.com/eyston/relay-composite-network-layer But, while certainly not necessarily the highest priority, I do agree that it would be nice to have some easier way to target multiple schemas via statically defined queries.

[wincent]

No future work is going to happen on the old babel-relay-plugin now that we have released Relay Modern. If there is still interest in pursuing support for multiple schemas, we can create a new issue for that. In the meantime, closing this one out so that we can keep the issue tracker focused on current work.

[n8sabes]

We use two different schemas that are bound to two different microservice endpoints, both of which must be accessed from the same client. It is not desirable to create one endpoint to proxy to other GraphQL servers, due to the use of microservices and goal to reduce execution environment runtime -- thus the client initiating the query to the two different endpoints.

If there is a best-practices pattern for this with Relay-Modern, please point to a code example. Otherwise, where do you recommend re-opening an issue if this current issue is not adequate? Thanks for any input.

[josephsavona]

Internally we only use Relay with a single schema per app, so we don't have a best practice or recommended approach. The best bet might be to post an issue at facebook/graphql, since multiple schemas are something that multiple clients may need a solution for.

[VaclavSir]

My recommendation would be to use different folders for components that use different schemas. Then you can compile them separately, using --include and --exclude options of the relay-compiler.