Instantly share code, notes, and snippets.

What would you like to do?
Why I love Tabletop.js but don't use it in production

Tabletop.js is a fantastic, open-source JavaScript library that lets developers easily integrate data from Google Spreadsheets into their online projects. I've used it, even contributed a minor feature, and love it for prototyping. Non-programmers love being able to update a project via Google Spreadsheets' hyper-intuitive interface.

That said, I'm extraordinarily wary of using Tabletop in production. Instead, at the Wall Street Journal, we use a bit of middleware to "prune" our Google Spreadsheets-based data and then cache it on our own servers. A few brief reasons:

  • Short-Term Reliability. With Tabletop, your project depends on Google not to rate-limit access to your spreadsheet. Google rate-limits access to their Spreadsheet API, though the thresholds aren't clear. If you're building an app you care about, you don't want to be in the position of hoping not too many people try to access it.

  • Long-Term Reliability. Your project also depends on Google not changing its Spreadsheets API. If it does so substantially, then — poof! — your project can't access the data it needs. Running your own middleware means that, with just a little work, you can provide your projects with a consistent data format, no matter how drastically Google's APIs change.

  • Load. Google adds a lot of cruft, like scheme notations, to its API responses. Lopping off that cruft will make your project load faster. In my experience, pruning the API response reduces the size of the data to somewhere between 15% and 40% of the original.

  • Editing flexibility. With Tabletop, changes you make to the spreadsheet are immediately reflected in your project. Sometimes you don't want that to happen. Middleware lets you update your public data only when you want.

  • Obfuscation. Anyone with a web inspector can trace Tabletop's live API calls back to the Google-hosted spreadsheet. You shouldn't be hiding anything confidential there anyhow, but I could envision circumstances where you might not want readers looking over your shoulders. Middleware lets you obfuscate the original source if you want.

Anything I missed? Any disagreement? I'm all ears.


This comment has been minimized.

zzolo commented Mar 28, 2013

What is your "middleware" that caches the data? Can you share?


This comment has been minimized.

cperryk commented Jul 24, 2013

I have the same concerns regarding tabletop.js, but, yes, what is the "middleware" that you mention?


This comment has been minimized.

aendrew commented Aug 5, 2013

Seems like #2 just happened...

@zzolo & @cperryk -- Look in the Tabletop.js repo's "caching" folder, there are two scripts that create a locally-cached version. jsoma/flatware is another option if you want something a bit more dynamic. Personally, I just used the snippet from here to save a local version of the Json object and then provided that to my existing code with jQuery's getJSON() method (Ultimately replacing the Tabletop.js calls).


This comment has been minimized.

jschleuss commented Nov 20, 2013

Another option would be to export your production spreadsheet as a JSON file and then call it in with a getJSON().


This comment has been minimized.

nicktruch commented Nov 25, 2013

@jschleuss : excellent !! But from this, how do you modify your Tabletop.JS code to use the JSON file ?


This comment has been minimized.


jsvine commented Dec 17, 2013

@zzolo @cperryk @jschleuss @nicktruch

Whoa, just rediscovered this Gist; didn't realize folks had commented or asked questions. On the principle of "better late than never," finally responding.

  • The middleware was an ExpressJS app running on one of our internal servers. Given a spreadsheet ID, it'd fetch the spreadsheet's JSON representation, strip out all the Google Spreadsheet–specific cruft, and write a plain-old JSON file to any combination of development and production servers.
  • Each spreadsheet got its own endpoint in the app, which listed some metadata (last date published, sheet maintainer's email, etc.) and a "update" button, which would pull/write fresh data.
  • Configuration for each sheet was, in turn, handled by a single "master" spreadsheet that designated the spreadsheet ID, project name, destination server(s), et cetera.

This comment has been minimized.


jsvine commented Apr 16, 2014

"New Google Spreadsheets doesn't allow you to publish CSV to the web. That's going to break a lot of stuff. They keep doing stuff like this." — @rich_harris, 15 April 2014


This comment has been minimized.

techieshark commented May 24, 2014


Assuming the permissions on the doc are set to 'Anyone with the link can view', downloading the following url gave me the CSV file:

is google drive's long hash key looking thing that you see in the URL when editing the doc.

Found this here (which calls for listing the key in the URL twice but that didn't seem necessary when tested):


This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment