Live data from Hacker News

Show HN: Using Google Sheets as the back end/APIs of your app

zerosheets.com

131–140 of 171 posts

Re: Show HN: Using Google Sheets as the back end/APIs of your app

#132

Just beware of the modern version of the "Excel noob trap" which lots of investment banks fell into in the 80s and 90s. Spreadsheets are amazing generic calculating frameworks and you can do a ton in them, so a lot of banks ended up building a huge ediface of excel spreadsheets that ran a wide variety of risk, pricing and operational functions. With a few plugins and extensions you can really do amazing things with t…

Totally agree. I’m working for a company right now that put off ‘refactoring’ their tangle of spreadsheets and database query export ‘pipelines’ for over a decade. We are hemorrhaging money right now because it does not scale. And you won’t notice that until it all breaks down.

Now you have effectively created bottlenecks for all critical processes because simultaneously working on spreadsheets is about the most dangerous thing you can do. Data integration becomes a perilous and time consuming affair; there’s no easy way to guarantee conformity between spreadsheets.

You paper over these problems with more code than you ever would have had if you switched to the proper tools earlier.

Re: Show HN: Using Google Sheets as the back end/APIs of your app

#133

Just beware of the modern version of the "Excel noob trap" which lots of investment banks fell into in the 80s and 90s. Spreadsheets are amazing generic calculating frameworks and you can do a ton in them, so a lot of banks ended up building a huge ediface of excel spreadsheets that ran a wide variety of risk, pricing and operational functions. With a few plugins and extensions you can really do amazing things with t…

But it would be ok maybe to use sheets just for storage. I wonder what size limitation do they have.

Re: Show HN: Using Google Sheets as the back end/APIs of your app

#134

Funny story. Before pivoting my startup to Loom, we were a user testing company named Opentest. Instead of spinning up a DB and creating a dashboard for my co-founders to look at who requested certain user tests, I just dumped everything into a Google Sheet. It was so good. No downtime. Open access. Only 3 people looking/editing, so no conflict. Didn't have to deal with database upgrades or maintenance. I often think…

If you can do this one-way data dump, it sounds like a good idea. The issue starts when you have seven different sheets that is supposed to authoritatively control some other processes. The people writing in the spreadsheet can basically do any kind of mutation to the spreadsheet, so it will break extremely easily.

Re: Show HN: Using Google Sheets as the back end/APIs of your app

#135
post #22

Earlier quoted context omitted.

Hello!! Google limits for me are: 300 Read requests per minute 300 Write request per minute Since Ive just launched it, that number is far far away from being reach. (If it happens, the number can be increased). Regarding the SSL cert, some other users pointed the problem but I can`t replicated. Tried with many different browsers. Im not sure about whats happening, it`s always working for me but I will keep digging.…

Have you thought about auto-installing https://developers.google.com/apps-script/guides/triggers into the connected sheet, and maintaining a cache of the data that you invalidate onEdit? Would likely improve read latency dramatically, though it would make reads eventually-consistent. To others seeing this - has anyone else ever tried this approach? Are there players out there who do this and have SOC II etc. data sec…

Disclaimer: I work at Glide but not on Google Sheets integration.

Triggers/AppScript - not that I am aware of right now...

Everyone I know doing stuff with GSheets (including Glide) is using a full-sync approach with an optimistic write layer of some sort.

GSheets API frequently reports being unable to do things, sometimes because it's calculating (common for huge sheets), sometimes just because it's down, other-times because rate limits

My impression is it's not a great API to build on directly.

A trigger based system that captured writes and wrote them to an outbox sheet could drastically speed up the sync process however.

The reason why we don't use that approach is there isn't APIs sufficient to setup this sort of thing automatically (last time I checked at least) and it makes changes to the users sheets which isn't impossible to live with but is distasteful.

Re: Show HN: Using Google Sheets as the back end/APIs of your app

#136

I'm surprised no one's posted Spread API yet: https://spreadapi.roombelt.com/ It's a free Google Sheets / Apps Script you just paste to your sheet, and it turns the sheet into a full CRUD. It's kind of rate limited though but completely free! Edit: I've thought about creating a company around Sheets before, and the problem is that once you get to the "willing to pay" stage, you also kind of outgrow Sheets. I'd rather…

Looks neat! Seems very limited though.. like you can't even insert multiple lines in one request?

Re: Show HN: Using Google Sheets as the back end/APIs of your app

#138
post #122
post #96

Earlier quoted context omitted.

I read your comment and your blog post and I still don't understand what happens when I put a link to a sheet in the text box and click Go.. what happens? You say your inputs and outputs are all in the sheet.. ok.. what does the button do? Are you just calling some API and giving it the sheet as the input, and then writing the output of the call back to the sheet? So then these Single Button Apps are just API endpoin…

Same here. If the idea was to make it so non-technical people can use the google sheets + API app, just put a script in the sheet that calls the API? It will appear in a menu inside google sheets itself

You can even put a button on a sheet to trigger a script

Re: Show HN: Using Google Sheets as the back end/APIs of your app

#140
post #128

Just beware of the modern version of the "Excel noob trap" which lots of investment banks fell into in the 80s and 90s. Spreadsheets are amazing generic calculating frameworks and you can do a ton in them, so a lot of banks ended up building a huge ediface of excel spreadsheets that ran a wide variety of risk, pricing and operational functions. With a few plugins and extensions you can really do amazing things with t…

Sadly many companies WANT to be in the excel trap...

Can you elaborate? I understand the reasoning "we need to grow no matter the cost, will deal with problems when they arise", but deliberately sabotaging yourself doesn't sound reasonable.
Post reply on HN