And yet – Apollo advertises its easy Python interoperatibility right on the front page, as one of the features that makes scaling easier.¹

GraphQL arguably makes decoupling frontend and backend languages even easier than classic REST APIs, since the GraphQL schema can serve as single source of truth across language barriers.

¹ https://www.apollographql.com/blog/graphql-python-api-comple...

OK, let's unwrap that:

> And yet – Apollo advertises its easy Python interoperatibility right on the front page

Yes, absolutely, there is great support for GraphQL in many different languages.

> , as one of the features that makes scaling easier.¹

To be clear, that is your own commentary and I didn't see anything in the Apollo site that said implementing in Python makes scaling easier. I.e you seem to be implying that somehow implementing in Python is better for scaling, but there is no background to support that.

> GraphQL arguably makes decoupling frontend and backend languages even easier than classic REST APIs, since the GraphQL schema can serve as single source of truth across language barriers.

Yes, I totally agree with that. If you are, say, providing an API to other developers GraphQL is a great choice for a number of reasons, one of which is that there is great language support across pretty much all languages.

But if you are starting a project within a company, and have the luxury of choosing technologies, having the same ecosystem on the front and back ends makes it much easier for people on either team to go across that "boundary" if necessary. This is not just me hypothesizing. For the majority of career, which really started right when web apps started taking off, there was a separate language on the backend (Java for the majority of my career, but also sizable stints where Ruby and Python were the backend languages). Yes, most backend folks understood JS and CSS, and most frontend folks could understand the backend languages, but it was still a huge barrier to people being able to contribute across teams such that it rarely happened. It's only in the past couple of years where I've been in a "TypeScript everywhere" org where I've seen the gigantic change in the team dynamic that this allows.

On the other hand I've seen JavaScript everywhere slow down back end development and increase costs with not much increase in contributions across teams.

I've seen the same. It starts off faster and then as the business grows and features are added the problems scale up. Some symptoms I've seen on projects I've been asked to look over include but aren't limited to throwing Redis around when an in-memory structure would normally suffice because Node is too slow, scaling to 200 CPU's and using up at least 200GB gigs of RAM for a single servioce, when a 25 instances with 8 CPU's, 25GB of RAM could do the same job and cost a lot less, scared to write their own data structures/algo's that may be required as their business scales, etc.

I dunno if it’s even easier than REST given that an OpenAPI spec does the same thing without the scalability concerns of GraphQL

> without the scalability concerns of GraphQL

I hear about this dreadful "scalability" problem with GraphQL and N+1 queries and all other sorts of geysers constantly, but I see a lot more success stories than failures.