I have a custom resolver in my Slash GraphQL DB. It simply executes a REST call to my image signer API that takes the file name, requests a signed URL from google storage, then returns the signed URL. This whole thing shouldn’t take a lot of time or resources… but it feels sluggish.
Now… I’ve already tracked down some performance issues in my signing API and I’ve deployed serverless in Cloud Functions. And I suspect that’s where the bulk of my performance issues lie. However… out of due diligence, I wanted to reach out and see if I can find out what’s happening under the covers with custom resolvers.
Are these resolvers executed asynchronously or are they executed one at a time? For example… for my image signer, the custom resolver is on a field. So, if a page has 100 images on it, it’ll call the API 100 times. There would be a pretty huge difference between Dgraph waiting for each element in the array to complete the call to my API before moving on to the next one. Compared to firing off the call across the board, then waiting for all to complete before returning the entire object.
anyone? Still hunting down the performance issues. Today, while nothing has changed, I started getting random, but frequent 500 errors from my custom resolver. However… looking at the logs from my API… not a singled 500 error is being thrown. Kind of curious as to where this error is occurring.
I am assuming you are using custom resolvers in SINGLE and not BATCH mode. In the SINGLE mode, we execute the requests concurrently and then wait for all of them to return. So it executes all of those 100 requests at once and waits for them to return.
If this is the case, your GraphQL request to Slash should also be returning an errors key. Can you check the error that you get back and share here? Is there a way we can reproduce this or maybe we can add some debug/tracing logs in the next version about the time it took for a custom resolver?