I’m starting development on a GraphQL-based project (Apollo, hopefully). One of the imperatives from above is to embrace a micro-services architecture.
So far I’m designing server with each module has models (using knex, similar to Apollo GitHunt API server) but then we need to aggregate data from different modules. This could be done in an aggregation layer, or one module needs to reach into the data layer of another.
The fact that each module is not completely self-contained is frowned upon. Personally, I think the microservices trend has gone too far, when you have to go over HTTP to get data from another services (or probably multiple services) in order to accomplish anything. However, there are some people who firmly believe that microservices are the only way to go (e.g. CTOs, architects) and anything else is a slippery slope to unmaintainable code.
What’s your experience and recommendation? How do you modularize your GraphQL server, and deal with inevitable coupling?
Is it practical to create pure GraphQL microservices? Meaning, each service has its own queries and mutations, and talks to other microservices only through GraphQL. I’m thinking this is impractical, but maybe I’m wrong?
Another question: Has anyone experimented with running a GraphQL system AWS Lamda?