Folks using GraphQL in their stack, I have questio...
# tribe
s
Folks using GraphQL in their stack, I have questions. Our team has been pondering over migrating to graphQL from traditional REST Endpoints, but we aren't convinced why should we do it. We have read blogs, watched videos but have't found a strong reason. So, if you have already migrated to GraphQL from REST 1. What made you do it? 2. How does it help you in a way traditional Rest Endpoints could not?
e
• There won’t be problems with API spec mismatches as always there is only one endpoint. • Easier to manage than REST IMO once you get the hang of it. To elaborate multiple people working on REST services can end up becoming messy with too many endpoints and duplicate endpoints for the same functionality. It would not be the case with graphql. • Client side code doesn’t need to worry about the endpoint specs.
f
Issues with having just REST • As your app size grows, REST payload would grow too which will impact how fast your app gets hydrated on client side. • Response structure often gets duplicated in terms of implementation. Advantages with GraphQL • One of the biggest advantage that frontend gets is that they get to decide what they need from backend (by defining query with only fields they need), this leads to significant reduction in payload size. • Most GrqphQL plugins for frontend web frameworks come with built-in state management so you can skip on writing state management logic entirely and just rely on GraphQL. • A resolver implementation for a certain connection can be plugged in to any other resolver without thinking about internal structure of it (less possibility of breaking existing apps using the connection). I like REST a lot (and it isn’t going away anywhere), and I think that if your engineering costs permit, both REST and GraphQL can co-exist.
d
Caching and query performance and tuning need a lot of work with GraphQL btw. Things have improved over the years, but it’s still something that you need to spend time on and understand
➕ 3
but we aren’t convinced why should we do it.
then don’t do it? It’s primarily useful for frontend and if you have web app and mobile app etc that need different requirements and you don’t have to build separate set of endpoints for each. Or if you think your customers will benefit from it - but a lot of customers will expect REST anyway.
f
Caching and query performance and tuning need a lot of work with GraphQL
Yes! Query complexity can quickly go out of hands. 😬 I won’t say it is hard to work with but something to be cautious about.
h
Agree with the caching point by Manoj. You could look at GraphCDN for that. I've personally been looking into trpc.io a lot these days and have enjoyed using it but it only really makes sense if your entire stack is js/ts.