Yes, certainly. Consider it added to the todo list. It wasn't a priority for a prototype, as the users I'm targeting are generally not Google Docs users anyway (at least in my own experience).
Interesting. I thought the opposite. Anyone who deals with APIs are likely gdoc users. Like us :) Anyway, adding google docs would open up a lot of cool things, like tapping into IFTTT recipes that already output there. You are providing the glue that removes a lot of grunt work.
This is awesome, btw. Could you talk about how you came about the idea?
Ah, agreed that the end-users of the APIs this builds would very likely also be Docs users. But the people who're turning their spreadsheets into APIs (i.e. the publishers) likely are not, in my experience.
Thanks for the compliment. As a developer working on a lot of systems that integrate service coverage data I'm constantly being sent spreadsheets that contain zip code / postcode level information, and I need to import this into my database or my client's databases. And normally my apps only want to lookup one or two values per day - but the third party is sending me their entire 100MB spreadsheet, as they don't have an API to publish it via. It's time consuming, error prone, and clunky. But they don't have the skill or resources to create an API, so I'm hoping something like this might remove some barriers.
Very interesting. So you may want to experiment with the messaging like "clients still doing things with excel spreadsheets?" for example, targeting developers who deal with excel dependent or decades old reporting clients. There are so many of those I'm sure.
There's two types of user here that go hand-in-hand:
The publisher, who cannot / will not create an API from their spreadsheets, but would like to (either to ease their own pain, or because their end users are asking for it, or because they don't want to share their entire dataset so often).
The consumer, who wants to access a little bit of their publisher's data without having to import spreadsheets en-masse regularly.
The publisher is the customer of the service ultimately, but the consumer will quite likely be the one driving the publisher to adopt it. Being self-critical, I'd say this makes it a bit of a tough sell (you're one step removed from the actual customer).
This looks great. Now if you could only turn websites into a spreadsheet using http://scrape.ly and then turn it into an API using Sheetlabs, that would be awesome.
Very interesting idea: one possibility for driving demand would be to provide free API hosting for public-domain spreadsheet data (essentially anything published by the government) and charge heavy usage users for access (they could eventually just import the source data if they cared that much, but it could help get the word out).
I've been thinking along very similar lines, but more along a Github-esque model: Host your data and APIs for free, providing you publish them publicly. If you take them private, you pay a little. Early days yet, today is mostly about gauging interest.
Hehe: I was trying not to use "Like Github for APIs" in my description, but yes, that is pretty much what I was thinking.
I actually just ran the following search on Google:
inurl:.xls site:gov
and uncovered a bunch of random Excel spreadsheets (such as this one: http://www.whitehouse.gov/sites/default/files/omb/budget/fy2...). Would be slightly more complex to do but potentially this would make any published government data instantly accessible via API and (depending on what your backend looks like) you could bake in Solr or ElasticSearch to also provide search inside the data. Maybe an easy onboarding tool to let any visitor to the site specify a publicly accessible spreadsheet and then automatically create the API?
Curious, others are importing xls docs without issue, but yours is failing silently with return code 77 from libreoffice-headless (which is being used for the conversion). A quick Google shows I'm not alone here. Leave it with me, I'll reply here. In the meantime, feel free to convert to CSV or XLSX first and then import.
This is a really clever idea. So simple and almost-obvious, yet it's the first time I come across this. Genius.
Particularly like the fact that REST APIs are pretty easy to start with providing GET access to resources, but get messy when you start doing POST, PUT, DELETE, PATCH etc. In this case, it's read-only by definition. That must make things so much easier. I can anticipate people asking for update access in future, but if you can get customers without it, I'd hold off with that for as long as possible.
One thing though - I think you should definitely raise your prices. 20Gb and 10 million queries for only €15 per month??!!
Thanks! I too was surprised when I couldn't find anyone else that had done it. Noted RE pricing, just testing the water for today - consider this a HN special if you want to lock it in early ;)
This strikes me as different. This looks a lot like Microsoft Access. A tool for "simplifying" database construction and common tasks like reporting (which doesn't actually work except in very simple cases, because you quickly reach the point of needing to understand concepts like normalization and foreign keys even if the GUI is pretty).
I'm guessing I'm simply not considering the target audience, but so far as I know the groups (people who communicate primarily via spreadsheets) and (people who know what an API is) have a fairly small overlap.
Maybe I'm just underestimating how widely used spreadsheets are for communicating programming information. I've never seen it, but hey, I've never seen a lot of things.
Excel 2010 and up have the ability to read from web services that support Microsoft's OData protocol, and Microsoft is pushing some add-ons they built for Excel to turn it into a more robust front-end for business intelligence things.
So I don't think it's about knowing Excel and knowing what an API is as much as that you can train someone to paste a URL in and then they can build their own reports/worksheets that join in your data.
I can only speak for my use case, but I've heard similar things from other people, so I don't believe it's only me. I agree the overlap is small between those groups, but I think it's pretty painful when it does occur.
I've done quite a bit of freelance web development, mostly in the telecoms and infrastructure sectors, and there was often a requirement to integrate with a third party. This "integration" almost always took the form of periodically receiving spreadsheets from them, manually importing them into our database, and then also handling the periodic updates. And the apps I was building only needed to query a few rows each day! Sometimes they'd eventually create an API, but most said they couldn't or wouldn't due to time or complexity. Sheetlabs is my attempt at removing some of these barriers.
Anyway, that was _my_ itch, and this is how I'm scratching it!
Pretty much what I wanted to say. The target seems to be "business" people who email spreadsheets around, and if you haven't seen this much, believe me it is done a LOT. But in my experience these people would have no idea what an API is and no idea why they would want one. I see these people gravitating to shared spreadsheets on Google Drive or SkyDrive, which eliminates the email attachment pain without really requiring them to learn anything new.
The idea is cool, the website looks good, and this seems like it could be really useful, but I don't get the sense that the right audience is targeted here.
Also an aside to the Sheetlabs folks, sort of a pet peeve of mine, your site returns a blank white page if JavaScript is disabled, you might want to at least throw a noscript tag in so people don't think you are just down.
Neat. I'll be interested to see how access restriction by user is handled? Obscure header key or URL? Something authenticated? I guess I will have to sign up to find out. It doesn't appear to be documented publicly.
There's three access levels: public (anyone can access), authenticated (anyone authenticated user in your organisation can access), and private (only selected users can access).
If an API requires authentication, then you'll need to login to see documentation or query it.
There's a little about it on https://sheetlabs.com/#/docs at the bottom, but you're right that the docs need to be fleshed out more fully and linked from the front page.
Looks neat but can you add a github (or google/otheroauthprovider) login...the register page is way too daunting for me. Either that or provide an account-less mode for trying out the product before prompting signup..and even then i'd much rather not type into many fields when i can just auth with something else. Thanks again for the putting this out. look forward to playing with it :)
The phrase "There's so many things that can go wrong with this" is really bothering me. I don't know why this mistake catches my attention, but it does. I probably speak that way but it should be written "There are" instead of "There is". Hopefully this sounds like creative criticism and not just bashing. I noticed that samcrawford is watching these comments.
They (Ycombinator) should implement 'mark as favorite'. There are so many similar tools included in the comments that I'm writing this comment just to have a quick shortcut to find the thread in future references.
Interesting, quite neat that you can share the data between organizations in a permissioned manner. Pricing is interesting, you may want to consider a usage based model rather than flat fee.
Author here. Thanks for all the feedback, very much appreciated, I wasn't expecting this. Feel free to email me if you have questions you'd like to take off-list (email in profile).
Some stats, which may be useful for anyone doing a Show HN soon and wondering about volumes:
- 11k visits at the time of writing (3 hours in)
- 71% of hits so far are from the Americas (hit the California server), 29% from elsewhere (hit the London server). Given the time in Europe, there is significant bias here though.
You need to put up some examples of what can be done by this service. Something visitors can interact with without registering is ideal to convince them to register.
I stared at that for 10 minutes trying to find the spreadsheet. I assume there is a spreadsheet backing it? You should actually show people the spreadsheet - just seeing an API description without demonstrating that it runs off a simple spreadsheet almost kind of defeats the whole purpose of the service!
Thanks for the feedback. Yes, it is backed onto a spreadsheet effectively. Showing it is a good idea for the front page.
But I don't think showing the spreadsheet in the API docs is so useful; the idea is to present a clean API to the users, and they don't even need to know that the data was originally from a spreadsheet.
+1 on showing the spreadsheet. It doesn't have to be on the docs, can be on the website. I'd put front and center, if you have this spreadsheet, it creates this API. You can even look into giving access to the sample spreadsheet for testing directly from the web pages.
I know you're still working things out, but I feel that your free tier is overly generous and your Business tier is a steal at $20. If it assuages a pain point for someone, that pain point is likely worth quite a bit more.
I actually think I'll be using this quite soon. I've also shown it to an excited PM, who thinks this could be useful for some clients that have been building reports from spreadsheets.
For me, I think there's a great use case for prototyping applications with a spreadsheet. I don't intend to build a service that exposes spreadsheet data as an external facing API.
This is really cool, and a nice implementation. My question is about target customers. Presumably, you have two sides to this: non-devs writing and uploading the spreadsheet, and devs writing a client to to consume its API. I would imagine these two parties would be in the same company. e.g., Sales team wants some analytics dashboards written over their spreadsheets. So they upload a sheet and give it the API to devs, and then the devs consume the API, analyze the data, and pull it into a dashboard. Also presumably, it would be the devs recommending to the non-devs that they upload their spreadsheet here for easy access.
But if this is the case, why would the devs choose to use this over any number of CSV or XLS parsing libraries? You can write a simple web server that takes a spreadsheet as an upload, and then parse it to CSV, in less than 50 lines of code. The CSV reading APIs in any language are very easy to use and parse to native data structures, and I would argue maybe even easier than using an API like this.
What is your value proposition to devs in this scenario? Or I missing an entirely different use case?
Your two sides scenario tallies with my own, except I'd imagine they're not usually part of the same company (but other people will have different use cases, of course).
In your example, you could absolutely use an existing CSV or XLS parser to do this. The problem is that you're now responsible for making sure that you've got the latest data, have parsed it, and have imported it. As a developer, Sheetlabs allows you to put the onus back on the data publisher to ensure that they're giving you the latest data. Plus it's in an easier to consume format too!
This seems like a nice layer between some data scientists that might be used to working with csv's or some subset of databases, and a dev team that happens to be using another subset of db's. Data scientists could throw some results into a csv and front end devs could quickly pull it in as a rough version of what the actual API would look like to get started on presentation of the data. First pass mockups could be done taking minimal time away from the engineering team, iterate these with stakeholders, and finally implement the final API with the fully fleshed out front end.
What makes this better than using the Google Docs API? I could have anyone write to a spreadsheet and in turn it would be updated when called on their API.
In fact I do that for many small business clients of mine which don't want to deal with databases for things like their product catalog and pricing lists.
Additionally you get version control, busier sites get the google doc scraped X times a minute as to not reach the request limit.
- Simplicity. It's fine for you to create an API via Google Docs, but I suspect it'd be tough for your (presumably) non-technical clients.
- Generated API docs
- Granular control of who sees what data and APIs
- Usage tracking (see who's using your APIs/data and how often)
- Easy integration for API clients: example code, no messing around with authenticating their Google account
I don't think you're wrong though: For publishers who already have their spreadsheets held in Google Docs and have setup an API, and are happy with that process, then there isn't a _huge_ benefit here.
That said, I've had quite a few emails overnight from people asking to support importing spreadsheets from Google Docs, so clearly they're missing something - I'll have to ask to find out whether it's something from my list above or something else.
81 comments
[ 3.6 ms ] story [ 137 ms ] threadThis is awesome, btw. Could you talk about how you came about the idea?
Thanks for the compliment. As a developer working on a lot of systems that integrate service coverage data I'm constantly being sent spreadsheets that contain zip code / postcode level information, and I need to import this into my database or my client's databases. And normally my apps only want to lookup one or two values per day - but the third party is sending me their entire 100MB spreadsheet, as they don't have an API to publish it via. It's time consuming, error prone, and clunky. But they don't have the skill or resources to create an API, so I'm hoping something like this might remove some barriers.
The publisher, who cannot / will not create an API from their spreadsheets, but would like to (either to ease their own pain, or because their end users are asking for it, or because they don't want to share their entire dataset so often).
The consumer, who wants to access a little bit of their publisher's data without having to import spreadsheets en-masse regularly.
The publisher is the customer of the service ultimately, but the consumer will quite likely be the one driving the publisher to adopt it. Being self-critical, I'd say this makes it a bit of a tough sell (you're one step removed from the actual customer).
I actually just ran the following search on Google:
inurl:.xls site:gov
and uncovered a bunch of random Excel spreadsheets (such as this one: http://www.whitehouse.gov/sites/default/files/omb/budget/fy2...). Would be slightly more complex to do but potentially this would make any published government data instantly accessible via API and (depending on what your backend looks like) you could bake in Solr or ElasticSearch to also provide search inside the data. Maybe an easy onboarding tool to let any visitor to the site specify a publicly accessible spreadsheet and then automatically create the API?
Looking forward to seeing what you do with it!
I do think it will take some hard work to get it out there, though.
A Github-esque model sounds utterly fantastic. I would start using that today if it was available.
Particularly like the fact that REST APIs are pretty easy to start with providing GET access to resources, but get messy when you start doing POST, PUT, DELETE, PATCH etc. In this case, it's read-only by definition. That must make things so much easier. I can anticipate people asking for update access in future, but if you can get customers without it, I'd hold off with that for as long as possible.
One thing though - I think you should definitely raise your prices. 20Gb and 10 million queries for only €15 per month??!!
http://flatsheet.io/
http://data.brace.io/
http://cloudstitch.io/
It works both in read and write mode. See tutorial: https://apispark.com/docs/tutorials/google-spreadsheet
As a sidenote, I love these creatively easier ways to supply data to an API in order to use it quickly and update it quickly (just by re-uploading).
https://github.com/AntJanus/popstar-cms
Missing screenshots. (Examples)
Good:
Real text, not just a video.
Maybe I'm just underestimating how widely used spreadsheets are for communicating programming information. I've never seen it, but hey, I've never seen a lot of things.
So I don't think it's about knowing Excel and knowing what an API is as much as that you can train someone to paste a URL in and then they can build their own reports/worksheets that join in your data.
I've done quite a bit of freelance web development, mostly in the telecoms and infrastructure sectors, and there was often a requirement to integrate with a third party. This "integration" almost always took the form of periodically receiving spreadsheets from them, manually importing them into our database, and then also handling the periodic updates. And the apps I was building only needed to query a few rows each day! Sometimes they'd eventually create an API, but most said they couldn't or wouldn't due to time or complexity. Sheetlabs is my attempt at removing some of these barriers.
Anyway, that was _my_ itch, and this is how I'm scratching it!
The idea is cool, the website looks good, and this seems like it could be really useful, but I don't get the sense that the right audience is targeted here.
Also an aside to the Sheetlabs folks, sort of a pet peeve of mine, your site returns a blank white page if JavaScript is disabled, you might want to at least throw a noscript tag in so people don't think you are just down.
If an API requires authentication, then you'll need to login to see documentation or query it.
There's a little about it on https://sheetlabs.com/#/docs at the bottom, but you're right that the docs need to be fleshed out more fully and linked from the front page.
Some stats, which may be useful for anyone doing a Show HN soon and wondering about volumes:
- 11k visits at the time of writing (3 hours in)
- 71% of hits so far are from the Americas (hit the California server), 29% from elsewhere (hit the London server). Given the time in Europe, there is significant bias here though.
- 6.7% of hits used IPv6
- 76% used Chrome, second place was FF at 11%
This is linked off the front page, but could certainly be more prominent (as another commenter said)
But I don't think showing the spreadsheet in the API docs is so useful; the idea is to present a clean API to the users, and they don't even need to know that the data was originally from a spreadsheet.
It seems like Microsoft failed to promote the idea to a broader audience.
For me, I think there's a great use case for prototyping applications with a spreadsheet. I don't intend to build a service that exposes spreadsheet data as an external facing API.
But if this is the case, why would the devs choose to use this over any number of CSV or XLS parsing libraries? You can write a simple web server that takes a spreadsheet as an upload, and then parse it to CSV, in less than 50 lines of code. The CSV reading APIs in any language are very easy to use and parse to native data structures, and I would argue maybe even easier than using an API like this.
What is your value proposition to devs in this scenario? Or I missing an entirely different use case?
In your example, you could absolutely use an existing CSV or XLS parser to do this. The problem is that you're now responsible for making sure that you've got the latest data, have parsed it, and have imported it. As a developer, Sheetlabs allows you to put the onus back on the data publisher to ensure that they're giving you the latest data. Plus it's in an easier to consume format too!
In fact I do that for many small business clients of mine which don't want to deal with databases for things like their product catalog and pricing lists.
Additionally you get version control, busier sites get the google doc scraped X times a minute as to not reach the request limit.
- Simplicity. It's fine for you to create an API via Google Docs, but I suspect it'd be tough for your (presumably) non-technical clients.
- Generated API docs
- Granular control of who sees what data and APIs
- Usage tracking (see who's using your APIs/data and how often)
- Easy integration for API clients: example code, no messing around with authenticating their Google account
I don't think you're wrong though: For publishers who already have their spreadsheets held in Google Docs and have setup an API, and are happy with that process, then there isn't a _huge_ benefit here.
That said, I've had quite a few emails overnight from people asking to support importing spreadsheets from Google Docs, so clearly they're missing something - I'll have to ask to find out whether it's something from my list above or something else.
It seems as though you offer double the 100M file size limit on your free plan?