Thoughts on my idea (Google Sheets to REST API service)?
Hi, I'm planning to launch a dead simple service to get a full REST API from a Google Sheet. It's as easy as sharing the file to my service's Google account.
Every file will be treated as a database. Every Table/Sheet, as a collection.
Automatically, you get:
GET http://myservicedomain.tld/s/sheet_id/table_name. Attach a json to specify filters (like "name":"Peter").
PUT http://myservicedomain.tld/s/sheet_id/table_name. Attach a json to specify values of new row.
UPDATE ...
DELETE ...
Pricing: something like $0.01/request.
I know Google Sheets already has an official API. I know that there are already similar services to simplify that API like sheetsu.com, but still, I think my way is simpler and I would use it myself, actually.
What do you think about it?
https://sheetlabs.com/
How would you differentiate vs. these guys (and Sheetsu) and would it be enough?
It is an interesting intersection I'd think, like I was thinking about CSV to REST but there are open source repos out there that do it. What I was referring to by the intersection is, if a person is already thinking about "turn this csv into an API" are they close enough (as a developer) to just build something eg. a standard db/api interface.
I don't know, using csv/spreadsheets is still a thing though, like for WordPress and importing WooCommerce products using AllImport, using the column headers as the categories/other meta data, it make sense/straight forward.
edit: I do want to add "Thinking about" is not the same as having already built it. I was concerned about vulnerabilities but it turns out you can use it as a stream rather than file upload and not have the data touch your system. I guess other than escaping/parameterized bindings, read up on other potential exploits.
I like where you're going.
A good market for that would be the no-code / low-code community.
Great, thanks!
It is a good idea.
Is spreadsheetdb.io similar to your idea?
I've used fieldbook.com for this same purpose, which also allowed easily connecting models across different sheets (like assigning a post to a user).
It was the only solution I could find to let a client enter their own seed data for many to many data models in a laravel app.
Edit: looks like it's dead.
Something similar to take a look at as well would be https://airtable.com
It's not a GoogleSheet integration, so it's not the same niche, but has the same concept of "don't fuss with a database, use a super simple tool to store data, and access it anywhere". Could be some things to learn from as well as Sheetsu
Doesn't seem very hard to create. So launch it and see if you get traction and constant improve based on how users use it. :)
Often times, the idea you started with may not be the idea/product you end up with it. Put some stakes in the ground by create something and launch it is the best way.
Hey there looks like a good product idea but I am not sure if people would pay for it.
I had initially faced this problem while working on a simple CRM for my startup google sheets was really complicated to set up on a server and the methods for fetching and writing was a bit confusing.We ended up moving to Airtable which worked smoothly.
That's a great idea. Good luck!
Thanks!
Looks interesting to me!
Sheetsu's pricing model makes it impossible to use their product in small applications / non-commercial side projects.
Would be cool to have CORS configuration + requests limit for one IP address so I can use it right from the client side.
0.01/request is of course very very expensive.
I don't think this works in all cases, because many people share public IPs (that your server ends up seeing). For example, people on the same intranet (in an office) who use your app will all have the same IP.
Great, thanks for your feedback!+
0.01 was just a suggestion. Actually, I had no idea at all about how it should be priced. Maybe I should just look at Sheetsu prices and lower them down, as suggested above.
How would you differer from sheetsu?
I think the interface and the service itself would be much simpler.
Fair enough then, I think it can have a market. Just be careful about the pricing, $0.01/request looks really expensive to me!
Okay, thanks for your feedback. Maybe it would be better to have flat pricing?
I'd have a look at the pricing of sheetsu and lower the tiers, since they already validated the pricing model. In the end, your product is simpler, so it's reasonable to have a lower pricing.
I see, I'd probably do that.
While it might be tempting to have lower pricing, see if you can have the same pricing but instead improve the product or a specific part of the product. Easier/simpler to use could be a USP.
Playing the lower-pricing game can only go down and there are no winners in the end.
I see what you say. I don’t know sheetsu et al., but I don’t think he could reach the same quality/features upon launch. Correct me if I’m wrong @sheets. Therefore, how could you acquire customers at the same price, but with a lower quality product? Honest question, I mean my solution was to lowerer the price, but I see what you said. I’m curious to know how would you act.
I see, very interesting discussion. I think I can developer a simple alternative to Sheetsu, but still don't know if it would be that better for my potential customers.