Building an Airtable API Proxy using Glitch

Here's a project demonstrating the basics of an Airtable API proxy using node.js and Express. Click here to see the source and remix for your own purposes.

Why does Airtable need an API Proxy?

Airtable's rate limit is five requests per second per base. Anything more than that and the API will lock down for thirty seconds. By implementing an API proxy, it's possible to cache common results for quick responses and enforce a rate limit for requests.

Additionally, an API proxy allows you to keep your API key a secret. Since all Airtable API keys allow full CRUD access, using the key in client-side JavaScript code would leave your data subject to outside tampering.

Click here for example output.

Click here to see the source data.

How does it work?

Three files drive the proxy:

server.js

An API route, /api/ai/list/:page, demonstrates how to serve JSON in response to a request, handling pagination.

caching.js

Simple, file-based caching.

readCacheWithPath(path)

Returns cached JSON, if it's not too stale. Use cacheInterval to adjust this.

writeCacheWithPath(path, object)

Writes a JavaScript object to JSON at the specified path. Note this does not currently create directories if they don't exist. If you're seeing cache writes fail in your own implementation, try creating the intermediate directories.

//TODO: Add something that does this automatically.

database-connection.js

This is the meat of the project. It uses the Airtable node.js client to connect to a base and writes the results out as a JSON response.

Base ID and Airtable API key are in 🗝.env.

For more on accessing Airtable via the API, see the interactive Airtable documentation.

Rate limiting

Bottleneck handles rate limiting. The Airtable database interactions are handled using Bottleneck's wrap function.

Airtable: a quick intro