Google Spreadsheets and Python
twilio.com
twilio.com
- Fetch deals closed and lost hourly from Salesforce
- Fetch for each of our 14k+ paid accounts usage metrics using our Insights product
- Pull both items into a nice color-coded business dashboard that is near realtime
- Send said dashboard out as a PDF to a bunch of stakeholders daily/weekly
- Save PDF snapshot into Google Drive so I can easily pull up historical reports
PS: Google Sheets is definitely much slower for pure spreadsheets than Excel, no question about that. But by using cloud-based JavaScript + custom code, I can often work around that issue by writing functions that process the data quickly and report on what I need. Ultimately I end up getting much more out of it than Excel.
Why? Because they could take it all away --and I do mean ALL-- overnight. Email, apps, etc.
I've seen many people run into the Google ban for reasons not more complicated than not being experts and using one of Google's tools in a way that triggers an algorithmic ban. And this doesn't have to have anything to do with fraud or scams.
Had one client, probably ten years ago, who moved all of his 200+ domains to a service Google introduced at the time called "Google for Domains". A domain parking service with ads inserted into the parked domains auto-magically by Google. Prior to that all of his domains were parked at GoDaddy, who used Google to stuff ads into the domains. As soon as the service was offered he figured it was a good idea to remove GoDaddy as the middle-man in that equation.
He transferred all of his domains. There was an approval process. All domains were approved overnight. Done deal. Right?
Wrong! Two days later Google sent him an email informing him that all of his Google accounts were now permanently suspended (aka: closed) with no recourse. Reason given: Unusual click activity on some of the domains parked with Google for Domains.
This guy ran (runs) a multi-million dollar manufacturing business. The very idea that he would sit there clicking on ads to earn a quarter of a cent per click is, well, stupid.
Anyhow, this one event cost him all of his Google tools. His email, calendar, contacts, apps and whatever else he was using at the time. No recourse. Not conversation with a human being. Nothing. Done. Puff. Evaporated.
Since that one event I have been of the opinion that using any of these Google tools for a business is, to put it plainly, stupid and dangerous. You could be betting the farm on a petulant algorithm and no customer service of any kind to protect you from it.
I still have Excel files from decades ago that I can open and manipulate today. Microsoft could go out of business and I could still open these files. And the software has never lacked functionality, either directly, through add-ins or programmability.
The bottom line for me is that if something is business-critical it isn't a good idea to rely on a service that could be yanked overnight (I do mean that literally). If Google had customer service and a human (and humane) process to deal with issues it would be a very different story. I don't want free stuff. We have tens of thousands of dollars invested in all kinds of software. I want stuff I can rely on because my businesses depend on it.
The only way you are going to have to security is if you pay for well supported software that has a team behind it who understand how important it is for a business to have the ability to wake up every morning knowing that the tools they come to rely on for their daily work won't evaporate overnight.
I truly don't care how many shinny new things, candy and chocolate Google throws on the table. Until they prove they understand this one point they represent a business-killing risk nobody should be willing to accept.
BTW, this is a problem with nearly all Internet giants. Facebook, Amazon and others are horrible companies from the standpoint of how they deal with their business customers.
In my experience Google provides amazing service for tools that you are paying for. If you're using Google Suite/Apps to access your sheets, you should be just fine.
> I want stuff I can rely on because my businesses depend on it.
Well we're talking about using Google spreadsheets as a backend for an app. It should go without saying that this wouldn't be a mission-critical use.
However, I can assure you that Google definitely has a customer support department - I work with them every day =).
Also - it's important to distinguish between the free products we offer - and the paid products - where you actually give us money. In the latter case, there is nearly always a customer support hotline, and in many cases, a binding SLA agreement.
I work in Google Cloud, on the support organisation side of things - and I can confirm there is definitely phone support (along with chat and email), we do have SLAs on all of our products and you are definitely speaking to a human. It's not particularly hard to reach a person - either go through your admin panel (https://admin.google.com - click the big question mark), or all of our 24/7 support numbers for each country are right there on the website:
https://support.google.com/a/table/3247295?hl=en
That's on the business side. On the consumer side, the phone numbers shouldn't be too hard to find either on a search e.g.:
https://support.google.com/googleplay/answer/7100415?hl=en&r...
My own anecdote - several years ago before I started with Google, I subscribed to Google Play Music - I accidentally un-favourited a track once, and I couldn't find a way to find it again. So on a whim I rang Google Play Music support, and went straight to a person within seconds. She was very friendly, and tried to help me find the history - unfortunately it wasn't there, but the customer service was pretty damn good - a heck of a lot better than all of my experiences with several un-named mobile phone and broadband companies. (Hint: I'm in Australia)
Disclaimer: I work for Google.
Let's say I setup a site and have AdSense place ads on it. I don't touch any of the ads. I never click any of them. Yet, for some reason, the ads see a bunch of click activity. The reasons can be many, from sheer randomness to a competitor using it as an attack vector (to deny revenue and more).
I have seen this precise scenario lead to the absolute shutdown of a Google account. And that means every single service, including email and docs. Gone. Done. No recourse. No way to even recover the data.
Has this changed?
Do you have a way for people affected by such algorithmic issues to engage in a conversation with something that does not resemble a totalitarian regime?
The paid vs. free part is immaterial. People are relying on your products and offerings. Free is a strategy for dominance. I can understand free products not having a human in the loop. What I can't understand is the dictatorial/totalitarian relationship with your users, who, free or not, have come to rely on these tools.
However, my understanding is normally AdWords accounts are suspended for billing/fraud related reasons (e.g. you don't pay your bills) - e.g.:
https://support.google.com/adwords/answer/2375414?hl=en-AU
If you AdWords account does get suspended, there's a form to appeal it here:
https://support.google.com/adwords/contact/pf_suspended
I haven't seen it lead immediately to the actual Google login itself being suspended. However, if your the actual Google account was suspended - there is a set procedure you can follow to un-suspend it - there should have been a link in the notification email.
Also - paid or free isn't immaterial - it actually does make a difference.
If it's a free account (E.g. @gmail.com), you can fill in the online forms to appeal the suspension.
If it's a paid account (i.e. part of a GSuite domain - or it's old name, Google for Work), then what often happens are individual accounts are suspended, and you talk to your own domain administrator to get that resolved. There are ways to get a domain suspended (e.g. you don't pay your bills) but they're usually fairly obvious.
(Disclaimer: I work for Google, but the above comments are my own opinions).
The various forms Google makes available for appealing suspensions are pretty much useless.
I urge you not to believe what I am saying here as well as not feeding within your own internal echo chamber. Use your own search product to search the 'net for the thousands of stories of various forms of algorithmic account suspensions, the damage they cause and how frustrating it is to get anywhere with Google.
Based on what I've witnessed personally and what I've read online the idea of relying on Google products for anything business critical terrifies me.
You --Google-- needs to truly care for it's clients and, as I said in a prior post, issue a guarantee. I am NOT talking about a guarantee of uptime for a service, that's irrelevant here.
What I am referring to are guarantees of service longevity as well as protection and recourse from algorithmic account suspensions. A business person needs to have the ability to address and discuss misunderstandings or problems and not have their entire Google-provided infrastructure evaporate overnight with nowhere to go.
To me the matter of free vs. paid is immaterial. Google and companies like Google use free services to gather and monetize audiences. For example, nobody would pay for search. Nobody would pay for a Facebook account. So you use free to bait the hook and capture audiences. This is a technique as old as the Internet, with browsers such as Netscape and earlier being the first land-grab-through-free-products.
If you are going to have a virtual monopoly by resorting to free products you also have to have the responsibility of not causing your user base irreparable damage by pulling those product either by early termination of the services or termination or suspension of account without recourse. At the moment you are large enough to not have to care about this one bit and nobody has challenged you in court for this terrible issue.
Start here and read through a few pages of links:
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e...
I don't think that's even possible.
For one - abuse is a real thing.
Just ask Amazon about abuse and spam on their AWS platform. There is a reason that you can't just type in any credit card, and spin up 100 EC2 instances, or send 100,000 emails - depending on signals, Amazon seem to manually verify some accounts. But on top of that, they take proactive steps to suspend accounts acting in suspicious ways.
We do much the same.
It is a hard problem, and undoubtedly there are false positive and false negatives. That is regrettable - but I don't think allowing AWS or GCP to become a free haven for spammers or abusers is the answer.
You are correct that we need good procedures to deal with appeals of these things.
Regarding never deprecating a product - Google has started many products, and some of those have been shutdown. I know there's a lot of angst on HackerNews about Google Reader in particular - I myself used it a lot in fact. However, taking off my Google hat - of all companies, they are usually the best about letting you export your data, or migrate it away. When a product gets shutdown, you usually have 6 months, a year etc. to export your data. Even before I started there, they had Google Takeout which basically lets you export your data from any Google product in portable formats e.g. mbox, JSON files etc. Open standards are important to us - e.g. see our work on Kubernetes.
If there's a specific are you think we're failing on - please let me know, and I'll see if there's anything I am able to share, or if there's somebody I can link you up with.
It’s a no-brainer to feed all sorts of metrics (business or otherwise) from let’s say a Django app into Sheets, and with Data Studio decision makers can have all the freedom to combine them into complicated dashboards in accordance with current business landscape, pinging engineers only if new things need to be tracked.
I use App Scripts to run API calls from a Google spreadsheet which is easy when the API has simple basic auth. But I've been stumped with Salesforce.
FYI: https://developers.google.com/apps-script/guides/sheets
Google Forms + Spreadsheet + Python works perfectly for use cases like this: it is free, scaling isn't a concern, users can view and modify data at any time, and users can create Google Forms at any time. If you are trying to help a non-profit and aren't planning on maintaining their systems long-term, this is a great approach.
Code for the project: https://github.com/georgeaf99/das-care-contact-forms
I would assume they just installed python on whatever machine they were originally using to hand-generate reports and the job of that person now is to just run the python script and wait for it to finish.
As another note, we realized that far more useful than using Google Spreadsheets as the canonical backing database, was to be able to bidirectionally synchronize it with our primary database. That way, users who wanted to annotate entities in spreadsheet form could do so in GSheets, always working with up-to-date data, and keeping track of "I updated a.x in the spreadsheet, but a.y was updated upstream, so merge the two." Here were the semantics of our integration:
Returns a list of updates between last_synced_data and sheet.
Subsequently, if upstream_data is provided, then load it into the sheet,
adding rows on the end as needed, or merging if there is a match in the merge_key column
(note that any updates to the live sheet data since the last sync
override any upstream data, and those live updates are returned without changing the live sheet).
If there's interest in seeing open-source code for all of this, we could definitely extract from our corporate repo (we're https://www.belstone.com/ ). Let me know!
(And the sync thing is neat!)
The Jupyter Notebook use case sounds great but if you move to something that is more critical use a real data store.
https://support.google.com/work/answer/6056635?hl=en https://gsuite.google.com/terms/reseller_sla.html
If you mean the free products e.g. Google Sheets with a consumer account - AFAIK, there isn't a contractual SLA per-se, but the uptime is pretty good =).
You can also see a status dashboard with historical status here:
https://www.google.com/appsstatus#hl=en&v=status
RSS feed link is at the bottom of that page.
(Disclaimer: I work for Google Cloud, on the Drive/Docs/Sheets side of things).
The status dashboard (https://www.google.com/appsstatus#hl=en&v=status) lists what's covered or not covered - table at the top is all covered services (e.g. GMail, Google Drives/Docs/Sheets/Slides, Google+, Google Groups, Hangouts, Calendar etc.)
The table at the bottom lists things that aren't covered (e.g. Blogger, Google Voice, Google Analytics, Google Realtime API) by the SLA.
I believe you can find the list of covered/non-covered service on the support site as well (https://support.google.com/).
And what do you mean by devs break something during the release?
Do you mean if we introduce a bug in the code, and it affects the availability of the API? Yes, that is covered as well.
You mention you've seen this before - I can't promise anything, but if you're hitting any issues here, or roadblocks, and you're a GSuite customer (i.e. you are paying us some kind of money, even if it's $5 a month), I can certainly try looking into it for you - ping me your details and I can reach out.
Has anyone looked at "Fusion Tables?"
A google search reveals that is what it is supposed to be.
There's also ODBC in AppScript (although I haven't tested it to tell you how well it works).
(work on Google Cloud)
I had a spreadsheet with a few hundred rows I was using to create Docs and send emails. I was running from scripts.google.com. Any operation running for longer than about five minutes would time out so I had to batch my work into smaller buckets and hit run a bunch of times.
still fantastic for quick-and-dirty tools and prototypes though.
Google Spreadsheets actually goes a long way (I've done some stuff using the IF function etc. in it), but obviously has its limits. So combining it with Python sounds interesting. Not sure if it's what I'm looking for, but I'll check it out.
That's crazy low, given that Google Sheets gives you 200,000 cells, or 10,000 20-column rows, for free.
EDIT: That was from 2009. The current limit is 2,000,000 cells per sheet: https://support.google.com/drive/answer/37603?hl=en
They do claim a "custom number" of rows in their "contact us for pricing" plan, but the 50k number suggests that anything higher than that would have serious perf downsides with their current architecture.
If that saying meant anything meaningful, Walmart, Safeway, Ford, etc would not exist. I think what you meant to say was, "don't target customers not willing to pay enough for a profit margin." Much less catchy, but at least it's not bullshit.
You said: "Every customer cares about cost"
There's a world of difference right there!
Appreciate you taking the time to comment but starting with "That's a daft statement" and ending with "bullshit", throwing in "I think what you want to say" for good measure? I must have hit a sore spot!
I didn't realize they had an API. I just looked it up and the documentation is so good it makes me tear up.
The trick with the documentation is that it lets you pick one of your own databases and it then makes all the examples relevant to that database!
Why doesn't everyone do that?
I want to be able to say "get me back record 56 and all of the linked records in a single request".
I ended up having to iterate over their "fetch all records of type X" endpoints and then gluing the data back together in-memory, which is a pretty nasty workaround.
IMHO Fieldbook has the best user experience anywhere for building and working with a real relational data model, including many-to-many relationships, sophisticated queries, and aggregated reports. We've done a ton of iteration with real users and hundreds of usability tests to make these features natural and intuitive.
Fieldbook customers use it on a daily basis for their core business information and processes, and they're very happy. Read our reviews here: http://www.capterra.com/database-management-software/spotlig...
But there's no need to be gripped by indecision! Just try them both, it's free. That will tell you which one works best for you. Message us in-app if you have any questions, we're happy to help you get set up!
And then I just found out about Fieldbook through your comment and it looks really good too. It's the only other product I've seen that is in the ballpark.
And then both founders are right here on HN pointing out more features.
We think Airtable is to spreadsheets/Access/Filemaker what Slack is to email (and fwiw, Slack itself uses Airtable http://bit.ly/2m58l4U ).
Specifically, our product offers the following (which to my knowledge Ragic/Fieldbook do not): x IMO a much more intuitive design x Native Android, iPhone, & iPad apps, as well as an electron desktop app ( airtable.com/downloads ) x Ability to create multiple views on the same table, each of which preserves its own filter/sort/visibility settings Multiple view types, including grid, grouped records, calendar, kanban, public forms, and gallery: http://bit.ly/2ky3WLB . x Inline collaboration i.e. @mentions in text fields, record-level comments x Many more useful field types x Visual revision history and snapshots x More integrations, such as with Zapier (see Zapier's writeups http://bit.ly/2lfGr79 http://bit.ly/2l3dZqG ), Slack, native calendars via an iCal feed, and Dropbox/Box/Gdrive/Evernote. x Greater capacity and smoother performance. x Full realtime sync for all changes, including schema modifications. x Lots of little things, like the ability to perform date calculations relative to today (i.e. a filtered view or formula that shows all projects due within 7 days from today and is automatically updated as time goes by), private share-links and embeds to give people access to a read-only view of Airtable without making them sign up for an account, inline document previews (e.g. view a text-copyable inline version of a .DOCX file)
Over 30,000 organizations already use Airtable--this includes tech cos like Airbnb, Box, Wework, and Tesla; non-tech cos like Atlantic Records and Penguin Randomhouse; educational institutions like CMU, Rice, and Stanford. We're growing our team and continuously releasing new enhancements to improve the product experience for all users.
You are correct that a modern MS Access alternative would certainly find its market.
It helps to have an experienced Salesforce admin though, I love the "citizen developer" that Salesforce always preaches but you can run into a mess if you don't think your data model through like any other database.
> cleaning up or directly working with SF data is an expensive nightmare in my experience even post-Heroku acquisition
Plenty of decent sync products to make this not stink. We happily pay for DBAmp every year to keep all our data on-site so we can expose it to other users and to keep a backup of pruned data.
You are leaving out storage costs. There's a minimum record size and then per licence billing, something like $250/GB/month.
If anyone needs some info/consulting - PM me via email in profile.
We have just over 5GB of total storage in our org and are only using ~45MB after a year because we planned out model around both storage efficiency and a sane data model.
You don't use fully normalized database designs in Salesforce if you can avoid it.
Isn't the tool that does what MS Access used to do, and that is available now, called "MS Access"?
I know several people using this as a quick backend database solution since they make it so easy to interact with data and expose a GET and POST API.
Edit: DabbleDB was awesome, and easier to learn than quickbase. But Twitter acquihired them and shut it down.
Google App Maker?
https://blog.google/products/g-suite/customize-your-g-suite-...
You're putting the entire Internet between you and your "database". You'll receive all the latency and general reliability problems that go with doing that.
In the v3 API, the first blank row terminated the column data set. Which meant you couldn't access rows after that blank row, which may have been accidentally inserted by a user. They may have addressed this in v4, not sure.
You have almost no ability to restrict the values the user enters. They can be literally any string and your app has to handle every possibility. Restricting type on a Sheet is not really possible.
What if a user is in the middle of editing the spreadsheet when your app attempts to access it? Since the sheet is constantly saving itself, and the user may not have completed their edits, are you getting incomplete or inaccurate data?
Also sheetrock, which is JS-specific: http://chriszarate.github.io/sheetrock/
I'm not the creator and have only used these for trivial tinkering.
I very successfully used Google Spreadheets as a backend for this. Putting all text and the conditional logic in the spreadsheet, and allowing the form to be built as a web page based on the Google Spreadsheet data for instant preview. This allowed the different members in the project to even work in parallel (thanks to collaboration features) with stakeholders - and implementing the feedback immediately themselves DURING the meeting - to see if the results was what they expected.
I wrote a small blog post about this, unfortunately in Swedish, but hey - there's a video at least :) http://www.rebelandbird.com/hyperiterativ-prototypning-med-g...
Another powerful way I use personally is to use Google Spreadsheet as a data backend for Jekyll based static websites. Here is a Grunt plugin I did to deal with this https://github.com/stpe/grunt-gss-to-json - example usage; my retro games collection http://games.stpe.se/
If you haven't checked it out in a while it's worth a shot.
On my team, we absolutely loathe Google Spreadsheets with a passion. Not necessarily the product itself. It actually is a truly capable and nice spreadsheet program. However, it encourages some extremely bad uses.
Because of the low friction of creating a spreadsheet versus, say, a database, business users have started using it as a substitute for something that should probably live in a database. For instance, I'm thinking of a particular portion of our sales organization that kept their business hierarchy in a Sheet, ie x person is on y team. Now, when you want to do analysis on the data you now have to use something similar to this library to retrieve the data and return it in a dataframe, which then pipes into the rest of your analysis and you end up with a finished product, be it a dashboard or some job.
What always happens is that you write your analysis, set it up to run regularly, and all of the sudden, three weeks later, you start receiving exception emails on the script. When you investigate it, inevitably some jackass business user upstream altered the "schema" of the document, breaking your downstream analysis.
In addition, once you have hundreds or thousands of these scripts running repeatedly, all reaching out to the Google API and in some cases retrieving 100s of MBs of data, Google very quickly rate limits you and you end up with dozens of scripts that broke.
Sheets is great for analysis and one offs, but you have to push back on your business users who will constantly try to use it as an operations platform because they don't know any better.
- "I need to see an analysis of xyz data."
- "Ok, where does the data live?"
- "Well, all of the facts come from this SQL table, and we pull from this web service, and finally we run it through this lookup table we maintain in Google Sheets."
- "Nope. Come back to me when you put that data somewhere else. Spreadsheets are not databases."
We wrap Google Sheets and Excel 365 in an API you can use to GET/PUT data along with a number of other goodies:
- security policies (e.g., row-based auth)
- file upload support
- email triggers upon upload
- a notion of "frozen" releases versus live dev data
(released but yet undocumented -- email hello@ for details)
I like looking at simple things like time series' of what I'm doing, eating, and how I'm feeling and then exploring correlations, and regression betas/t-stats. Stuff that's just a little bit to onerous to do exclusively in sheets. At the moment, I have to download the spreadsheet then open with pandas in a jupyter notebook and then run everything. I'm definitely going to use the python api from now on - thanks a lot for writing this!
Next step is a simple python-based web dashboard to view all the results - but keep sheets for CUD instead of having to build a custom one and use sql/sqlite.
This really is super helpful - thanks again!
You can create a BigQuery table that's powered by a Google Sheet, or export data straight to Sheets for quick and dirty data wrangling. Some folks use Google Forms or Google Sheets to update ledgers, SKUs, or what have you, with data flowing straight to BigQuery for analysis against clickstream data, server logs, Google Analytics data, weather, etc.
Love AppScript - so many possibilities for a "serverless" framework. How about ODBC?
[0] https://cloud.google.com/blog/big-data/2016/05/bigquery-inte...
(worked on BigQuery, work in Google Cloud)
In the case of Sheets, the most reasonable sharding scheme for the database backing it would be based on some collection of spreadsheets (in the extreme case it would be just one spreadsheet, but that probably wouldn't be practical). The important assumption here is that all the traffic pertaining to one spreadsheet will ultimately go to one server. So, if there's too much traffic coming related to one spreadsheet, you cannot really scale horizontally by adding more servers – you have to give it more resources. A single Google Sheet is sometimes used by lots of users at the same time, but they are able to limit it from the frontend (for example by making it degrade gracefully).
If the traffic comes from the API, it's going to be a little bit more tricky – especially that IIRC the current rate limiting for the API uses a daily quota, leaving room for some really nice spikes.
So, as soon as a website built using this hack get somehow popular someone is going to have a really rotten day with a lot of pages.
(Of course, this is pure speculation on my side, I have no idea how Google Sheets is actually built – I would be very curious if there's a smart way of overcoming this sort of issue.)
Even things like forums have many, many page loads than new posts.
For example, I've created a simple Apps Script for a Google Spreadsheets that uses OAuth to sync the list of client accounts from QuickBooks Online allowing us to keep track of more structured notes and segmentation, which QBO is still sorely lacking. The sync allows someone to easily update the spreadsheet with any new clients not in the spreadsheet.
However, if I was going to be doing any in-depth calculations and/or a lot of data then I'd probably go the same route with using Python externally.
Forgot to mention: The only thing I'm wary of, and have seen other comments in other threads about, is using it for anything more crucial like a core Excel/Access app because of the potential future change that'll break things.
Here's what it'd need:
- Spreadsheet like UI - Validations and field data types (major liability of spreadsheets) - Good forms integration - Custom code like Apps Script capability - Something around workflow and business logic
I think Airtable gets pretty close but I haven't been willing to switch cause of some limitations but I do like where they're going. I'm considering pulling the trigger for Salesforce but keep hearing that it's really easy to shoot yourself in the foot.
Disclosure: I work on Google Cloud, but not App Maker.
1. There were at the most 30-40 rows. Google Spreadsheets works amazing for small table sizes (although not as small as 30-40, I'd assume upto 1500-5000 should be fine as well).
2. All non-dev teams were EXTREMELY comfortable with Google Spreadsheets. For people with non-engineering backgrounds, a spreadsheet is an amazing, low-barrier entry to structured data which I believe is what made this solution amazing.
3. The dev team was completely removed as a dependency, and we had staging environments where they would run it first to ensure it was working properly, so a dev could be engaged only if their spreadsheet run wasn't working as expected or due to some other issue. The previous method was a huge email sent out to the devs, who would handcraft it into a JSON, which would then be passed to a script and then written to the database. This required every run to be effectively final.. there were only so many times one could engage a dev.
4. While we had to engage a dev to execute the script, it actually is very easy to integrate a menu option within the google sheets interface itself (if you are using Google Apps) for your domain, which would say something like 'Deploy to Staging', although we never got around to actually building this.
For startups where product turnaround time is required to be short, this works as an amazing solution as it makes so easy for non-tech guys to input data into the system. While there is no doubt that a fully developed panel for these operations would be the best solution, one doesn't always have the luxury of time.
Here's the project, and there's more rationale/investigation in the README: https://github.com/adam-p/danforth-east
(And... it looks like I need to update from Sheets API v3 to v4.)
https://runkit.com/58a77f7a86c06300158dfcf5/58a77f7a86c06300... https://github.com/digplan/gsheet-web
My best guess is that they don't want it to be too good lest it cannibalize their other product lines; I would say the very exact thing was the downfall of MS Access.
Of course this sounds like a silly conspiracy theory, but if you're very familiar with Excel, and especially the pile of smoldering crap that is VBA, I'd be surprised if you don't see at least a glimmer of truth.
That google now has a modern, capable language that can be used with google sheets, perhaps now MS will actually wake up and begrudgingly give their faithful users something they've been asking for, for literally over a decade.
Disclosure: I work on Google Cloud.
Easy and simple. Multiple auths and roles and it's cached, so it's not queried every minute ( pressing a link clears the cache)