Any interest in adding upserts? And the general future of ExAirtable...

[iffies]

There are two features I want on a new project from ExAirtable: faster deletes and smart upserts. The latter was introduced in the Airtable API in 2022, where the API decides to create a new record or update an existing one based on the value of 1-3 matching merge fields.

Previously, I would determine whether to create or update records using saved hashes generated in Elixir. While Elixir is fast enough, even for tables with tens of thousands of Airtable records, the Airtable API read rate is too slow even at reads of 500 records per second. ExAirtable maintains simplicity through a single definition of a ExAirtable.Airtable.List, which consists of records and an offset. It uses this for the requests and responses to various Airtable API endpoints, including create and update.

But the Airtable API has evolved. For example, the update endpoint can take additional fields in both the response and request to permit upserts. It seems worthwhile to add custom request and response modules per action: ExAirtable.Airtable.Upsert.Request. (Also note that Airtable's update endpoint that handles the upsert action is fussy. If you include a null id field, it breaks. One has to either redefine a ExAirtable.Airtable.Record variation without an id field, or remove it from the binary of the generated JSON.)

I've made a pull request for my implementation of a faster delete, which operates on ten records per API request instead of one. I have upsert working, but it does make a compromise with the simplicity of ExAirtable. Does it make sense to make a pull request for upsert, even if for informational purposes? For sure, others may find a better way to introduce it with less complexity, but I think ExAirtable's simplicity is at a tipping point.

There are other areas where ExAirtable could do with catching up with Airtable features. For example, webhooks are now usable. And on the Enterprise plan, there is a 14-day change data capture (CDC) feed in the Compliance API. Does it make sense to make pull requests for minor changes, update on a new public fork, or start a new project using the existing code as a base.

ExAirtable is a great project, with great design decisions behind it, but where to from here?

[iffies]

In July 2024, Airtable quietly introduced a new API endpoint for uploading attachments. Previously you could only upload attachments by passing in a publicly accessible URL. The new endpoint takes the form:

https://content.airtable.com/v0/{baseId}/{recordId}/{attachmentFieldIdOrName}/uploadAttachment

What's interesting here is that (1) it's no longer api.airtable.com; and (2) you no longer need to give the API any information on the table, because it is uniquely identified by the Record ID. (Note that in 2025, Record IDs are no longer meant to be globally unique but unique to a base. Now when you clone an Airtable base, the Record IDs are now preserved.)

I'm sharing this on this thread as another example that the simplicity and assumptions of the original ExAirtable design is going to have to be rethought unless one resorts to hacks at the edges to implement these newer APIs.

(Found this in an open browser tab from last week; although I summarised some of it in another issue.)