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?
Ask HN: Would anyone recommend GraphQL over REST for teams just starting up?
1–8 of 8 posts
Re: Ask HN: Would anyone recommend GraphQL over REST for teams just starting up?
#2No. Just don't do it.
Re: Ask HN: Would anyone recommend GraphQL over REST for teams just starting up?
#3Yes, 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.
Re: Ask HN: Would anyone recommend GraphQL over REST for teams just starting up?
#4Yes, 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 sol…
At least put a disclaimer that it's YOUR SaaS you're recommending.
Re: Ask HN: Would anyone recommend GraphQL over REST for teams just starting up?
#5GraphQL 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.
Re: Ask HN: Would anyone recommend GraphQL over REST for teams just starting up?
#6I 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.
Re: Ask HN: Would anyone recommend GraphQL over REST for teams just starting up?
#7Yes, 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 sol…
At least put a disclaimer that it's YOUR SaaS you're recommending.
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 :)
Re: Ask HN: Would anyone recommend GraphQL over REST for teams just starting up?
#8Earlier quoted context omitted.
At least put a disclaimer that it's YOUR SaaS you're recommending.
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 :)
Which facts are you stating? Nothing but opinions and promoting your own solution.