Containerize apps script code and run it on cloud platforms such as Cloud Run outside the context limitations of the Apps Script IDE.
Bruce Mcpherson continues to expand the capabilities of his gas-fakes library, a tool that has already proven valuable for running Google Apps Script locally on Node.js. In his latest update, Bruce demonstrates how to take this a step further by containerising Apps Script code to run on Google Cloud Run.
For developers familiar with the constraints of the Apps Script IDE, particularly the execution time limits, moving logic to a serverless container environment offers a powerful alternative. With the release of version 2.0.2, gas-fakes now includes a managed configuration for Workspace Domain-Wide Delegation (DWD) enabling secure keyless authentication.
Essentially, this allows developers to package their Apps Script logic into containers, enabling execution on scalable platforms like Cloud Run, free from the constraints of the standard IDE.
Authentication and Service Accounts
One of the friction points in moving from a bound script to a cloud environment is authentication. Bruce highlights that while Application Default Credentials (ADC) work well for local development, a more secure method is required for Cloud Run. The updated gas-fakes CLI simplifies this by handling the service account configuration automatically.
The library supports two primary authentication types:
Domain-Wide Delegation (DWD): Recommended for production environments and cross-platform scenarios, such as Cloud Run or Kubernetes.
Application Default Credentials (ADC): A fallback method primarily for local development.
Containerisation Workflow
For those looking to deploy their own scripts, Bruce’s guide walks through the essentials required to containerise a project.
It is important to note that while the core logic can be written in JavaScript, you will need to manually set up the infrastructure configuration. The guide provides the specific code required for:
The Dockerfile: To mimic the Apps Script runtime environment.
Cloud Build Configuration: A cloudbuild.yaml file to manage the build steps.
To tie it all together, the article includes a deployment script (referred to as deploy-cloudrun.sh in the text) which automates the pipeline. It handles everything from creating the Artifact Registry repository and submitting the build, to monitoring the deployment.
Code Example
To help developers get started, Bruce has provided a dedicated repository containing a working example.
Note on usage: The repository contains the core Node.js logic (example.js) and a deployment helper script (named exgcp.sh in the repo). However, to deploy this successfully, you will need to combine these files with the Dockerfile and cloudbuild.yaml configurations detailed in the main article. Bruce notes there is more to come.
The example.js file illustrates how standard Apps Script services are imported and used within the Node.js environment. By requiring gas-fakes, you can access services like DriveApp or SpreadsheetApp using the exact same syntax you use in the Apps Script editor, bridging the gap between local Node development and the Google Cloud runtime.
Summary
This development opens up interesting possibilities for hybrid workflows where lightweight tasks remain in Apps Script, while heavier processing is offloaded to Cloud Run without needing to rewrite the core logic in a different language. If you are interested in trying this out, Bruce has provided example deployment scripts and a troubleshooting guide to help you get started.
Quarterly update on the shared bigquery dataset all about the Apps Script developer ecosystem on Github, with reports available on looker.
Bruce Mcpherson’s latest Gassypedia update offers a look at the Apps Script ecosystem, using publicly shared code on GitHub. The report analyses data from over 3100 developers and nearly 100 million files across 200,000 repositories. You can read the full report from the source link at the bottom but here are some key points:
Growth:Â The Apps Script community is still expanding, but at a slightly slower pace than before.
The number of developers increased by 4%.
Shared repositories grew by 3%.
Manifests increased by 2%.
Add-ons:Â There’s a 13% increase in Add-ons shared on GitHub.
Chat Add-ons are now most popular, surpassing Sheets.
Chat Add-ons increased by 18%, and Sheets Add-ons by 10%.
Calendar Add-ons saw a slight decrease.
Code Sharing:Â While the number of Apps Script developers and related content has increased, the total number of all types of repositories and files associated with them has decreased by almost 5%. However, the percentage of those repositories that are Apps Script related has increased.
Clasp:Â 25.2% of manifests showed Clasp usage, a 1% increase.
OAuth:Â 851 repos and 1008 manifests use the auth/script_external_request scope, a 6% increase.
Advanced Services:Â Drive is the most popular advanced service, used in 499 manifests.
Web Apps:Â 53% of web apps are public, and 81% are executed as the user deploying. 6% of web apps are created in Japan.
Libraries:Â oauth2 is the most popular library, with 236 users.
Key Takeaways
Apps Script is still a growing platform, with many developers sharing their work.
The rise of Chat Add-ons indicates the maturing of the platform for Google Workspace users.
More developers are sharing Apps Script projects on Github.
Explore the Data
Bruce’s full report is on Looker, with the data available on BigQuery. You can use this data for your own research and share any findings with Bruce.
A Google Cloud run hosted puppeteer with a graphQL interface … In this article I’ll show you how to use this (I’ve called it gql-puppet ) with Apps Script
One of Apps Scripts superpowers is the ability to make HTTP requests to external services. These can be requests to other product APIs, or as in the following example, your own services. In this post from Bruce Mcpherson you can learn how you can use Google Apps Script to interact with a service he has created on Cloud Run which has a deployment of the headless browser, Puppeteer.
To interact with Puppeteer, Bruce has added GraphQL as an application interface. GraphQL is a query language that allows developers to request specific data from an API, making it more efficient and flexible than REST, which often requires multiple requests to retrieve the same data.
As Puppeteer is just a browser there are lots of things you can do like take a screenshot, print a PDF or get the page content. With GraphQL there is an interface layer to do this as well as returning specific data from a webpage.
The article has various code examples for different use cases, such as taking screenshots, extracting table data, and creating PDFs from web pages using Google Apps Script and saving the data in Google Drive. Bruce is providing access to his combined Puppeteer/Cloud Run/GraphQL solution, gql-puppet but you can also find out how you can deploy it as your own service.
Shared cached data between multiple scripts with this enhanced Apps Script Cacheservice library
Bruce Mcpherson has shared a new Apps Script library, bmCacheSharer, which enables sharing of cache data between multiple Google Workspace projects. The library was originally created to solve the problem of sharing configuration data stored in a Google Sheet with multiple script projects.
The library includes a number of nice features to overcome some of the limitations of the Apps Script CacheService, such as the 100k maximum item size and the 6-hour expiration limit by incorporating features like compression, key digestion, and automatic refresh.
It also provides options for sharing cached values by using community keys. The library is designed to be flexible, allowing users to either use its built-in cache service or provide their own. Additionally, it offers a memory cache for faster access within the same script instance. The document includes code examples and explanations to illustrate the library’s usage and benefits.
All the Google Apps Script related github activity is now on Google Bigquery and Google Looker. Here’s how it was done.
Bruce Mcpherson has recently revisited his work on the visual Google Apps Script explorer tool, scrviz. Bruce has been working diligently to address limitations with the Github API and overcome quota restrictions. This new iteration still allows users to explore Google Apps Script projects and creators, but this time through a shared Looker Studio dashboard. The underlying dataset has also been made available on BigQuery if you would like to do your own analysis.
Follow the source link to find out more and explore the data!
Apps Script library to convert between file types, including OCR for image to documents, with a huge repertoire of conversion combinations.
The Drive API offers a whole range of conversions between mimeTypes, but it’s a little fiddly to figure out exactly how. This library takes a file and an a desired output format and converts it for you. Sometimes, there’s not a direct route – for example if you need to convert a word file to a pdf, it first needs to get converted to a Google Doc, then to a Pdf. This library automatically works out and actions any intermediate conversions required.
For those who are unfamiliar MIME types (mimeTypes) is a standard way of identifying a file’s content type, such as text, image, or audio. The MIME type for a file is usually used by applications to determine how to open and display the file. Google Drive is able to convert various files, such as a MS Word document to Google Docs.
Sometimes there isn’t a direct route and this clever library from Bruce Mcpherson can help alleviate the pain. The library works by first checking if there is a direct route between the input and output file formats. If there is, it simply converts the file. If there is no direct route, the library will use the Drive API to first convert the file to a format that can be converted to the output format. For example, if you need to convert a Word file to a PDF, the library will first convert the Word file to a Google Doc, and then convert the Google Doc to a PDF.
Knowing what mimeType to use can be a bit of a challenge but you can also use the library to give a list of known types, or if you prefer a more readable list of Google Drive export MIME types.
A useful library to create prettified HTML, XML GraphML and other markups directly from Apps Script or JavaScript.
A long, long, long time ago Apps Script had a Xml class which was deprecated in favour of the current XML Service. One of the nice features of the old Xml class was the Xml.parseJS() method, which “given a JavaScript array … returns an XmlDocument representation”.
The current XML Service doesn’t have a JavaScript to XML parser, but Bruce Mcpherson has recently shared a library that can be used to easily convert JSON objects into XML and it’s many recognised formats like HTML. Bruce’s post shows how to can create various HTML page elements including head sections and tables. It’s also worth checking out Bruce’s other post on “Create GraphML markups from Apps Script” which is included in the source link.
I thought it might be useful if you are learning Apps Script to be able to pull in examples to play around with. This latest release adds the ability to configure and clone projects from github directly into the Apps Script IDE.
We’ve previously highlighted Bruce Mcpherson’s visual Google Apps Script explorer tool, ‘scrviz’. If you are not familiar with this it is Bruce has figured a way to search and identify Google Apps Script projects publicly shared on GitHub. In this latest update to the tool you can now clone public Google Apps Script projects from scrviz straight into the Apps Script IDE.
The source link explains more about how you can do this:
