[Seattle3503]

> For me what GraphQL solves as main problem, which I haven't got good alternative for is API composition and evolution especially in M:N client-services scenario in large systems. Having the mindset of "client describes what they need" -> "graphql server figures out how to get it" -> "domain services resolve the part" makes long term management of network of APIs much easier. And when it's combined with good observability it can become one of the biggest enablers for data access.

I've seen this this solved in REST land by using a load balancer or proxy that does path based routing. api.foo.com/bar/baz gets routed to the "bar" service.

[btreecat]

Doesn't even need to be a proxy, you can lay out your controller and endpoints like this just fine in most modern frameworks

[Seattle3503]

How do you do routing across services?

[btreecat]

> How do you do routing across services?

Depends on your infra needs. Could easily be handled by the controller calling out to an external service. Like you do with a database.

You could use a proxy layer, but it isn't a requirement.