Recently, I worked on a project with a client who needed to parse XML files and convert them to JSON. Simple enough, right? The catch? These XML files were massive — each containing hundreds or even thousands of trades. Naturally, the first thing I thought of was Google Apps Script’s built-in XMLService. It’s reliable, widely used, and integrates smoothly into Apps Script. But when I ran it on a file with 1,000 trades, the parsing took 45 seconds! That’s painfully slow for an automation process.
[Editor: In a recent blog post, Dmitry Kostyuk has shared a valuable tip for developers working with Google Apps Script. When faced with the task of parsing large XML files, he discovered that the built-in XMLService was causing significant slowdowns. For files containing thousands of records, the parsing process could take an agonizing 45 seconds.
Dmitry’s solution? Using his Apps Script Engine (ASE) and the xml-js NPM library. By making this switch, he was able to achieve a remarkable 10x increase in parsing speed, reducing the 45-second process to only 4 seconds.
If you’re working with Google Apps Script and large XML files, click the source post link to find out how you can give ASE and xml-js a try!]
Welcome to the culmination of my Google Apps Script development journey — the Apps Script Engine. This isn’t just another template; it results from countless hours of refinement, driven by the passion to create the ultimate tool for Apps Script developers. Every ounce of my experience, every lesson learned, has been poured into building this robust, opinionated, yet highly configurable template. It’s designed to empower you to confidently and easily tackle even the most complex projects.
Developing Google Apps Script projects can be a pain, especially when dealing with modern JavaScript features like ES6 modules, the need for fast local development, and integrating NPM modules. The Apps Script Engine Template tackles these challenges head-on, offering:
Seamless ES6 Modules Integration: Finally, you can use this missing JavaScript feature with Apps Script.
Blazing Fast Local Development: Mock functions and promisified google.script.run calls make local development a breeze.
Front-End Framework Support: Includes Alpine.js and Tailwind CSS out of the box, with easy TypeScript integration.
NPM Module Support: Integrate NPM modules into front-end and back-end code effortlessly.
Automated Testing: Set up with Jest, so you can ensure your code works as expected.
CI/CD Integration: Easy integration with tools like GitHub Actions and Cloud Build ensures smooth, automated deployments.
Environment Management: Easily manage different environments (DEV, UAT, PROD) with specific configurations.
[Editor] This post from Dmitry Kostyuk introduces the Apps Script Engine, a template designed to streamline Google Apps Script development. It addresses common challenges by providing seamless integration of ES6 modules, fast local development, support for front-end frameworks and NPM modules, automated testing, CI/CD integration, and environment management.
The template simplifies the setup process, allowing developers to quickly create new projects. It offers a well-structured file system, including folders for compiled files, environment management tools, and source code.
Key features include the ability to use NPM modules in both client-side and server-side code, a custom Vite plugin for bundling, and Git hooks for automated formatting and testing. The template also facilitates environment management, making it easy to deploy code to different Google Apps Script projects.
For web apps, the template supports local development with a development server, and it provides a promisified version of google.script.run for cleaner code even allowing the easy mocking of server-side functions for realistic testing. The template also allows you to build scripts for different environments and even supports deploying libraries to NPM.
This is an incredibly impressive piece of work and Dmitry is encouraging contributions: “Your feedback, fresh ideas, and contributions are not just welcome — they’re what will make this tool even better. Let’s push the boundaries of what we can achieve with Google Apps Script together!”
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.
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.
I tried to see if an AI that’s good at writing could also make smart moves in a game. I chose Battleship and set it up in Google Sheets to play against Gemini, the AI. The result was mixed. On one hand, yes, Gemini could play the game. It followed the basic rules and even managed to sink some of my ships. This was a big deal, especially since it took me a ridiculous number of days of coding to get there, and I nearly gave up at one point.
Dmitry Kostyuk has shared a blog post detailing his experiment pitting the Gemini API against himself in a game of Battleship. As explained by Dmitry while Gemini could follow the rules and even sink some ships, it needed help to avoid basic mistakes, revealing that AI still has room to grow in the realm of strategic games.
Dmitry built the game in Google Sheets and the source code is linked from the post. To guide Gemini, Kostyuk crafted detailed prompts outlining the game’s mechanics and decision-making logic. However, he encountered challenges due to Gemini’s limitations in providing strategic responses. Despite these hurdles, the project yielded valuable insights into prompting techniques for AI decision-making.
I recently faced a frustrating issue when writing data to a CloudSQL database with the JDBC class in Apps Script. I kept getting the following error:
Exception: Argument too large: SQL
I also observed that it only happened when my SQL query reached a certain length. I considered breaking it down into multiple queries, but I was still puzzled 🤔 because I was only sending a few dozen kilobytes of data.
Now, the thing is, the official documentation could be more helpful; even though the solution is there, it needs to be better explained. So, I turned to StackOverflow. There was a discussion on this exact topic, but to my surprise, I was still waiting for an answer. Until, well, I wrote it 😉
Alright, folks, we’re talking about something quite hot off the press in the realm of Google Apps Script — “Smart Chips.” This feature is available within Google Docs and can build previews of pasted links using the Card Service. Think of it as a little preview window of what lies beyond the link — a sneak peek, if you will. 🕵️♂️
Editor: Smart chips are a recent feature in Google Workspace that help you quickly insert information into your Docs and Sheets. They can be used to insert people, places, dates, and more. It’s also possible for Google Workspace developers to publish their on ‘Preview links’ smart chips as Workspace Add-ons. In this post from Dmitry Kostyuk you can learn about publishing your own smart chips and some creative ways to get the data you need using Google Apps Script.
Mastering Google Apps Script: Deploy Once, Run Everywhere 🚀
What’s The Issue? 🤔
Building add-ons with Google Apps Script is akin to owning a magic wand for distributing your application. And if you’re like me, you’ve probably created an army of internal add-ons for clients and personal use, especially those sweet editor add-ons. But here’s the catch: every time you deploy your add-on, you need to specify the script ID and the deployment version for each context (Docs, Sheets, Slides, and Forms). Keeping up with 4 different files isn’t just tedious; it’s like trying to juggle flaming swords while on a unicycle 🙃. But don’t worry, there’s a better way!
Taking JavaScript to the Next Level with TypeScript for your Google Apps Script Projects
A Warm Welcome Back to the Series 🎉
Hey there, and welcome back to our hands-on series on mastering Google Apps Script UIs! Now, if you’re serious about JavaScript, it’s high time we chat about TypeScript. TypeScript is a superset of JavaScript that brings static typing to the game. It’s like JavaScript put on its best suit and turned into a more organized, reliable version of itself. 😎
The reason a lot of developers are switching to TypeScript is because it can catch errors at compile-time, making debugging less of a headache (it’s like having a personal assistant who checks your work for mistakes so you don’t look silly later). In this part, we’ll let the Emojibar project rest (it’s earned it, after all!), and we’ll switch over to a different repository I frequently use as a boilerplate for my projects. This boilerplate is a work in progress, so don’t be surprised if it changes faster than you change your socks. 😅
Streamlining Your Development Workflow with Multiple Deployment Environments 🚀
Kickoff: Marching Towards Deployment
Welcome back, dear coders! Our Emojibar is not just a fun prototype anymore — it’s a full-fledged tool ready to be unleashed into the wild. But before we let it run free, we need to get our house in order, or in our case, our environments. And no, I’m not talking about recycling, though you should be doing that too!
Professional development calls for setting up different environments — it’s a bit like having different outfits for different occasions. At the very least, you’ll want to have a development environment where you experiment and break things (yes, it’s encouraged!), a User Acceptance Testing (UAT) environment where your users can give your app a test drive, and a production environment, the red carpet where your app shines.
