Investigate API performance

[bitbeckers]

What is it?

We have a sudden crash yesterday where the reason couldn't be determined. We know we have optimisation to perform on the API as the growing complexity in the data model introduced a lot of DB round trips.

Paths to explore:

• API performance testing - what load makes it crash
• API round call reductions - reduce the number of calls to Supabase

Known issues:

• Image fetching in metadata pulls raw, unoptimized image #257
• Refactor fetching metadata from DB into field resolver #256

[bitbeckers]

Fetching the metadata image wasn’t really optimised, so when you call the hyper cert metadata you fetch the full image. This means the API could pull a couple of MBs from Supabase DB, before returning it from the API to the client. Which, obviously, can be pretty slow.

In our app we’ve split the image fetching via an API route and let Vercel handle the image caching and optimisation

[bitbeckers]

Investigating Railway, Sentry, Cloudflare and Vercel logs show that responses appeared to time out, but no 3xx, 4xx, 5xx errors. We do see long calltimes to supabase (>10s) and /v1/graphql POSTs (>10s)

Sentry

Railway

Cloudflare