Depends on how you are going to implement both serving and fetching GraphQL.
Backend: define the whole schema and resolvers many vs something like KeystoneJS?
Frontend: define all queries and types and whatnot manually, or use some adapter with a layer like https://refine.dev/?
A lot of trade-offs.
If I don’t need to build higher-level abstractions on top of the API, I’d always roll with ad-hoc REST. :slightly_smiling_face:
Also, is it just an API for your own needs or I expect it to become public at some point? The answer has a huge effect too. People would hate you if you only have GraphQL, imho.
writen by Kirill Rogovoy
I don’t know all the details, but I’d roll with REST by default. It also means that the barrier of entry for others is lower.
If other devs will be implementing it, I’d look into their experience first and consult with them if possible. Maybe they are GraphQL ninjas.
writen by Kirill Rogovoy
If you don’t know GraphQL really well, you should stick with REST API. GQL can become really mess after some time. 3rd alternative is TRPC
writen by Dobroslav Radosavljevič
Also really depends on use-cases. Big companies use GQL because they have experts focusing only on it.
We use GQL at my work and it’s mess for me 😊 I really like REST
writen by Dobroslav Radosavljevič
Tha ks for the feedback Dobroslav Radosavljevič. I like to learn on the job though. So if it would make sense I would like to try it and learn it. So does GQL replace rest? Is the idea for the frontend to communicate with the DB with GQL without any intervention of a Rest API?
writen by Tiago Ferreira
Yes, it’s complete replacement. GraphQL only uses POST requests to backend to make things happen
writen by Dobroslav Radosavljevič
https://youtube.com/c/TheoBrowne1017|https://youtube.com/c/TheoBrowne1017 I learn a lot from this guy. He worked at Twitch, now he is making his own VC backed startup http://ping.gg|ping.gg
He explains dev things and how they work + compare
writen by Dobroslav Radosavljevič
