Show HN: Sheetlabs – Turn your spreadsheets into APIs
sheetlabs.com
sheetlabs.com
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??!!
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).
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.
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.
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.
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!
Combined with "jq" on command line for testing stuff, could be really useful.
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?
It seems like Microsoft failed to promote the idea to a broader audience.
Hobby => $8
Business => $29
Enterprise => Contact
It's worth noting that the costs for this really are tiny - just a couple of servers. I've done the sums, and even with the business tier costing $20, the profit margins are significant.
The biggest unknown is how much support each user will generate, and that's probably a good reason to raise the business price. Anyone who signs up before then will be offered the existing price of course.
Based in the UK. The site already does some work with geolocating the user (for giving localised pricing and also for inferring date formats when you upload spreadsheets), so I suppose I could localise spelling too ;)
http://blog.oxforddictionaries.com/2011/03/ize-or-ise/
In fact it appears more to be laziness on the part of the UK english. Whilst the 'ize' form is derived from the greek endings, certain english verbs had to end with 'ise'. As we were too lazy to remember which ended 'ize' or 'ise' we just took the pragmatic approach and used 'ise' version for all of them.
I remember working for Deutsche Bank 15yrs ago when one Excel spreadsheet could make them millions of £/day — don't be afraid to charge a decent amount! People who care about data, have spreadsheets, and need some interoperability will not baulk at $29, $50 or even $200/mth. And if they're giving you a decent income, they'll trust that you'll be around for longer.
Would you expect a bank (or accountant, or FMCG company) to trust a critical part of their process to a free or £12/mth service? Hell, no.
But perhaps part of the problem is that you've build a cool thing but don't know exactly who your customers should be. When you figure that out you'll be able to write more compelling copy and price it appropriately.
N.B. I'm not bashing sheetlabs, just saying that sometimes the most important part is not the numbers in the cell but how you create them
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.
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 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).
Edit: I should add that Sheetlabs uses loads of open source goodies under the hood. For converting inputs we use libreoffice for XLS to CSV and xslx2csv for XLSX files to CSV files.
Missing screenshots. (Examples)
Good:
Real text, not just a video.