Hacker News new | ask | show | jobs
by BrainInAJar 978 days ago
GraphQL is great if you're a frontend developer. REST is great if you're a backend or infra developer (not because of complexity of developing it, because of complexity of using it)

You cannot satisfy both with one tool. Migrating to GraphQL (or choosing it in the first place) will frustrate consumers of it who primarily use your API for things other than writing frontend clients. Using REST will frustrate people who use your API to write frontend clients.
2 comments
chatmasta 978 days ago
GraphQL is great for both. It's a collaboration tool between front and backend. You can design the schema for the resolvers during the RFC phase of planning a new feature, and then both teams can implement their tasks in parallel. And you can use the spec to generate type safe libraries on each side.

We did this with Strawberry in Python for backend (which uses dataclasses for defining resolvers), and TypeScript + graphql-codegen on the frontend. We have fully automated type generation from the backend to the frontend, meaning GraphQL becomes a cross-language, shared type layer. It works great, once you get everything setup. Worth the effort IMO.

link
satvikpendem 978 days ago
> REST is great if you're a backend or infra developer

Not sure about that, we have a codebase that's huge, with 100s of REST endpoints, and the backend engineers simply start writing new endpoints because frontend needs one more specific field, and the backend folks can't be bothered to refactor the codebase for an endpoint that's used elsewhere, as that takes time. GraphQL solves that cleanly by allowing the frontend to request any data they want and for the backend to focus on figuring out how to give back a piece of data if it's requested. No 100s of endpoints required.

link
mannyv 977 days ago
The only reason GraphQL is "better" is it forces documentation.

The fact is, you still need those endpoints, it's just your developers aren't afraid to change the GraphQL endpoints because they're documented. Sometime down the line your developers will become afraid to change the GQL endpoints and you'll have the same, but different, issue.

link
isuckatcoding 977 days ago
Not sure this always happens in practice. I’ve seen lots of redundant resolvers being implemented for the same type at work because someone didn’t know one already existed.
link