17 comments

[ 2.4 ms ] story [ 60.8 ms ] thread
Love the idea. Clearly, a ton of effort put into this, congrats on shipping. But if you're going to abstract away Google Sheets, you might as well make a thicker abstraction. I want to use Google Sheets like a key-value store or some Mongo-like API, without thinking about worksheet names, column names, or underlying worksheet-specific implementation details. Your custom designed API is too much of a leaky abstraction, seems that it's not too far from me learning and using the Google Sheets API directly. Consider how other libraries like diskDB abstracted away the filesystem behind a Mongo-like API.
Then submit a pull request. Don't sob about it here.
That's a very good insight! We treat spreadsheet more like a database with a schema. What you propose is a schema-less approach. I like this idea, and I think we will try to implement it, as we see that in such solutions schema is needless and is adding more complexity for the end user, which, in most cases, don't care if there is any schema or not - she is just a spreadsheets user.

From the other hand, it's hard to map JSON to a spreadsheet, because - what to do with the nested keys. Any ideas?

You could flatten the json object - instead of joining the keys with a `.` scheme, treat those as columns in your sheet.
(comment deleted)
Don't hesitate to stick to enhancing the low-level non opinionated api. Having one is great because that enables all users to do what they want.

Then you can have other apis on top of it for opinionated usage like a kv store or other stuff.

For representing a nested key the first implementation that springs in mind is to use the indent (number of empty colums on the left) as indicator of parent-child relationship.

Who said we're all just putting spreadsheets on the Internet?

This at least makes that easier...

Don't do that. Please.
Why?
Because Google Speadsheet isn't designed to be a database. For example there are no datatypes.

It's maybe good enough for protoyping, but that's all.

maybe prototyping is all it's needed for. It doesn't need to fit every single use case to be useful.
It's indeed as robust as web scraping IMO but I'm sure there are some use cases.
You list Code for America, imgur, Berkeley, Stanford, and others under partners on your website. How are they using this? And do you have some links to blog posts of them talking about it or something?
Students from Stanford, Berkley and other universities (Notre Dame, Illinois, Columbia, Yale, Texas Woman’s Uni, Alaska, Colorado Boulder, Minnesota, UCLA, Michigan, Chicago, Georgetown), as well as students from Boston, Harvard college, are using Sheetsu to learn how to talk with APIs and use them on the front-end.

Folks from Code for America were using it for very simple CMS to show dates of some events.

Guys from GeneralUI are using this for a quick solution for prototyping and have forms up and ready without setting up middlewares, servers, etc.

A customer from imgur is using this for some user research process (getting feedback).

Basically, most of them are using this in places where marketing or UX meets IT. Or there's no budget for IT to be involved, and they need to setup something on their own. We are trying to get all of those awesome use cases and make stories and blog posts from there. We are really amazed by some of them, what people can build if they need to.