Hacker News Reader

Comment by kodablah | Hacker News Reader

Con: Unpredictable code paths (at least in complex use cases).

I've seen so many times GraphQL implementations or ad-hoc equivalents with user supplied property and filter requests, that regret giving the caller so much flexibility. IME, flexibility is a bad thing because in the API world, often once you cross a feature bridge, there's no going back. I say be very restrictive in your API for many reasons. And for that UI use case, I disagree with a complete client-side/server-side dev separation. Unlike data APIs, backend data requests for frontend use should be tightly tailored to what is used. GraphQL is just another way to forget what you've exposed and also allow clients to hit never before seen code paths to your backend. There are security, bloat, and maintenance concerns...keep the UI backend thin and light and inflexible and strict and limited yet agile and volatile and you'll be so happy you did a couple years down the road.

View on HN

None of these problems are GraphQL-specific though. Say someone wants to build a feature that requires some attribute or joined model we weren't exposing before. Maybe someone else tells them no for all the caching/performance/complexity reasons mentioned above. That's a slippery slope leading towards a culture where nothing ever gets done because all the senior engineers default to saying "no" to everything, which isn't a place people want to work and probably isn't great for the longterm outlook of the company.

So assuming the feature is going to get built, the implementation might involve sticking the extra attributes in an existing route, or might involve creating a new custom route just for this use. Both of these options have pro's and cons that need to be weighed in the given situation based on usage patterns. And both are possible with or without GraphQL. But they should require just a few lines of configuration in GraphQL vs more lines custom boilerplate code in your controller in a traditional MVC framework, which is a nice win for GraphQL.

The problems can arise whenever people start thinking some tool is basically magic where there's no wrong way to use it and it'll solve all your problems, instead of thinking criticially about how to use the tool and what tradeoffs involved. And this tends to happen much more easily with a hot, new tool like GraphQL than a more established one where people have more experience with the downsides.

> That's a slippery slope leading towards a culture where nothing ever gets done because all the senior engineers default to saying "no" to everything, which isn't a place people want to work and probably isn't great for the longterm outlook of the company.

No, and thinking in absolutes like this is what green lights extreme flexibility exposed to the public internet.

In general, all query possibilities from the public internet should be accountable and eagerly tested/auditable. And don't let complaints about stodgy seniors or flexibility make you do otherwise, development efficiency and tight public internet predictability are not mutually exclusive.

Again, to put it simply, it is very rare to need extreme flexibility in publicly accessible APIs. And articles like this one foolishly refuse to make that clear. In the meantime, super flexible data access schemes are lauded for their help to client side developers, scary. The org can be tightly integrated, don't let the ridiculous idea of having some devs not allowed to do any server side code force these loose-lipped systems on your users.

There are graph ql build systems where you can generate a list of queries used on the frontend, which should help with your concerns over total flexibility, while still allowing easier use of new queries.

If the frontend can use the API, can I, the guy with a curl command or headless browser, use it too? How are you generating that list of queries from my machine? Unless the surface is sufficiently small to get all permutations at which point no prob, my issue is with flexible GraphQL systems.

> If the frontend can use the API, can I, the guy with a curl command or headless browser, use it too?

No.

> How are you generating that list of queries?

I believe the queries in the device UI code are replaced with identifying hashes as part of the build and those prebaked queries are deployed to the GraphQL server.

> Unless the surface is sufficiently small at which point no prob, my issue is with flexible GraphQL systems.

This is still as flexible for UI developers since this is simply a build time optimization / limitation.

For publicly accessible GraphQL APIs I believe the common approach is to calculate a cost for the query and limit what users / queries can do that way.

In the case of turning flexibility at compile time to a fixed set at runtime and the server side only accepts that fixed set, I'd say that's definitely a lot less of a concern than the literal GraphQL queries I've seen in use at runtime by UIs. At that point, your only major concern is how many of those devs use those sans review by person familiar with the storage that could optimize it. After that, your fixed hash request hasn't improved things from a runtime standpoint over a fixed URL request. The disappointing internal team segregation that makes this a required path to go from actual query and programming languages to pseudo ones is concerning.

But for that common approach for APIs you mention, that cost calculator is a bit scary vs limiting the caller. Now if you're a big shop and you need to essentially expose a query language, ok. But for most, the flexibility is really not necessary and bites later with all the possible combinations of requests.

> But they should require just a few lines of configuration in GraphQL vs more lines custom boilerplate code in your controller in a traditional MVC framework, which is a nice win for GraphQL.

If it's a few lines of configuration in GraphQL, it's going to be a few lines of configuration or code in the "traditional MVC framework".

If it's a lot of code in the "traditional MVC framework", then it's going to be a lot of code in GraphQL as well.

The issue with using terms like "traditional MVC framework" is that you will have a hard time making statements that apply to all.

> That's a slippery slope leading towards a culture where nothing ever gets done because all the senior engineers default to saying "no" to everything

They can just say no to GraphQL then. You shouldn't be mixing culture/politics and technology arguments in one context.

”But they should require just a few lines of configuration in GraphQL”

…assuming the presence of the equivalent of a complete enough SQL engine in the server, and often not even then, because adding a new stored procedure that can be called may mean extensive rethinking of the indexes you maintain, the way tables are partitioned, etc.

This. Nearly every GraphQL schema I've seen is a logical representation of the domain, just like how we typically approach schema design in OO apps. This is probably fine in many contexts where your GraphQL endpoint is consumed by other internal services.

However, if your GraphQL endpoint is used by consumer/public/external clients I feel like we need to give everyone permission to make a Schema matching the View Model, not the Model (proper). In practice GraphQL works quite nicely as a layer to translate the model proper into the view model. This makes MVVM much more attractive for SPA's than in object->relational worlds prior.

Another PRO of strict APIs is that they're dead simple to cache. Tons of customization = caching hell.

If you know your queries at compile time, then you can register each query with the server when you build as the hash of the query. Then clients only have to send up the hash and the server can look them up in its registry; plus you now have an easy way to cache (cache based on query hash plus user). If it's the first time you've seen a query, you can hash it and add it to the registry as well.

See: https://github.com/apollographql/apollo-link-persisted-queri... https://blog.apollographql.com/improve-graphql-performance-w...

I know about apollo caching, but it's strictly inferior to HTTP caching which has tons of options (Vary, Etag, etc)

Caching per user is still going to mean tons of cache misses. Caching based on the query hash means you're going to cache subsets of the same data over and over as separate entries.

With resources over HTTP, you can separate the user specific part from the generic resource part and cache accordingly.

Plus, I like the option of caching somewhere else than the app server, like a distributed Varnish.

I'm not saying you can't cache with graphQL, it's just less natural and mature.

In practice, caching is non-trivial to implement for any sufficiently complex system even with REST. It depends on your use case of course, and how tolerant you are of stale data, but I have worked on very few frontends where HTTP caching is sufficient.

These seem like concerns that GraphQL backend implementations could address. With sufficient limitations on things like query size, nesting depth, and number of entities requested, it seems like you could have reasonable confidence that no pathological queries are valid.

Security doesn’t seem like a problem unique to GraphQL. Traditional REST APIs also need to be just as careful about authentication and access control.

> With sufficient limitations on things like query size, nesting depth, and number of entities requested, it seems like you could have reasonable confidence that no pathological queries are valid.

Rarely good enough and in general a dangerous mindset that just adding layers around is an acceptable solution to essentially giving the world a query builder (internal use only is different of course).

> Security doesn’t seem like a problem unique to GraphQL

It's about surface area of permutations as much as the data. Sure you can auth property paths, but many GraphQL setups can be gamed by malicious callers to strain systems in ways you never expected those client side devs to do when you gave it to them. If the only reason for this flexibility is because they can't be bothered to do a bit of server side tailoring, you have a dev fragmentation problem and a vertical integration problem that will cause security concerns one day anyways.

I don't know, I've seen lots of REST APIs that have similar levels of query configurability (albeit without the predictable syntax of GraphQL). It's certainly not uncommon for REST APIs to support params for sorting, filtering, and including related entities (i.e. joining), at which point you could just as easily open yourself up to dangerous queries as you could with GraphQL.

Most definitely and I allude to them in my initial post because it's basically the same problem. Can't get rid of all parameters in all cases of course. Of the common configurability options I see in REST APIs, the ones that affect queries in the most complicated way is the customizable inclusion of extra relational properties.

> Rarely good enough

That's baloney. GraphQL can have just as locked down code paths as any non-GraphQL API. Facebook does exactly this.

I never said they couldn't. What's baloney is pretending FB's approach towards GraphQL is replicated by all. Anyone that's seen the tech deployed in multiple places (and equivalent systems) has seen the cavalier attitude with which data can be accessed with seemingly infinite unique combinations. And it's especially true if you revisit them after some time to see they often grow, but rarely are paths or properties deleted. Sometimes it's due to API compat guarantees, but often it's due to the ridiculous divorce between actual client side usage and expected server side usage.

That you can do it right is not at issue, it's whether you do, and over time IME it's unaudited data proliferation and even when data is controlled, often unaudited permutations of all the possible queries that can be built.

Actually this is quite false. GraphQL queries are deterministic and Apollo offers great tools for query analysis.

For example the Github GraphQL API has a restriction on the amount of nodes an unauthenticated requests can query. Because of the deterministic nature you know the query complexity before execution time.

As a result you can come up with simple to implement mechanisms for restricting query complexity. This is far superior to any mechanism I have ever seen in REST APIs which are inherently far more restrictive because of the limitations of the design and much harder to predict. e.g. it's easy to exploit O(N) DOS type attacks in REST APIs that expose queries that are relational.

GraphQL supersedes REST in every way. For those who haven't realized that yet are simply missing context or experience.

> Actually this is quite false. GraphQL queries are deterministic and Apollo offers great tools for query analysis.

What is false? Who said anything about determinism? Unless by deterministic you mean the ability to tell the future about what will be called. I'm talking about giving clients the flexibility instead of having predictability in the call. I'm saying that flexibility has costs especially as systems grow. It's not just GraphQL, lots of systems that are essentially query languages serialized to HTTP requests have this problem. Whether, once you know the call it's deterministic, or whether you can theoretically map all permutations doesn't absolve the practice of giving the clients so much free will.

Time the queries out after X seconds. Limit people to X seconds of query time each hour.

idd, better pattern to use is: backend for frontend https://www.thoughtworks.com/radar/techniques/bff-backend-fo...

BFF anti-pattern is a superlinear explosion of surface area to maintain. I agree with you that GraphQL does not actually fix it when backed by any mainstream database. If you solve this, you don't need to write backend boilerplate anymore, the whole thing can be done as an abstraction and you can fire the web developers. No clear answer has emerged yet. I think Datomic (c-f this thread) can be used as a basis to fix BFF anti pattern.

funny. BFF is not an anti pattern. number one it is a pattern. it makes sure the frontend code is minimised. if you want to maximised frontend sure go ahead don't use BFF. but there are scenarios where you do want to minimise frontend code. for example when you have multiple frontends with different languages and code bases.

The holy grail (and goal of GraphQL) is one general purpose backend maintained by N engineers. Backend-for-frontend is M backends maintained by M*N engineers. This is why Google employs thousands of engineers.

yep. you can still have it with the BFF and GraphQL pattern. Since both would use the same general purpose services. the key difference between GraphQL and BFF is, the GraphQL service itself is general purpose. hence the biz functionality resides in the frontend. With the BFF pattern you try to move as much as possible of biz functionality into the backend.

Reply on news.ycombinator.com