HN Explorer

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

1 points by bruchim ↗ HN
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

[ 3.0 ms ] story [ 23.4 ms ] thread
bhaney
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.

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

amtamt
> 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)

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

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

bruchim
Specifically about performance, have you tried to solve it with any caching mechanism or any other out-of-the-box optimization?
uberman
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.