- 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.
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.
My understanding is that it’s the preferred way for a lot of frontend engineers to build their experiences. It gives a lot of freedom and reduces entire classes of bugs due to the type system.
Edit: to elaborate; “a lot of freedom” means an entire schema instead of pre-negotiated contracts, potentially reducing back and forth between frontend and backend.
Yep. Imagine an api scheme that matches the underlying normalized database structures. In order to render a view, you may need dozens of calls to different services to gather all of the data you need. Some places have been moving towards backend for front end (BFF) as a way of providing a better abstraction layer for UI development and some have been exploring GraphQL where the data can be combined and aggregated within call as dictated by the front end. I will say that the time I’ve spent working on front ends with a good graphql implementation were much more efficient and reduced overhead of dealing with more typical API interfaces.
This isn’t something I’d rush into though. There is real overhead in managing graphql and in my opinion is best suited for extremely large API spaces that most companies simply don’t have to deal with. Microsoft and their graphql implementation is one where I see it as a better option than hundreds if not thousands of different services with different endpoints.
The sibling comments here are weird to me. IME the primary reason to us GraphQL is explicitly solve the dilemma of "ReST-ful" endpoints:
1) An endpoint returns a superset of the data any client may need, which means more data is loaded than any given client needs (which means wasted bandwidth/compute)
2) An endpoint returns a subset of the data all clients need, which means any given client has to tack on additional queries to get everything it needs (which means more roundtrips)
(There's the third option of tacking on "includes" or "excludes" parameters to endpoints, but at that point you're evolving an ad hoc, informally-specified, bug-ridden implementation of half of GraphQL, to massacre Greenspun's tenth rule).
How important solving this dilemma is to your application may be a function of your team or system topology, and the type safety that GraphQL happens to come with is a nice bonus, but this dilemma is the crux of things.
End to end type safety that's better than REST and even stronger than others like gRPC by using the Result type, see my comment for an example: https://news.ycombinator.com/item?id=37125685
An endpoint that fetches exactly the data it needs for an entire application, never over or underfetching.
Independence between the frontend and the backend, as the backend can implement resolvers for a certain piece of data and the frontend can then query anything that contains that data without waiting for the backend to implement a specific endpoint with that data.
Seriously, GraphQL (when used correctly with Relay, rather than Apollo) is among the best developer experiences I've ever had.
