tadam313 / sheet-db Goto Github PK

Instead initiating many requests simultaneously in async manner, the same effect could be achieved by using batch operation, so handle every entires in one single batch operation instead of multiple.

Upon worksheet creation, the column count/row count values are burnt-in, meaning a worksheet area won't extend as the user inserts new entries. This eventually end up causing an error if the content grows too big. The insertion logic should be aware of this behaviour and dynamically increase the worksheet area by X lines/columns. (where X should be significantly bigger than the amount of entries being inserted to avoid doing this on every insert)

The Google Sheets v3 API will be shut down on March 3, 2020. Follow this migration guide to update your applications so that they use the v4 API. Learn more

https://developers.google.com/sheets/api/v3/authorize

It seems that we need to upgrade our API to v4 before March 2020.

Update Sep 2020

Here's a great google spreadsheet API module with v4 which we can learn from: Google Sheets API (v4) wrapper for Node.js

My google spreadsheet is public read & write able.

My code t.js is as the following:

const connect = require('sheet-db')

// https://docs.google.com/spreadsheets/d/106lfsqgEOMqRX3apK3qGbVcjQIaCK7EudHHI3-TpEKQ/edit?usp=sharing
const sheet = connect('106lfsqgEOMqRX3apK3qGbVcjQIaCK7EudHHI3-TpEKQ')

sheet
  .info().then(console.info)
  .catch(console.error)

It show the following error message when I run it:

$ node t.js
Error: The response contains invalid data
    at _callee$ (/home/huan/git/mike-bo/node_modules/sheet-db/lib/rest_client.js:44:31)
    at tryCatch (/home/huan/git/mike-bo/node_modules/regenerator-runtime/runtime.js:65:40)
    at Generator.invoke [as _invoke] (/home/huan/git/mike-bo/node_modules/regenerator-runtime/runtime.js:303:22)
    at Generator.prototype.(anonymous function) [as next] (/home/huan/git/mike-bo/node_modules/regenerator-runtime/runtime.js:117:21)
    at step (/home/huan/git/mike-bo/node_modules/sheet-db/lib/rest_client.js:588:191)
    at /home/huan/git/mike-bo/node_modules/sheet-db/lib/rest_client.js:588:361
    at process._tickCallback (internal/process/next_tick.js:68:7)

The current process is very tedious. Especially when a token expires need to manually reissue the request with the newly fetched token which is delegated to the user. This results in many manual preparatory/integration work before someone can start using this package. The amount of LOC spent on integrating this package should be dramatically reduced.

If the current process can not be improved anyhow, need to provide built-in authentication solutions (e.g separate auth namespace) to mitigate this problem.

Keeping authentication detached seemed a reasonable way, but it should not degrade the ease of integration.

The current callback like API is very obsolete. Promises are clearly the direction of JS world and this project should follow that.

The idea is that every high-level call (user facing) would return a promise instead invoking a callback. Here we need to bear in mind the backward compatibility so might need to support both callback/promise way. Maybe worth considering ES6 transition as well, just random thoughts...

Hi @tadam313 !

I search a lot on the internet and try to find a MongoDB interface for the google spreadsheet, but I found nothing.

Then I try to search the npm module name as spreadsheet-db, it's a 404.

At last, I try sheet-db and I arrived here! It seems is exactly what I want, I will try it later.

Do you want to support TypeScript for your module? If so, I'd love to contribute.

We have two options:

1. Add a TypeScript definition file to package.json
2. Rewrite the whole project into TypeScript (which I think it's worth to do)

I would love to help you with either of the above two options, please let me know what I can start with if you want it.

Thanks for your great module, and I hope you have a nice day!

Huan

A script or a tool will be a great help for the user to get the token.