I feel like this is a bad take: I’m not sure what your experience with graphql is but your comments about Netflix strike me as naive. I think there is a simplif

I feel like this is a bad take: I’m not sure what your experience with graphql is but your comments about Netflix strike me as naive. I think there is a simplified version of Netflix that doesn’t do eg recommendation or history or different contracts in different countries and so on, which is maybe just a few api calls, but I don’t think that’s what Netflix is. And are they actually reinventing the wheel here? I thought graphql was a Facebook thing. Maybe you meant to say that they are rewriting systems pointlessly but it (also) feels like a bit of a generic criticism that is easy to apply to companies for which in-house systems make sense. (Edit: it’s not even like this is a graphql vs rest change as Netflix have had graphql for years and they have a custom api system that seems a lot more like graphql than it does rest) I’m curious what you think the best advantages of graphql are, particularly for a larger company like Netflix? I would guess: - reduces coordination/contention between different frontend/backend teams (eg there are many clients – desktop, mobile, various smart devices – but maybe other front ends too like something customer support might use). - cuts down on ‘boilerplate’ api work. For example, maybe you have some property X of each item Y in your catalog, but which you don’t get on the request for the catalog, and that you want to display this now (maybe it’s some new experimental feature you need to thread through from some database table to the front end). You need to choose between adding X to the catalog (potential version woes…) or managing a bunch of requests for X for each Y (risks being slow or bad in a few ways), or add some non-restful api endpoint that takes a list of Ys and gives you their X properties. With graphql you need to teach the backend how to get X of Y but the frontend only needs to change the query. - it potentially lets you apply access controls in a more straightforward way. If someone is from the US, maybe there are some shows they can’t see. In that case we probably want to hide all records in results about shows they can’t see. (Alternative example: various properties of other people’s accounts). If you have many separate api endpoints, it feels easier to me to accidentally screw up on one of them. I’m not really very familiar with graphql but the middle option is the most compelling one for some of the things I work on (which are nothing like Netflix). One assumes that some people from Netflix had reasons for graphql and I’m interested in what they were rather than some imagined Venn diagram with the current api in the ‘not invented here’ area and graphql in the intersection of ‘invented here’ and ‘not yet a thing we have’. I’d also be curious to see how well it works out for them over time – perhaps they’ll regret it but maybe not for the reasons you oppose graphql; if there are organisational problems (like some team becoming a big new bottleneck or some teams being unhappy about it being ‘forced on them’), they can be hard to write about.