Why Screenshot APIs Are Ideal for Serverless
Running Playwright or Puppeteer on AWS Lambda is famously difficult — the Chromium binary exceeds Lambda's deployment package size limits, requires custom Lambda layers, consumes significant memory, has slow cold starts, and breaks on Lambda runtime updates. Screenshot APIs solve this entirely by moving the browser to a managed external service, leaving the Lambda function as a lightweight HTTP client that calls the SnapAPI REST endpoint and returns the result. A Lambda function that calls SnapAPI fits in a standard Node.js Lambda deployment package, starts in milliseconds, and uses minimal memory — the heavy browser work happens on SnapAPI's infrastructure, not in the Lambda execution environment. This architecture enables serverless screenshot workflows that scale to zero between requests, cost nothing when idle, and scale to handle traffic spikes by invoking additional Lambda instances in parallel, each making concurrent SnapAPI calls within the plan's rate limit.
AWS Lambda Screenshot API with Node.js
Define an AWS Lambda function handler in Node.js or TypeScript that accepts an API Gateway event, extracts the target URL from the query string parameters, calls the SnapAPI client using the installed SDK, and returns the screenshot bytes in a Lambda proxy response. Initialize the SnapAPI client outside the handler function at module scope so that the client is reused across Lambda invocations within the same execution environment, avoiding client re-initialization overhead on warm invocations. Return the screenshot PNG bytes base64-encoded in the Lambda proxy response body with isBase64Encoded set to true and Content-Type set to image/png, enabling API Gateway to decode and proxy the binary response correctly to the HTTP client.
import { SnapApiClient } from '@snapapi/client';
const client = new SnapApiClient({ apiKey: process.env.SNAPAPI_KEY! });
export const handler = async (event: any) => {
const url = event.queryStringParameters?.url;
if (!url) return { statusCode: 400, body: JSON.stringify({ error: 'url required' }) };
const result = await client.screenshot({ url, fullPage: true, width: 1280 });
return {
statusCode: 200,
headers: { 'Content-Type': 'image/png' },
body: result.image.toString('base64'),
isBase64Encoded: true,
};
};Vercel Edge Functions Screenshot API
Vercel Edge Functions running on the Vercel Edge Network use the fetch-based Web API rather than Node.js APIs, making the SnapAPI integration a standard fetch call to the SnapAPI REST endpoint. Define an Edge Function in app/api/screenshot/route.ts using the Edge Runtime export, read the URL from the request URL search params, call the SnapAPI REST endpoint using the fetch API with the Authorization header set to the API key, and return the response image bytes as a NextResponse with Content-Type image/png. Edge Functions run close to the user on Vercel's global edge network, reducing the round-trip latency for screenshot API calls that are initiated by user interactions — though the SnapAPI call itself runs from the edge node's location, so edge proximity primarily reduces the function invocation latency rather than the SnapAPI screenshot generation time. Use Vercel's KV store for caching screenshot results at the edge, returning cached images for repeat URL requests without invoking SnapAPI on every edge function call.
Cloudflare Workers Screenshot API
Cloudflare Workers running on Cloudflare's global network call SnapAPI using the native fetch API available in the Workers runtime. Define a Worker that handles GET requests with a url query parameter, calls the SnapAPI REST endpoint using fetch with the SNAPAPI_KEY secret bound to the Worker, and returns a Response with the screenshot bytes and the Content-Type: image/png header. Use Cloudflare's Cache API to cache screenshot responses at the Cloudflare edge, keyed by the target URL, so that repeated screenshot requests for the same URL are served from the nearest Cloudflare PoP cache without making additional SnapAPI calls. Cloudflare Workers KV provides a global key-value store for persisting screenshot metadata — the target URL, the capture timestamp, and the storage key — across all Cloudflare edge locations, enabling distributed screenshot result lookup in Workers deployed globally without a centralized database.
Google Cloud Functions Screenshot API
Google Cloud Functions using the Node.js runtime call SnapAPI using the official JavaScript SDK or the native https module, with the API key stored in Google Cloud Secret Manager and accessed via the Functions framework's built-in Secret Manager integration. Define an HTTP-triggered Cloud Function that reads the URL from the request query parameters, calls the SnapAPI client initialized at module scope for connection reuse across warm invocations, and writes the screenshot PNG to Google Cloud Storage using the @google-cloud/storage client before returning the GCS object URL in the response. Configure the Cloud Function with 256MB of memory — sufficient for the Node.js process and the SnapAPI HTTP call without the browser memory overhead that Puppeteer-in-Lambda requires — and a timeout of thirty seconds to accommodate SnapAPI screenshot generation for complex pages. Use Cloud Scheduler to trigger the Cloud Function on a schedule for batch screenshot monitoring workflows, passing a list of monitored URLs in the scheduler job payload for the function to process in sequence within a single invocation.