HN Explorer

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

2 points by ksaxena ↗ HN
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?

7 comments

[ 3.8 ms ] story [ 33.4 ms ] thread
tusharmath
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 — 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
At least put a disclaimer that it's YOUR SaaS you're recommending.
tusharmath
It's open source and free. Use it if you like what it offers.

Disclaimer: I am not promoting it, I am just stating facts :)

GiorgioG
Which facts are you stating? Nothing but opinions and promoting your own solution.
linkdd
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.

injb
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.