Using the Google Sheets API to store session history and metadata for a nightly backfill job instead of, you know, a database. The program broke after the creator left and no one could figure out how to bring it back up. The engineer assigned to fix it pulled their hair out looking for the database creds, local SQLite3 records, anything that would initialize the backfill. Finally realized it wasn't just printing out metadata to a Google Sheet but actually relying on that as a persistence layer. Root cause of the breakage was automatically adding every Hadoop counter from the job as its own column in the Sheet, which eventually exceeded the dimension limits.
I did this once. A client wanted a website that mimicked the functionality of a complicated spreadsheet that he had created to calculate quotes for customers and didn't have enough money to pay to have all the logic rewritten in a webserver (not to mention continually updated).
I imported the spreadsheet into google sheets, gave him access, and had the webserver paste the values in the spreadsheet via the google sheets api and read them back out.
Not to detract from this project, buy this is a good opportunity to mention Apps Script.
You can do all sorts of interesting things between a form, spreadsheet, and other services including your own. Nobody seems to use it, but internally we do all sorts of gloriously hacky workflows with it.
You can easily script forms/sheets/calendar/Gmail together to create pretty much anything you need.
I use it to send daily email reports of data fed into a spreadsheet.
Ah sure, no problem, feel free to do a PR mentioning App Scripts as well if you'd like.
From a quick overview it seems like if you need serious work with spreadsheets/GDocs then App Scripts is a good choice. However drive-db is more like a (very) quick way of putting a Spreadsheet into your Node.js backend as an array/db. I purposefully didn't even allow edit since that'd require API keys from users and defeat the quick part of it.
