[pkaler]

GraphQL makes sense when you have:

  - Many teams with many micorservices with many underlying stores
  - A fetch-based architecture

Each team can be responsible for implementing the resolver for their service along with caching, scaling, etc. At Netflix's scale you don't want to have every single service have to scale to the level of the BFF/Orchestration layer. https://www.apollographql.com/docs/apollo-server/data/resolv...

If you have push-based architecture, it makes more sense for underlying microservices to publish to a broker like Kafka and then materialize a view to DynamoDB, Mongo, Redis, etc.

And if you don't have many teams with many microservices, then just do the REST, Rails, MVC thing and save yourself the headache.

[kriz9]

Thanks for the explanation. I guess the overhead does make sense at a certain scale. The unfortunate thing is that articles like this always end up inspiring some bored engineer/CTO to redesign everything so it is "webscale" like Netflix and blow the mid/small-sized companies' Christmas bonus on AWS bills.