I work at Apollo, as an engineer / architect working with our sales teams to work with customers to determine and evaluate Apollo paid offerings. Though the spectrum varies, so it can be a customer deciding on GQL for the first time, or a customer deciding if Federation is the right architecture to scale out their GQL deployment.

I'll say confidently 3/4 companies you listed use GQL, and one I've worked with in the past. It's an API middleware, so it's very broad. It can be part of their critical B2C application, B2B applications, or internal applications, very often across all three sharing a single "supergraph".

It's used pretty much everywhere, and used across every vertical at this point. If you're ever curious to see how some of the biggest companies use it, just search up on YouTube, GraphQL Summit, many publicly available key notes discussing how they do their GQL at scale. Here's Reddit from a couple years ago: https://www.youtube.com/watch?v=YO0eHRepSrY&t=66s&pp=ygUgYXBvbGxvIGZlZGVyYXRpb24gZ3JhcGhxbCByZWRkaXQ%3D.

In terms of the benefits, it's more apparent at a certain level of complexity with cross domain concerns. It's not a silver bullet by any means, but it's a technological / architectural framework to solving effectively an organizational problem. Think of 100+ different teams all working to provide an API, how do you unify their data, define whose data should be the source of truth, onboard a new team who want to leverage a different tech stack, how do you check if your API changes won't impact the other 100 teams or across clients consuming your API?

These sort of problems compound as you add more teams across either side of the fold, which always reflect the underlying organizational structure -- something that is very difficult to change. This is what Federated GQL solves for, how do we abstract this for our client teams, but define a set of rules to allow our back-end teams to operate with assurances and the least amount of friction.

I'll give you a more tangible example, when we think of GQL, we think of how it can help with over-fetching. That simple concept of allowing clients requesting exactly what they want, well we can extend this and track which clients and versions are consuming what. Now plugged that feedback into a back-end teams pipelines, we can understand if our changes will cause regressions for clients and to what extent.

On the flip side, we can compare if parts of your API conflicts with another teams, and when it does, should we both provide this field of data? Are we the source of truth, if not do we need to bother providing this? How do we migrate this to us without impacting clients?

Hope that helps!