We all have superpowers. One of my friends once said that my superpower was the ability to look at any piece of software and, within minutes, be able to describe with frightening accuracy the underlying data structures and fundamental internal APIs used to manipulate it. The other day I ran headlong into Airtable, and the underlying data structure was pretty obvious. The performance is amazing, but the underlying data is, well, simple.

A spreadsheet is a Cartesian grid of cells. But the interaction between the cells is a graph, in which some cells contain values, and other cells contain expressions that are dependent upon those values. A hypersheet extends this notion to include the idea that some cells contain, or are driven by, data stored elsewhere (and usually stored using an RDF triple).

So: An Airtable is nothing more than a graph database, backed by Postgres, in which triggers written in a convenient subset of a popular language (let's call it Javascript) can be written by the community to facilitate the filtering and processing of hypertext content on a cell-by-cell basis.

The trick of a spreadsheet is in extending it conveniently. But there's already a book that teaches you how to do cutting, copying, and pasting of content. It's not a fantastic book; it's too centered on its own interests to abstract spreadsheet notions well, and it's too concerned with C# (although the F# asides are fascinating). It does cover the issue of relative-and-absolute ranges and how to cut and paste them without losing track of what they refer to, so that's good enough.

Seriously: That's about it. I've linked to every paper and book you need, every idea, to re-implement Airtable. All it takes is some engineering. And let's be honest here: if you get the infrastructure for Airtable right, you get how to write Wunderlist, Trello, and Evernote for free.

Now, be fair: I have no idea if Airtable is implemented this way.  For all I know, this facile analysis might give the engineers there one heck of a giggle.  But if I was going to implement something like Airtable, these are the resources with which I would begin: A document store of databasess, a graph database of relationships, an abstracted RDBMS (probably Postgres) of content, a decent event manager using push as its paradigm for updating cells (RxJS, using React, or possibly just straight up Om), and a lot of interesting knowledge gleaned from papers on hypersheets and functional spreadsheets, with each cell decorated with an about field that identifies the uniform resource name of the object that cell represents.  Processing could be done client-side or server-side, depending upon the nature of the cell and the frequency with which in needs updating (RSS and Semantic Web objects would be updated less frequently), and it would be technically challenging but not impossible to discern which was which with a proper constraints-based system.

Oh, by the way, if you get the typeof/about/property triple correct for cell representation, you're basically a few engineering puzzles away from replicating The Grid, as well.