Would anyone recommend GraphQL over REST for teams just starting up?

Question

I'm working with a team building out our first MVP, which is a basic iOS App with about 12 screens. So far, we have built out REST APIs (about 15 APIs support our entire MVP). We are now moving toward building a v2, which is a significant change and we were wondering if we should consider GraphQL (with Hasura) instead of REST. Has anyone been in a similar situation and decided between these options? How did you make your decision? What were the parameters you evaluated?

injb · Accepted Answer

I would be inclined not to. IMO GraphQL is great when you have a frontend team that wants to make changes without requiring a new backend build. If your team isn't structured that way (i.e. you have full stack devs and/or very frequent, low overhead backend releases), or the nature of the changes is that they frequently don't require backend changes anyway, then I would just stick with REST.

linkdd · Answer

GraphQL shines when your data model is already a graph, when you have polymorphism and expose nodes/edges and follow the "Relay" pattern.
But it shines only for the frontend. It is a nightmare on the backend to implement efficiently.
Then, you have Hasura, which will compile the GraphQL request into an SQL request. Hasura provides a REST-like schema with GraphQL syntax. At that point, just stick with REST.

tusharmath · Answer

Yes, that is the best time to build a GraphQL API. It will save you many hours later. Like it or not, eventually if you are building a mobile app, you will move to GraphQL eventually. It's a massive pain to do it when you have everything running. GraphQL will save you from embarrassing errors on the client and improve performance for sure. My recommendation is &mdash; Build API and expose them using REST or GRPC. Use a solution like https://tailcall.run/ to create a GraphQL facade on top of it for your clients to consume.

GiorgioG · Answer

No. Just don't do it.