>The problem with these increasingly expressive end points is that you are putting them not just in the hands of your front end developers, but also in the hands of potentially hostile users.
Meaning, let's not expose to 'hostile users' if we can help it.
For example, put the API gateway solely on a private overlay, and gate entrance to that overlay to endpoints with enrolled private key signed certs (+ other factors if you wish).
Puts more burden on the API clients - e.g. PKI enrollment, management, etc. would need to be reliable, automated and abstracted.
So infeasible or too much friction for some APIs, but this would reduce the attack surface for a B2B API with a limited number of consumers...and many of those would take that tradeoff?
Of course, we still wouldn't 'trust' the private network overlay in our API definitions...it would just be one more layer of security if access is gated with modern cryptography.
Too painful ? It is just regular TLS
TLDR: there is a trade off in how much expressive power you can surface to front-end developers when their logic is written in-browser because anything you give to them, you give to anyone who can open up a console. That makes things a lot more dangerous and is in contrast w/ the back end, where you can give developers access to a full SQL implementation.
You can give a back end developer SQL, because the users of your application don't also get SQL. Not true of GraphQL.
