This post introduces a library that can summarize selected columns from multiple sheets across multiple spreadsheets into 1 spreadsheet, as well as to optionally apply a public/private key data encryption scheme to selected columns, all via a simple JSON definition file.
Bruce Mcpherson continues to be one of my favourite Google Apps Script authors and often you get to gain an insight into his development process. This latest post is the latest in a series that follows a post on Super simple cipher library for Apps Script encryption and decryption. The source post shared here continues this journey, in particular, highlighting the use of Google Sheets Developer Metadata to store data bound to the spreadsheet.
Google Apps Script has some amazing built-in stuff. It gives us native access to all Google apps like Sheets and Gmail, seamlessly integrates with GCP services like BigQuery, allows for the building of interfaces with HTML and CardService, facilitates the creation of simple webhooks/APIs and web apps with simple and efficient client-server communication, can make use of any API through UrlFetchApp, and can be bundled into add-ons for efficient distribution. In my experience, it’s enough for 99% of all Google Apps Script developers.
However, one thing that Google Apps Script is missing is modules. NPM has an extremely impressive database of JavaScript modules that don’t automatically integrate with Apps Script. Of course, in Apps Script we have libraries, but the selection is extremely limited and there is no marketplace for those. By the way, who wants to participate in creating one? Let me know in the comments! However, the very first warning on the libraries documentation page notes that libraries make Apps Script slow. Well, Apps Script is already far from being the fastest programming language on Earth, so slowing it down further is not an idea that I’m a fan of!
But what if I told you that there actually is a way to use some NPM modules in Apps Script? You just need to bundle them with Webpack. Not sure what I mean? Keep reading.
This repository is an example of how to setup an automatic CI/CD process for Google Apps Script using GitHub Actions.
This solution come via Dimitri S on Twitter and provides a way to setup a continuous development workflow for Google Apps Script using clasp and Github. The basic recipe appears to be is you develop your code locally using your preferred IDE. You then use clasp to push your code to GitHub, which triggers a GitHub Action to deploy your code to script.google.com.
This article discusses row-level security in Google Data Studio and shows how community connectors can be used to overcome the limitations of the native feature when accessing data stored in Google Sheets.
I don’t think one of our summaries could ever do justice to this contribution from Pablo Felip. The post has a very thorough summary of row-level security and how Community Connectors coded in Apps Script can be used for additional levels of functionality.
Google Apps Script is handy, and it will help you a lot in your work. However, as you use it, you may hit a big wall. That is the six-minute limit on execution time. As the official documentation states, the maximum allowed time per execution of Google Apps Script is 6 minutes.
If the script execution time reaches 6 minutes, the script will stop suddenly, and an error message “Exceeded maximum execution time” will be displayed.
For as long as Google Apps Script has been around there have been various solutions published for handling the 6 minute execution limit. This post from Inclu Cat presents a nice overview and solution for the execution limit.
More technically, this library can be used to send http requests via UrlFetchApp.fetch or UrlFetchApp.fetchAll, interacting with api endpoints in raw form. By bringing it down to a lowest layer on this platform, you get the following benefits:
All of the options, features, and abilities that are available. No compromises.
Ability to batch the requests in bulk. Performance can be significantly improved and run times lowered.
If you’re looking for a way to duck under the 6 minute limit to your scripts, the last bullet point should be particularly interesting.
Este artículo presenta eMayordomo, un desarrollo GAS capaz de vigilar un buzón de Gmail y responder automáticamente y de manera condicionada a los correos electrónicos procedentes de diversos formularios web, enviando mensajes preparados de antemano. Estas respuestas preparadas soportan HTML, imágenes en línea, archivos adjuntos y emojis.
Google Translate: This article presents eMayordomo , a GAS development capable of monitoring a Gmail mailbox and responding automatically and in a conditional manner to emails from various web forms, sending messages prepared in advance. These prepared responses support HTML, inline images, attachments, and emojis
For non-Spanish speakers you’ll have to hit Google Translate but it is well worth it for the very thorough documentation Pablo Felip has prepared, which includes the source blog post and GitHub repository. The repository is particularly useful to look at as Pablo has taken the time to document and explain the various Google Apps Script functions he has developed, methods used and potential issues/limitations when interacting with a Gmail inbox.
Sometimes things fail — that’s a fact of life and programming. So as a programmer, you’re going to have to write error-handling code. Thankfully TypeScript has some handy features which can help us to create simple and maintainable error-handling code.
James Elderfield recently joined us on Totally Unscripted to share some insights into the infrastructure used at Supermetrics used to support the development of their Google Sheets Add-on and Data Studio Connector. As part of their stack James highlighted how they used TypeScript to write code complied to use in Google Apps Script. This post isn’t Apps Script specific but provides some useful tips on using TypeScript for error handling.
Use Github as a back end for caching large objects across platforms. It’s possible to use a github repo as the back end for a caching service, and by taking this approach we can share data between Apps script and multiple platforms. It also means you can retrieve the data with the git CLI in addition. It works in exactly the same way as all the other backends. … Using a regular git Repo means you can make it private and share it using the tools already built into Github.
You know that idea you always keep at the bottom of your backlog for that elusive day you’ll find enough time to address? For me, it’s the possibility to connect a chatbot to an SAP system.
Julien Delvat shares how you can connect the SAP Graph API to Google Chat with Google Apps Script. The post provides details of the entire development and deployment process with useful tips on how you can extend the project.
