[SOLVED] Investigate performance of response serialization with nestjs and graphql


I am looking into a performance issue with serialization in a nodejs backend. I would like some suggestions about how to investigate what is happening after that the app logic in the service has returned its response.

Currently there is a bad query executed with typeorm that returns about 12000 rows. The speed of this query is not a problem, but when the result is returned from the service, it takes about 100 seconds for the api to actually return the response. The application is using nestjs with graphql as api.

I guess that there is some heavy serialization done either in apollo server or in nestjs. How do I investigate this further? And is the large size of the database query the only issue here, or could it be something else?

The real problem here is that this is blocking the event loop of nodejs for about 100 seconds, which freezes the whole backend.


By console log debugging I discovered that typeorm was not the problem. The most time was not spent in typeorm, not even in the service or the resolver either. The most time was spent somewhere after the return of the resolver which lead me to think about apollo server itself.

When trying to return from the same service but using a regular rest controller instead, it only took about a second. What I ended up doing was to use JSON.stringify on the response data within the resolver and then just typed the graphql response as a string. For this particular case it was fine since the data was quite isolated from the rest of the system anyway.

The issue was probably within the part of apollo server which validates the typing of the returned data, but that is mostly a guess.

Answered By – rablentain

Answer Checked By – Cary Denson (BugsFixing Admin)

Leave a Reply

Your email address will not be published. Required fields are marked *