Well, that just isn’t true The DataLoader pattern is well known and widely used with GraphQL, and that provides an easy entry point to caching beyond per-query.

That aside … security!

So, the web is, in a word, fucked. It is probably one of the least-well designed set of technologies that is so widely used, and that says a lot as there are some truly bad ideas out there in wide usage. It has such an absurdly large attack surface ranging from client-side code that is dynamically loaded from potentially random locations with little to no sandboxing (so many patchwork bandages to address that have been deployed over the years…) to server-side APIs that are neither protocols nor designed with basic concepts like secure federated authentication / authorization or progressive discovery in mind. It’s a dumpster fire which we collectively limp by on.

Just look at at venerated Internet protocols which offer no API (let alone advertise capabilities!) until authentication is performed. You don’t get “you aren’t allowed to access that” messages, you just don’t get anything at all, socket closed. And even after auth, they will expose different views on its capabilities depending on what authorization follows. This is fairly basic security stuff .. which most web technologies lack.

It isn’t all darkness, though. It’s one reason I love things like LiveView. The user authenticates, opens a socket over which authentication and authorization can be performed and then based on that capabilities can be provided. No peeking, no leakage required.

Before I moved an app recently to LiveView uploads, anyone could find out that there were various upload endpoints. Returning 404’s on incorrect uploads to pretend nothing was there would have made error recovery harder for legitimate usage (aka my own front-end apps!), and even then the latency differences between that and a “true” 404 would probably have been perceptible. Now that everything happens over a websocket and and upload capabilities are only ever advertised to users with sufficient authorization? Yeah, that hole is closed with no hackiness. (.. and yes, I do use rate limiting)

As @dimitarvp noted, GraphQL is a front-end developer convenience (and, given the mess REST APIs can be, and often are, for non-trivial access to hierarchical data, a rather useful convenience), but the world ought to just own up to the fact that HTTP based services do not provide much in the way of security or privacy.

I have serious flashbacks to telnet, ftp, and pop3 … which, btw, were all things alive and going when HTTP was initially designed.

All APIs are vulnerable to this. If you do not authenticate ids, you run into trouble.

Introspection has nothing to do with their issue. The browser network tab is enough to see the API calls being made. They could do this with old school HTTP POST + JSON and it wouldn’t make any difference.

Right, and Absinthe / GraphQL won’t let you send inputs that aren’t the right type or shape either. Swagger, JSON-RPC, etc, none of them have a way at the API schema level to enforce that you are authorized to use an ID. This must be done at the application layer.

If giving away what your API is capable of is a security risk, you have failed some very basic security requirements imo.

It’s like saying your house is more secure if people don’t know whether or not you have a back door.

Having a lock on both your front and back door is what makes you safe.
Any GQL design that is not enforcing a kind of authorization as a parameter on every call going from a resolver to your business layer (for non-public functionality) has most likely been designed wrong.

And GQL certainly solves a bucket load more than ‘frontend convenience’
Off the top of my head:

• Documentation that lives INSIDE your api (Swagger that doesnt suck and is harder to diverge)
• Very easy tool to design api contracts and shape of data before you implement anything in your business layer
• Allows you to think in data more than business actions. That is an insanely flexible feature. It is a lot easier to nail your data shape than it is to up front nail your business exposure. This increases the possibility space for innovation while still adhering to a strict data shape so you don’t get a cancerous beast of an API that falls under its own weight.
• Composability is a lot easier in GQL as the query and mutation submission through a document is a lot easier on the developer than composing REST apis. Even the more modern APIs that supply _self and other links you can navigate by.

A client wanted my frontend dev to build out a big data dump to csv because they were losing track of their master data records. It took him half a day building a big query, collate that into a table view with a simple csv export button.

Building that in SQL (backend) or through composing REST apis (client) would have been a nightmare.

Edit: Graphql is actually so powerful in terms of query composability that I am still using it even though I’m coding liveview, because it’s easier to just re-run a query (as in client doing refetchQuery on webbrowser) than it is to do anything else. So my CUD is talking to the Service (context) modules directly, while all R is done through a Absinthe runner. Works beautiful.

I expose a split schema since we have some external dependants so one Schema is only internal and one is exposed for clients over API. They share all types and enums so it’s super easy to stay in sync.