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.
In 2022, we made it easy to seamlessly access popular Education Technology tools directly in Google Classroom. We partnered with 20+ EdTech companies, including Kahoot!, Pear Deck, IXL, ReadWorks, and Nearpod, to build Google Classroom add-ons. These new integrations let educators and students easily find, use, and grade great content in their favorite EdTech tools without having to navigate to external websites and apps.
Today, we’re excited to make Classroom add-ons generally available to all developers.
Given the number of Apps Script users in EDU today’s announcement the Google Classroom add-ons now generally available for anyone to publish is probably welcome news. Whilst Google Classroom add-ons have been around for a couple of years they have historically only been created by a select few of Google partners.
Before jumping in something key to keep in mind is that while Apps Script offers a low-entry approach for most Workspace add-ons, Classroom add-ons require more technical expertise. They involve building a web application and integrating it with Classroom’s functionalities using the Google Workspace Marketplace SDK. Proficiency in web development languages like Python, Java, or Node.js is recommended and Google have published some example implementations for Python, Java and Node.js.
Whilst there are differences there are overlaps. For example like Workspace and Editor Add-ons you will need to create a Google Cloud project to publish to the Google Workspace Marketplace. As part of this you’ll have to also provide key information such as terms and conditions as well as going through the OAuth verification process.
The Google Developer documentation and other resources are linked from the source announcement.
Open-source made me a better developer, and can do the same for you.
TLDR;
This is our final stretch! We’ve navigated through building an Apps Script library, and now it’s time to discuss how you can contribute. Here’s a quick rundown of what we’ll cover:
GitHub Flow: Learn to fork the repository, create a feature branch, and make a pull request.
Guidelines: Tips on ensuring your pull request gets accepted.
Code of Conduct: We won’t delve into this, as respectful behavior is the default expectation.
License: Our library uses the MIT License, which is pretty much the one that lets you do anything you want with the code.
Issues: I will post issues that I consider a priority, but feel free to tackle any of them.
Process: Follow the steps outlined in our CONTRIBUTING.md file.
As a reminder, here are the links to the repo and the NPM page.
But first, let’s talk about what you should do before you open a pull request.
Everyone says use Google Apps Script libraries for easier maintenance — I found a better way. Here’s why NPM modules might change the game for you too.
Last time, we covered how to deploy our library as a native Google Apps Script (GAS) library using Vite, GitHub Actions, and clasp. This setup is efficient, but there’s a notable drawback to using Apps Script libraries.
According to the official guide: “Warning: A script that uses a library doesn’t run as quickly as it would if all the code were contained within a single script project. Although libraries can make development and maintenance more convenient, use them sparingly in projects where speed is critical. Because of this issue, library use should be limited in add-ons.”
Apps Script is not known for its speed, being a free runtime. Slowing it down further by using native GAS libraries is generally not advisable. Therefore, I prefer to avoid native GAS libraries whenever possible.
Instead, it’s much more efficient to bundle your dependencies directly into your source code, similar to how it’s done in Node.js. This is where NPM modules and Vite come into play.
In this post, we’ll cover:
Which NPM modules are compatible with Google Apps Script and which ones are not.
How to use NPM modules in your Apps Script projects.
Forget everything you know about deploying Google Apps Script, because the typical ‘Deploy’ button is not part of our strategy.
TLDR;
In the previous posts in this series, we focused on preparing our tools and setting the stage. We reviewed our project’s functionality, explored the project structure, and delved into the source code. We also discussed the pros and cons of using JSDoc versus TypeScript and covered essential developer tooling.
Today, we’re finally getting to the fun part—deploying something! We’ll start by deploying our library as a native Google Apps Script library. But there’s a twist: we will do it the proper CI/CD way, avoiding the typical “Deploy” button in the online IDE.
Side note: I always avoid the online IDE as it feels like my hands are tied when I use it.
Instead, we’ll use Vite with a custom plugin to bundle our library and GitHub Actions to handle the deployment.
In this series about deploying Google Apps Script libraries, Part 2 dove deep into Test-Driven Development (TDD) and highlighted jest as my go-to tool for outstanding outcomes. Now, let’s broaden our toolkit with additional essentials that not only elevate our development standards but also make our codebase more welcoming to collaborators.
First up, we’ve got ESLint. Linting, for those unfamiliar, is the process of running a program that will check your code for potential errors.
Next, we introduce Prettier, which takes our code and formats it into a structured style that you define. Think of Prettier as the stylist of your codebase, making sure everything looks ‘pretty’ and readable by cleaning up those messy or inconsistent styles left behind.
We also employ Husky, a tool for managing git hooks. Git hooks are scripts you can set to run before or after events like commits, push, and receive. Husky ensures that tools like ESLint, Prettier and Jest run every time you commit changes, helping catch issues before they hit production.
These tools are indispensable not just for solo developers but also for teams looking to contribute to the library. By maintaining consistent, pre-defined high standards of code hygiene, we ensure that our library remains robust, clean, and maintainable.
Prerequisites: You should be familiar with git, an essential skill for any developer. If you’re not, I recommend checking out the beginner’s guide at FreeCodeCamp. Additionally, being able to code locally and understanding clasp is crucial. If you need a refresher on this, visit my earlier post on setting up your local environment. Once you’re set, we can dive into making our development process even smoother and more efficient!
Here are the links to the repo and the NPM page again.
About a year ago, a notable shift occurred in the developer community when SvelteKit made the decision to transition from TypeScript to JSDoc, specifically stating that TypeScript was not the ideal choice for developing libraries. This move definitely raised some eyebrows and stirred the pot among developers. Initially, I was skeptical, perceiving it as a regression rather than progress. TypeScript was even featured in one of my previous blog posts as a recommended tool. However, this decision began to resonate with me over time, leading me to adopt a similar approach in Google Apps Script. The reasons for this shift are manifold, with some being universally applicable and others specific to the peculiarities of Apps Script.
Here are the links to the repo and the NPM page again.
Let’s dive into why TypeScript was chosen in the first place and what has changed to endorse JSDoc over it.
Following up from last week, we get into how I built the table() method in our ConsolAS class, using test-driven development (TDD). This is a cool way to make sure everything works perfectly by testing each part before we fully build it. We’re aiming to make it work just like the console.table() function in Google Chrome, which is pretty handy.
To subscribe to events using Apps Script, you can now use the Advanced Google Workspace Events service.
In the May 02, 2024 Google Apps Script release notes it was announced that a new Advanced Google Workspace Events service is available to let developers use the Google Workspace Events API directly in Google Apps Script. The Google Workspace Events API is a relatively new API, which was released to developer preview in January, 2024. The Google Workspace Events API uses a subscription model to handle resource changes. When you create a subscription, you specify the target resource (such as a Google Chat space or Google Meet meeting space) and the event types that you want to subscribe to. The API then sends notifications to your specified endpoint whenever an event occurs for that resource and event type.
In the case of the new Advanced Google Workspace Events service the linked documentation includes samples for using the new service with Google Chat. It’s worth noting that the Advanced Google Workspace Events service is designed specifically on managing subscriptions to events. While it lets you to control the flow of information and manage event subscriptions in your Apps Script projects, the actual processing and handling of event data occurs separately.
The linked documentation page provides sample code as well as outlines all the prerequisites.
Here’s the scoop: While tinkering with a project, I needed a way to pinpoint the last row of data in various sheets — essentially to catch any “orphan” values lurking there. Typically, something like console.table() would be the hero of the day, allowing me to effortlessly display data like so:
