Hacker News Reader

Comment by Philip-J-Fry | Hacker News Reader

>If anything I think the biggest problem with GraphQL is that, if people just saw it is a simple alternative to REST, with a well defined set of query (GET) and mutation (PUT/POST/DELETE) endpoints, they wouldn't get caught up in all this "infinite object graph" stuff that I never hit in my day-to-day.

But isn't this "infinite object graph" like the only real valuable part of GraphQL? People get caught up on that because all the other things you mention aren't really an issue with normal REST API.

If you're saying you use GraphQL but don't use the key defining feature of GraphQL. Then what's the point of using GraphQL if you're just using a strict predefined set of things you can query/mutate?

View on HN

Value of GraphQL imho is the ability for the api to be driven by frontend requirements without bothering the backend guys "to expose that one field in that one query".

Once the app is developed I think you might put up reasonable general limits to what queries are responded to in a general manner over the whole api.

So you move the issue to the resolver instead? IMO graphql is trying to allow the frontend to be the 'driver', the first bit; otherwise you just have the backend publish an API and then that is what it is, if that one field is available from a different endpoint than the one you're currently using, that's the one you need to hit (as well), tough.

Not to say either way around is inherently better, I just see it as a switch from backend-driven to frontend-driven.

(Personally I'd love to use something like OpenAPI, with tooling more mature than probably exists, to be properly schema-driven, with both backend and frontend stubs/clients derived from that.)

> So you move the issue to the resolver instead?

Yes. Where it can be logged, inspected and dealt with wholesale.

It's moveing a problem from intra-team verbal communication into software where it can be dealt with more efficiently with software tools and methods.

> Not to say either way around is inherently better, I just see it as a switch from backend-driven to frontend-driven.

Yes. I think that's the whole point and main benefit of GraphQL which makes a lot of sense since apps that evolve through their development usually have most changes UI driven.

> Where it can be logged, inspected and dealt with wholesale.

Just as it could be in the backend? I don't follow that point.

> apps that evolve through their development usually have most changes UI driven.

That's a fair point certainly, but isn't completely generalisable - if you offer a third-party API at all (or think you might) then maybe don't special-case your own frontend.

> Just as it could be in the backend? I don't follow that point.

GraphQL server is the part of the backend.

The problem is that client has a new requirement, it is verbally communicated through UI change request. Frontend team implements the change then has to make a verbal request to the backend team for new data to be exposed. There's a bit of back and forth, testing. Everybody waits for everybody. It all takes time and is most of the time brainless busywork. GraphQL makes it so that request to the backend team doesn't need to be verbal (jira is same as verbal for me). It can be mediated through software and even fulfilled automatically if the GraphQL server is open enough during development. The cost of that streamlining is that at some point security or performance issues might arise, but those then can be dealt with solely by the backend and db team, as they should be because frontend is always insecure.

> if you offer a third-party API at all

For one such app 99 have both server and the client developed in sync.

And even then with offering third party api I think it's way easier to fall into the trap of special-casing your frontend with poorly designed REST than with GraphQL, althought there might be performance and security challenges as there always are with anything public. So there might be a bit to learn about how to deal with that in GraphQL ecosystem.

> It can be mediated through software and even fulfilled automatically if the GraphQL server is open enough during development.

You pretend that GraphQL is magic.

If there's requirement not exposed by the GraphQL server, the way to add it is literally exactly the same as for any other backend API.

Sure. But it's magic enough for me if I don't have to create a ticket for adding existing database field to a DTO every single time.

So you've reached a point where working together collaboratively is such a burden that you've adopted technologies to circumvent that activity.

This suggests that GraphQL adoption is a sign of impending business stagnation. This does in fact align with my experience around GraphQL.

> So you've reached a point where working together collaboratively is such a burden that you've adopted technologies to circumvent that activity.

On braindead busywork, yes. Please automate everything about it as soon as possible, including communication. I don't want to collaborate on it with a human the same way I don't want to collaborate with a human on my McDonald's order and I prefer to access their ordering software through a kiosk or a phone.

> This suggests that GraphQL adoption is a sign of impending business stagnation. This does in fact align with my experience around GraphQL.

That very well might be. But stagnation understood as predictably churning an app after an app.

In my experience, braindead busywork is largely non-existent. Yes, there are times when you'll have to do something easy that conforms to code requirements and standards. But when the frontend needs to update something that is coming from a server, there is a real opportunity to discover, illuminate, and even solve architectural issues.

Sometimes that solution is to use GraphQL to make it easier to manage client implementation fan-out and requirement diversity. But GraphQL is never a substitute for communication and collaboration.

> In my experience, braindead busywork is largely non-existent.

Lucky you. In corporate environments I worked at it took easily half of the time.

> But it's magic enough for me if I don't have to create a ticket for adding existing database field to a DTO every single time.

It means that those fields are already exposed to you by backend. Had they not been, no amount of magic on your side would make them appear.

This is how I have interpreted its value, and frontend devs have very plainly advocated for its use with this argument. I think this is a really silly value prop.

Behind the elegance of a query language that lets you get your perfect little payload, there is a complex server that could need to resolve and block on requests to multiple backends, touch different caches and databases, and do joins and sorts and projections. Front end devs will add the videoRating field and have no idea that this comes from a separate API and causes the response time to double.

Developing some gragantuan do-it-all meta API as a sandbox for frontend engineers is a terrible idea. You don't just slap a graph over your APIs and call it done. The GraphQL server is orders of magnitude more complex than a purpose-built API.

Ultimately once the FE devs have crafted their query to satisfaction it will hardly ever change. It's better to work together and decide whats needed and how to best get that data to your app.

I really favor collaboration on purpose built APIs than gargantuan do-it-all systems.

> Ultimately once the FE devs have crafted their query to satisfaction it will hardly ever change

this makes the fallacy that it is FE devs driving change. it is not. it is product management. and to them (and indirectly to you), making it easy to make performant changes without 3 committee meetings is a Good Thing

"Driven by frontend requirements" is how approximately all APIs in the world are developed. The problem GraphQL exposes, and makes extremely punishing when you ignore it, is that of poor communication of requirements.

Put it this way: you _could_ build a GraphQL resolver by means of mirroring your database schema or service structure, and let frontend engineers play in that sandbox while patching up holes. This would have the exact same result as building a REST API service that proxies requests to a SOA without understanding the performance or stability impact. Or the exact same result as exposing multiple REST services that must all be hit to render a single screen on the frontend, except you push the blocking to clients, which is not a proper solution if you care about the energy usage you don't pay for.

In all of these cases, the common thread is that the backend and frontend teams aren't working together and thinking of the entire product as a system instead of a frontend/backend split. GraphQL forces you to reason about the entire system and not a series of API calls, which can obviously cause problems with siloed teams.

This means I disagree with folks who attribute the power of GraphQL to "frontend-driven" APIs. Your frontend and backend is your product, so ultimately you must reckon with the boundary layer between the two.

This whole thread makes me happy that at my job we don’t have this arbitrary backend/frontend split. Everyone on my team does both—if you are working on a feature you implement all the parts needed for it. Seems like it avoids a lot of this coordination hassle.

Of course some people are better at one or the other so for very tricky things we might have them take over those pieces. But 99% of coding is fairly straightforward.

It's neither an arbitrary split, nor is the fact that everyone does both exempt you from this discussion. You are still concerned about this, unless you are doing some desktop app.

> Front end devs will add the videoRating field and have no idea that this comes from a separate API and causes the response time to double.

That's absolutely wonderful problem for the backend and db teams to detect and solve. Cache it, use another data structure, pre-calculate, build cunning indexes, if you can't do anything just throw hands in the air and say it cannot be done. Neither frontend team nor the client does care about backend woes. And frontend team doesn't want to be kept in the game of telephone as backend negotiates solutions for performance with the client.

That's what GraphQL does. Provides better separation of responsibilities between the teams and lowers the amount of conflicts and delays because of the reduction of verbal communication necessary.

> Developing some gragantuan do-it-all meta API as a sandbox for frontend engineers is a terrible idea.

It's not a sandbox for developers. It's for the clients. I know it's painful for the backend developers that front end doesn't want to be involved in challenges to the backend caused by customer's requests and how often they change. GraphQL makes those problems owned by backend devs and noone else.

> I really favor collaboration on purpose built APIs than gargantuan do-it-all systems.

Same as with the software itself, well separated parts, clear non-overlapping responsibilities, small, well defind interfaces between the parts result in better outcomes.

This is a problem with siloing front end development, not graphql.

The thing is there are solid, replicable patterns for optimizing graphql. The way we use GraphQL is to expose "everything" to the frontend folks so they can work closely with design until they have a polished frontend for whatever they're building, then our backend folks look at it in APM in Datadog and figure out where to optimize it. Once we have an optimized query, we ship it. Everyone's aware of the basic optimization patterns we use, and backend is a pretty well-oiled machine.

So this completely contradicts your GP post who says the fact that it supports generic queries is not the point of GraphQL.

So which is it?

Generic during development. Once the dust settles you can restrict to what's used.

If you have 1, maybe 2 front ends then this is flat out laziness.

The front end arguement makes sense for someone like Facebook who has many different front ends and integrations. It’s unmaintainable to try do this any other way.

Reply on news.ycombinator.com