←back to thread

356 points joaovcoliveira | 6 comments | | HN request time: 0.002s | source | bottom

Hello everyone!

At a company I worked for, we needed to develop an MVP (basically a web page) and apply certain business logic to a Google Drive spreadsheet that was frequently updated by the Sales team.

In this case, we had two options:

Develop a backend to replace the current spreadsheet and have the sales team use it as a new "backoffice" - This would take a very long time, and if the hypothesis we were testing was wrong, it would be time wasted.

Create the web page and use Google's SDK to extract data from the spreadsheet.

We chose to go with the second option because it was quicker. Indeed, it was much faster than creating a new backoffice. But not as quick as we imagined. Integrating with Google's SDK requires some effort, especially to handle the OAuth logic, configure it in the console, and understand the documentation (which is quite shallow, by the way).

Anyway! We did the project and I realized that maybe other devs might have encountered similar issues. Therefore, I developed a tool that transforms Google spreadsheets into "realtime APIs" with PATCH, GET, POST, and DELETE methods.

Since it's a product for devs, I think it would be cool to hear your opinions. It's still quite primitive, but the basic features already work.

https://zerosheets.com

Show context
maliker ◴[] No.40016158[source]
Great concept. Congrats on launching.

Do you have a sense for how much usage Google will allow on a given sheet or user? I.e. will Google shut down the API after a certain usage level?

(Side-note, your SSL cert seems to be having trouble, i.e. www.zerosheets.com is correctly encrypted, zerosheets.com is not.)

replies(1): >>40016396 #
1. joaovcoliveira ◴[] No.40016396[source]
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.

Thank you for your comment bro :)

replies(4): >>40016597 #>>40016790 #>>40018523 #>>40018818 #
2. hankjacobs ◴[] No.40016597[source]
I get an error on Chrome as well.

From what I see, the Common Name for the cert at https://zerosheets.com is `*.ip-66-228-52-143.cloudezapp.io` rather than zerorsheets.com. It's issued by Let's Encrypt. www.zerosheets.com is issued by Amazon. Hope that helps.

3. btown ◴[] No.40016790[source]
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 security measures?

replies(1): >>40021933 #
4. davidraedev ◴[] No.40018523[source]
Same issue here. At least on firefox initially the bare domain shows the error, but if you visit www and then try to load the bare domain it will then redirect to www on subsequent loads. I was able to replicate in a private window.
5. buzer ◴[] No.40018818[source]
curl is good for isolating issues. Here's requests to https://zerosheets.com & https://www.zerosheets.com: https://gist.github.com/Buzer/67adedefe59f9efdf3b16b0b8def11...
6. jpgvm ◴[] No.40021933[source]
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.