Improving performance and stability by consolidating validation and access check logic in the API gateway

For the past few days, I have been working on improving the stability and performance of the ScreenshotOne API. I started from low-hanging fruits—moving validations and access key management from rendering services to ScreenshotOne's API gateway. The API will be more stable and performant as a result. If you are curious why, please continue reading.

2 min read

Written by

Dmytro Krasun

Published on

Before Refactoring

A few words about how the ScreenshotOne API worked before the refactoring and why it was done the way done:

before

An API Gateway service (built on top of the Cloudflare Workers platform) received all requests and sent them to rendering services (Google Cloud Run). And the rendering services, each on their own, were sending requests for validating requests, checking quotas, signatures, and so on to the access management services.

That architecture had evolved organically:

  1. The API started as one simple service hosted on one server.
  2. Then, for scalability, it was moved to Render and eventually to Google Cloud Run, which required decoupling key management and other common logic from the rendering services.
  3. Later, the API gateway was added to use Cloudflare Caching and Storage.

It worked nicely, but in the past few months, ScreenshotOne grew dramatically. And the setup revealed a few bottlenecks:

bottleneck

Each request to the ScreenshotOne API spins up a new Google Cloud Run instance. Propagating back takes time, and the number of instances is limited after all. So, when an error happens in the validation and key management services, it propagates back through the Google Cloud Run instances and increases the response time. In addition to that, on rare occasions, there might be no available instances.

After refactoring

It is obvious, yes, how to solve it? And, yes, the solution was simple. I moved validation and access check logic to the API gateway.

after

The new approach means that validation in case of invalid requests will be super fast. And new instances won’t be used. It implies that ScreenshotOne customers can enjoy improved stability at the end of the day.

What’s next?

ScreenshotOne has a public roadmap, but I invest time in improving what the API already has to offer.

I am now improving observability, and the quality of rendering is one of the core metrics for the API. I am eliminating errors and issues I find, and customers report one by one to make the API as great as possible.

If you have any questions or want to share some ideas, feel free to write at hey@screenshotone.com.

Read more product updates

New features, bug fixes, and optimizations...

View all product updates
Get the HTTP response status code and headers with screenshots

Get the HTTP response status code and headers with screenshots

On rare occasions, you might need to get the HTTP status code and headers of the target host. It is pretty easy to do now.

Read more

1 min read

Documentation for LLMs

Documentation for LLMs

ScreenshotOne now supports documentation format specifically targeted for LLMs—llms.txt and llms-full.txt.

Read more

1 min read

Rendering errors in webhooks

Rendering errors in webhooks

Check out how to get notified about rendering errors when using webhooks.

Read more

1 min read

Automate website screenshots

Exhaustive documentation, ready SDKs, no-code tools, and other automation to help you render website screenshots and outsource all the boring work related to that to us.