(no title)
BrainInAJar | 2 years ago
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.
chatmasta|2 years ago
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.
satvikpendem|2 years ago
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.
mannyv|2 years ago
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.
isuckatcoding|2 years ago