Hi Ben and thank you for your quick and thorough answer.
I’m faced with a quite interesting challenge and after hours of research, I thought maybe you (or anyone else here) would have an idea on how to tackle it.
My goal is to make a distributed app in which the business logic would be split between microservices. I’m not 100% positive but I think schema stitching will be of great help once I want to scale it out on multiple nodes.
For now though, I really don’t need to and would be happy with an umbrella app with local dependencies. I think this would be a viable option for a couple of years. Being careful about encapsulation would also make it easier when it’s time to scale.
Here is an example of a GraphQL document I’d want my app to be able to respond to:
{
users {
possessions {
...
}
}
possessions {
users {
...
}
}
}
A simple many-to-many relationship, but here’s the catch. The umbrella app would look like this:
umbrella_app
apps
graphql_entry_point
users
possessions
This is not a real life example but you get the idea. I’d like to split some parts of the business logic between multiple apps and have a single GraphQL node to rule them all.
I’ve explored many options. Here are my thoughts:
-
What I’d like the most is to have each business logic app (users and possessions) be responsible for its own GraphQL schema and have the graphql_entry_point app import their types and fields.
- I can’t seem to make this work. Since users and possessions are related to each other and I therefore need to share their types and fields, I always end up with compilation errors (duplication of things that must be unique). If you have an idea, example or anything that would help me do this, I’d be so happy!
-
I could have my whole schema defined in the graphql_entry_point app and then call the other apps for the data that I require.
- This option might not be in line with my former goal, that was to split load between microservices. As the business logic will grow, the graphql_entry_point app will be the only one responsible for building and processing everything Absinthe related. I don’t know if it’s a real concern, maybe Absinthe is so lightweight it could handle any sized schema like a breeze. However, I’d still like each app to be responsible for defining its own schema.
- I don’t see a viable option for the graphql_entry_point app to call the other apps for getting their data. Function calls through an interface layer? Rest? GraphQL documents (duplicated or altered)? Every option seems to add a lot of complexity and reduce the flexibility GraphQL was engineered for.
Whatever your thoughts are, I’d be very happy to hear them! Don’t hesitate to destroy my ideas or preconceptions as I’m here to learn.
Cheers! 
).
