Ask HN: GraphQL Performance Issues, Am I the Only One?

Posted by bruchim on Tuesday April 09, 2024 @02:10PM
from the ask-hn dept.

We've recently made the leap to GraphQL for our APIs, attracted by its promise of more efficient and flexible data retrieval. The initial transition was smooth, and the benefits were immediately apparent. But, we've since hit a bit of a snag concerning performance.

We already implemented some of the recommended practices, like data loaders and simple expiration-based caching, but we're still in search of that significant breakthrough in optimization. The improvements, while beneficial, haven't been the game-changer we hoped for.

Does anyone talk about the elephant in the room? our app performance sucks, we need help.

Any insight? advice?

( 7 comments | on HN )

Re:Ask HN: GraphQL Performance Issues, Am I the Only One? by uberman on Tuesday April 09, 2024 @02:51PM (#39982782)

From our experience graphql made semi technical users more productive from a query perspective but at a cost of literally everything else. Data loading, security, schema building, responders, performance, n+1, and on and on.

We would never do it again if we could.

[ Parent | on HN ]

Re:Ask HN: GraphQL Performance Issues, Am I the Only One? by bruchim on Tuesday April 09, 2024 @02:52PM (#39982796)

Specifically about performance, have you tried to solve it with any caching mechanism or any other out-of-the-box optimization?

[ Parent | on HN ]

Re:Ask HN: GraphQL Performance Issues, Am I the Only One? by uberman on Tuesday April 09, 2024 @04:54PM (#39984127)

We tried a number to cache solutions including those baked into AWS dynamodb but nothing worked correctly for us. We were never able to get resolver specific cache with the correct parameter granularity working correctly.

[ Parent | on HN ]

Re:Ask HN: GraphQL Performance Issues, Am I the Only One? by bhaney on Tuesday April 09, 2024 @02:17PM (#39982393)

It's impossible to give you advice on performance improvement without knowing why your performance sucks, and that's not a conversation that's reasonably going to happen here. I can't even tell from what you've posted if migrating to GraphQL degraded your perf and you're looking for a solution to get it back, or if GraphQL improved your perf but not as much as you wanted.

Ultimately if your app performance sucks and you need help, then hire people who can help.

[ Parent | on HN ]

Re:Ask HN: GraphQL Performance Issues, Am I the Only One? by bruchim on Tuesday April 09, 2024 @02:49PM (#39982768)

We are using Apollo on top of our Postgres db, which is also used for other CRUD REST APIs.

I'm basically looking for more perspective of other teams, if they are feeling the same after migrating to graphQL (the same query in simple node + SQL ORM took half of the time), and if there is something that helped them solve these problems.

e.g. caching graphql is not as easy as caching GET API, something that I didn't know before.

[ Parent | on HN ]

Re:Ask HN: GraphQL Performance Issues, Am I the Only One? by amtamt on Tuesday April 09, 2024 @02:28PM (#39982524)

> We already implemented some of the recommended practices...

Looks like these recommended practices did not include benchmark the queries and DB for the workload. And 99.99% there was no person with performance engineering mindset was involved (or was/ were completely ignored)

[ Parent | on HN ]

Re:Ask HN: GraphQL Performance Issues, Am I the Only One? by bruchim on Tuesday April 09, 2024 @02:43PM (#39982691)

TBH, I summarized here almost a year of a process into a single paragraph, maybe it's my bad. A few engineers with good performance minds have already benchmarked and improved some of the queries, and we learned a lot from the process.

My general feeling is that for the average developer, graphql can lead to some serious performance issues, and I wonder if it's just my experience or we are doing something wrong.

[ Parent | on HN ]