Hacker News Reader

Comment by ryanar | Hacker News Reader

GraphQL also allows the frontend team to iterate faster, because they don't need to ask the API team to change an endpoint, or add one. The API team also moves faster, they define the relationships and they are done, no going back and updating endpoints.

GraphQL creates a data graph that powers the UI, REST creates a database that you can query on the UI and you have to compose it all together and manage.

View on HN

In my experience GraphQL slows down all teams. If you're on a new project and that's the stack you pick it can work well for a while but as soon as your product is large enough you get multiple GraphQL api's built by different teams that don't behave in a similar fashion. If you're in an org with historical code now you've got APIs that are RESTful and then some which are GraphQL based. Making those work together is either a hack on the frontend or a rewrite project.

Ultimately the thing that speeds up teams, again in my experience, is predictability not flexibility. If you tell someone they have a RESTful API they know exactly how to work with it, document it, etc. GraphQL which is shiny, new, and used by in-vogue orgs is fine, you can use it to get the job done, but I don't believe that it warrants much praise.

What if you don’t have separate teams, or what if your teams are in the same room? Why do you want your frontend to select it’s own data rather than consuming predefined known quantities? Is this not analogous to type safety? Is graphql not in fact closer to having a database that you query from the frontend, not least of all because it literally has ‘query language’ in the name?

> What if you don’t have separate teams, or what if your teams are in the same room? Why do you want your frontend to select it’s own data rather than consuming predefined known quantities?

Then you don't share many of the reasons GraphQL was originally created for. Act accordingly.

I agree. Sometimes it seems like GraphQL degenerates into a generic REST API where you construct and pass the SQL directly from the client.

Another way to put that is to say that GraphQL is just a way to ship your raw DB schema as JSON. I thought we learned it was bad to shape your front-end code to the mirror the DB schema, sometime back in the early dot-com era.

But the entities, names, dates, and photo URLs in my database are exactly what I want to show on the frontend, by and large. Maybe a join, aggregation, or something in there.

Right, but now when you are deciding on a schema change, your front ends clients are going to break because you didn’t create an API, the just allowed db querying from the front end.

Web API contracts are primarily routes and request/response data structures. This allows front end and backend concerns to be separate which allows a lot more flexibility over time for both front end and backend developers. From my limited knowledge of GraphQL, this is still possible but more work than just exposing your db schema types/DTOs.

At my last place the "product" team owned the clients (website, app) and the GraphQL layer, and the "platform" team owned the business logic just beneath the GraphQL layer (it happened to be in monolith though, so the boundaries between teams were intentionally fuzzy).

You do realize other patterns exist where the frontend team is largely in control of the first endpoint, right? Backend-for-Frontend is one such pattern, although I'm sure that is nothing new either.

> because they don't need to ask the API team to change an endpoint

Bollocks. What happens is you need some field implemented in the microservice or DB that your GraphQL layer talks to. This task gets tossed into your ticket system, gets managed by half a dozen managers, and weeks to months later you finally get the field you need and can finally bubble it up through your fancy toy API.

> GraphQL creates a data graph

does anyone even know what a graph is today? Serious question.

This seems to throw up the issue of a higher degree of the DB structure getting exposed to the frontend. Faster iteration of the front-end (presumably during a period of more rapid change) comes at the cost of forcing the backend to remain more static.

That seems like a fair trade-off to the oft-seen alternative of the front-end remaining more static because of slow iteration of the back-end, in the sense that I think that there are many situations in which that would be the least bad option.

How many features do teams tend to build that use exclusively existing data, versus new data? How much existing data is lying around that isn't already exposed via API?

I'm not sure that the query layer solves team collaboration and prioritization problems.

Redesigns, UX changes etc, will all change how a UI interacts with data but won't necessarily require any changes to the underlying data model.

Adding brand new capabilities to a system (or refactoring existing ones) will usually requires changes to the GraphQL layer, but this is only a subset of frontend work. Iterating on what already exists also represents a lot of development time.

Reply on news.ycombinator.com