AppsScriptPulse

Solutions, AI, Advanced

Mastering Workspace API Authentication in ADK Agents with a Reusable Pattern

Tags:
| | 0 Comments |

For developers seasoned in the Google Workspace ecosystem, the promise of agentic AI is not just about automating tasks, but about creating intelligent, nuanced interactions with the services we know so well. Google’s Agent Development Kit (ADK) provides the foundation, but integrating the familiar, user-centric OAuth 2.0 flow into this new world requires a deliberate architectural approach.

This article explores the patterns for building a sophisticated, multi-capability agent. It explores why you might choose a custom tool implementation (ADK’s “Journey 2”) over auto-generation, and presents a reusable authentication pattern that you can apply to any Workspace API.

The full source code for this project is available in the companion GitHub repository. It’s designed as a high-fidelity local workbench, perfect for development, debugging, and rapid iteration.

The Architectural Crossroads: Journey 1 vs. Journey 2

When integrating a REST API with the ADK, you face a choice, as detailed in the official ADK authentication documentation:

  • Journey 1: The “Auto-Toolify” Approach. This involves using components like OpenAPIToolset or the pre-built GoogleApiToolSet sets. You provide an API specification, and the ADK instantly generates tools for the entire API surface. This is incredibly fast for prototyping but can lead to an agent that is “noisy” (has too many tools and scopes) and lacks the robustness to handle API-specific complexities like pagination.
  • Journey 2: The “Crafted Tool” Approach. This involves using FunctionTool to wrap your own Python functions. This is the path taken in this project. It requires more initial effort but yields a far superior agent for several reasons:
    • Control: This approach exposes only the high-level capabilities needed (e.g., search_all_chat_spaces), not every raw API endpoint.
    • Robustness: Logic can be built directly into the tools to handle real-world challenges like pagination, abstracting this complexity away from the LLM.
    • Efficiency: The tool can pre-process data from the API, returning a concise summary to the LLM and preserving its valuable context window.

Journey 2 was chosen because the goal is not just to call an API, but to provide the agent with a reliable, intelligent capability.

The Core Implementation: A Reusable Pattern

The cornerstone of this integration is a single, centralised function: get_credentials. This function lives in agent.py and is called by every tool that needs to access a protected resource.

It elegantly manages the entire lifecycle of an OAuth token within the ADK session by following a clear, four-step process:

  1. Check Cache: It first looks in the session state (tool_context.state) for a valid, cached token.
  2. Refresh: If a token exists but is expired, it uses the refresh token to get a new one and updates the cache.
  3. Check for Auth Response: If no token is found, it checks if the user has just completed the OAuth consent flow using tool_context.get_auth_response().
  4. Request Credentials: If all else fails, it formally requests credentials via tool_context.request_credential(), which signals the ADK runtime to pause and trigger the interactive user flow.

This pattern is completely generic. You can see in the agent.py file how, by simply changing the SCOPES constant, you could reuse this exact function for Google Drive, Calendar, Sheets, or any other Workspace API.

Defining the Agent and Tools

With the authentication pattern defined, building the agent becomes a matter of composition. The agent.py file also defines the “Orchestrator/Worker” structure—a best practice that uses a fast, cheap model (gemini-2.5-flash) for routing and a more powerful, specialised model (gemini-2.5-pro) for analysis.

The Other Half: The Client-Side Auth Flow

The get_credentials function is only half the story. When it calls tool_context.request_credential(), it signals to the runtime that it needs user authentication. The cli.py script acts as that runtime, or “Agent Client.”

The cli.py script is responsible for the user-facing interaction. As you can see in the handle_agent_run function within cli.py, the script’s main loop does two key things:

  1. It iterates through agent events and uses a helper to check for the specific adk_request_credential function call.
  2. When it detects this request, it pauses, prints the authorisation URL for the user, and waits to receive the callback URL.
  3. It then bundles this callback URL into a FunctionResponse and sends it back to the agent, which can then resume the tool call, this time successfully.

This client-side loop is the essential counterpart to the get_credentials pattern.

Production Considerations: Moving Beyond the Workbench

This entire setup is designed as a high-fidelity local workbench. Before moving to a production environment, several changes are necessary:

  • Persistent Sessions: The InMemorySessionService is ephemeral. For production, you must switch to a persistent service like DatabaseSessionService (backed by a database like PostgreSQL) or VertexAiSessionService. This is critical for remembering conversation history and, most importantly, for securely storing the user’s OAuth tokens.
  • Secure Credential Storage: While caching tokens in the session state is acceptable for local testing, production systems should encrypt the token data in the database or use a dedicated secret manager.
  • Runtime Environment: The cli.py would be replaced by a web server framework (like FastAPI or Flask) if you are deploying this as a web application, or adapted to the specific requirements of a platform like Vertex AI Agent Engine.

By building with this modular, Journey 2 approach, you create agents that are not only more capable and robust but are also well-architected for the transition from local development to a production-grade deployment.

Explore the Code

Explore the full source code in the GitHub repository to see these concepts in action. The README.md file provides all the necessary steps to get the agent up and running on your local machine. By combining the conceptual overview in this article with the hands-on code, you’ll be well-equipped to build your own robust, production-ready agents with the Google ADK.

Source: GitHub – mhawksey/ADK-Workspace-User-oAuth-Example

Solutions, Advanced

Customising the Gemini CLI with Extensions: A gas-fakes Case Study

Tags:
| | 0 Comments |

The Gemini CLI is a powerful tool for developers, but its true potential lies in its extensibility. I’m excited to share a project that showcases this flexibility: the gas-fakes Gemini CLI Extension. This extension is a case study in tailoring the Gemini CLI to your specific needs, particularly when it comes to secure software development in Google Apps Script.

At its core, this project addresses a critical security concern in the age of AI-driven development: how can you safely test and execute AI-generated code that requires broad access to your Google Workspace data? The answer lies in the pioneering work of Bruce Mcpherson on his gas-fakes library, which this extension integrates into a seamless and secure workflow, thanks to the invaluable contributions of Kanshi Tanaike. I’m looking forward to discussing this project in more detail with Bruce at the upcoming Google Workspace Developer Summit in Paris.

The Power of Gemini CLI Extensions

The ability to create extensions for the Gemini CLI opens up a world of possibilities for developers. By packaging together a collection of tools and resources, you can create a customised experience that is perfectly suited to your workflow. An extension can include three key components:

  • System Prompts (GEMINI.md): A GEMINI.md file allows you to provide the model with custom instructions and context, guiding its behaviour to ensure it generates code that aligns with your specific requirements.
  • Custom Commands: You can create custom commands to automate common tasks and streamline your development process.
  • MCP Tools: The Model Context Protocol (MCP) allows you to integrate external tools and services with the Gemini CLI, enabling powerful, interactive experiences.

The gas-fakes Extension: A Case Study in Secure Development

The gas-fakes Gemini CLI Extension is a practical example of how these components can be combined to create a powerful and secure development environment for Google Apps Script.

The extension tackles the challenge of safely executing AI-generated code by creating a sandboxed environment where scripts can be tested without granting them access to your Google account. Here’s how it works:

  • GEMINI.md: The GEMINI.md file provides the model with detailed instructions on how to use the gas-fakes library, ensuring that the generated code is compatible with the sandboxed environment.
  • Custom Commands: The extension includes custom commands like /gas:init and /gas:new that automate the process of setting up a new project and generating code.
  • MCP Tool: The packaged MCP tool allows the Gemini CLI to interact with the gas-fakes sandbox, enabling it to execute code and receive feedback in a secure environment. This extension also includes the new official Model Context Protocol (MCP) for Google Workspace Development to interact directly with Google Workspace APIs.

Getting Started

To get started with the gas-fakes extension, you’ll first need to have the Google Gemini CLI installed. Once that’s set up, you can install the extension with the following command:

gemini extensions install https://github.com/mhawksey/gas-fakes-ext

For more information on managing extensions, including uninstallation and updates, please see the official documentation.

Usage

Once the extension is installed, you can start a new sandboxed Apps Script project directly from your terminal.

First, create a new directory for your project, navigate into it, and start the Gemini CLI. From there, you can use the /gas:init command to scaffold a complete project structure, which includes all the necessary files for local development and testing.

With the project initialised, you can then use the /gas:new command to generate code from a natural language prompt. For example:

/gas:new "create a new Google Doc and write 'Hello, World!' to it"

This command generates the Apps Script code in src/Code.js and a corresponding runner script in run.js. From here, you can continue the conversation with the Gemini CLI to refine and build upon your code, testing each iteration locally in the secure, sandboxed environment.

This project structure is deliberate: the run.js file is your sandbox for testing, while the src folder contains the clean, production-ready Apps Script code. This separation makes it easy to use other command-line tools like clasp to push only the code in the /src directory to your online Apps Script project when you are ready to deploy.

Fine-Grained Security with Conversational Controls

Beyond creating new files, a common requirement is to have a script interact with existing documents in a user’s Google Drive. The gas-fakes extension provides a robust solution for this, and because it’s integrated into the Gemini CLI, you can configure these advanced security settings using natural language.

This conversational control is powered by the extension’s MCP tool, run-gas-fakes-test. When you ask Gemini to “whitelist this Google Doc for read access”, the model doesn’t write the configuration code itself. Instead, it calls this tool, translating your request into a set of structured parameters that the tool understands. The MCP tool then dynamically assembles and executes the run.js script with the precise security settings you requested. This abstraction is what makes the natural language interface so powerful.

For example, instead of requesting broad access to all of a user’s files, you can create a specific whitelist of file IDs that your script is allowed to interact with, specifying read-only or write access on a per-file basis. This granular approach ensures your script only ever touches the files it is supposed to.

For even tighter security, you can ask Gemini to:

  • Disable entire services: If your script only needs to work with Sheets, you can completely disable DriveApp and DocumentApp.
  • Whitelist specific methods: Lock down a service to only allow certain actions, for example, permitting DriveApp.getFiles() but blocking DriveApp.createFile().
  • Manage test artefacts: For debugging, you can disable the automatic cleanup feature to inspect any files created during a test run.

These advanced features provide developers with the confidence to build and test powerful automations, knowing that the execution is contained within a secure, predictable environment.

Conclusion

The Gemini CLI is more than just a command-line interface; it’s a powerful platform for creating customised and intelligent experiences. The gas-fakes Gemini CLI Extension is just one example of what is possible. I encourage you to explore the world of Gemini CLI Extensions and see what you can create.

Acknowledgements

This extension stands on the shoulders of giants. It directly builds upon the pioneering work of Bruce Mcpherson and his gas-fakes library. I’d also like to express my sincere gratitude to Kanshi Tanaike, whose work on the gas-fakes sandbox and MCP server has been instrumental in the development of this extension.

Source: GitHub – mhawksey/gas-fakes-ext

Community News, Library, Solutions, V8, Advanced

Apps Script Engine v2.0 is Here! Your Workflow Just Got a TypeScript Power-Up 🚀

Tags:
| | 0 Comments |

 

You heard it right. This is the update you’ve been waiting for. Apps Script Engine now has full-blown TypeScript support! 🤯

We’re talking server-side .gs files and client-side HtmlService code. The whole shebang. While clasp has been on-again, off-again with its TypeScript support, we decided to go all in and deliver the robust, seamless experience you deserve.

Getting started is ridiculously simple. Just tack on the --ts flag during installation:

npx apps-script-engine [directory] --ts

Why TypeScript is a Game-Changer for Apps Script

For larger or more complex Apps Script projects, the introduction of TypeScript offers substantial benefits that can improve code quality and developer productivity:

  • Static Typing: Helps catch common errors during development rather than at runtime, preventing entire classes of bugs related to data types.
  • Enhanced Autocompletion: Provides intelligent code suggestions and autocompletion in the IDE, speeding up the development process.
  • Improved Code Readability: Makes code easier to understand and maintain, as types explicitly define the data structures being used.

What’s New in Version 2.0?

This release is packed with features that modernise the Apps Script development experience:

  • Full TypeScript Support: Write modern, type-safe JavaScript for both frontend and backend code.
  • ES6+ Modules: Organise your code into clean, reusable modules.
  • Frontend Frameworks: Comes with out-of-the-box support for Alpine.js and Tailwind CSS (including Daisy UI).
  • NPM Modules: Leverage the vast ecosystem of NPM modules in your server-side and client-side code.
  • Robust Mocking: The mocking system for google.script.run has been re-engineered to allow for easy simulation of both success and failure handlers during local development.
  • Migration to Vitest: The testing framework has been switched from Jest to Vitest, offering faster performance and a simpler configuration.
  • Gemini CLI Integration: A new GEMINI.md file is included in the project template, providing the Gemini CLI with the necessary context to assist with coding and debugging tasks.
  • CI/CD and Environment Management: The engine includes built-in support for GitHub Actions workflows and managing multiple deployment environments (DEV, UAT, PROD).

This update positions Apps Script Engine as a powerful tool for developers who want to apply modern web development practices to the Google Workspace platform.

Source: Apps Script Engine v2.0 is Here! Your Workflow Just Got a TypeScript Power-Up 🚀

Solutions

Handling Granular OAuth Consent in Editor Add-ons with a Ready-Made Solution from Dave Abouav

Tags:
| | 0 Comments |

Image credit: Dave Abouav

A collection of helpful functions for Apps Script powered scripts, Add-ons and Chat Apps for checking if all of a script’s OAuth scopes (as listed in the project’s manifest file) have been authorized/granted by the end-user, and if not, then to prompt the user to re-authorize.

As we’ve covered previously, Google continues to roll out granular OAuth consent for published Editor Add-ons. This change gives users more control but requires developers to adapt their code to prevent a broken experience for new users.

While Google has provided new Apps Script methods for developers, distinguished Google Workspace Developer Dave Abouav has gone a step further by creating a simple, drop-in solution to help developers address this change quickly.

The Challenge: Handling Partial Permissions

With the new consent screen, users can grant only a subset of the OAuth scopes your add-on requests. If a new user deselects a scope that is essential for a particular feature, your add-on could fail, leaving the user without a clear path forward.

A Simple, Ready-Made Solution

Dave’s solution addresses this by providing a function that checks for incomplete authorization. When the function is triggered and finds that necessary permissions are missing, it automatically displays a user-friendly dialog. This prompt explains the situation and provides a direct link for the user to grant the required access.

The implementation is straightforward. After adding the granularAuth.gs file to your project, you’ll need to configure two constants at the top of the file:

  1. Set AUTH_APP_NAME to your add-on’s name to ensure the re-authorization prompt is correctly branded.
  2. Crucially, update the ADD_ON_CONTAINERS array to list only the host applications your add-on is designed for. This prevents your add-on from requesting unnecessary permissions (e.g., asking for Google Docs access when it’s a Sheets-only add-on).
// Set your Add-on's name here.
const AUTH_APP_NAME = 'My Awesome Add-on';

// To avoid requesting unnecessary scopes, list ONLY the hosts this add-on is for.
// For a Sheets-only add-on, for example, you would use:
const ADD_ON_CONTAINERS = [SpreadsheetApp];

Once configured, you can call the main function at the entry points of your add-on, such as from a menu item:

function menuItemStartAction() {
  if (authHandleMissingScopeGrants()) {
    // The prompt has been shown, so abort normal execution.
    return;
  }

 // Continue with normal execution
 handleStartAction();
}

This simple check ensures your add-on has the permissions it needs to run, and if not, it provides the user with an immediate path to resolution. Crucially, deploying this update doesn’t trigger the need for a new review from the OAuth or Marketplace teams.

It’s worth noting that this solution is specifically designed for Editor Add-ons (Forms, Sheets, Docs, and Slides). Adapting it for Workspace Add-ons would require modifications to use the Card Service for the user interface.

A big thank you to Dave Abouav for creating and sharing this valuable resource with the community! You can find the complete code, setup instructions, and more details on his GitHub repository.

Source: Dave Abouav’s granularOAuth GitHub Repository

Library, Solutions, AppSheet, Intermediate

New Feature for the AppSheetApp Library: Run API Calls in Parallel

Tags:
| | 0 Comments |

A Google Apps Script wrapper for the Google AppSheet API – bienlim/AppSheetApp

Recently I had a nice ping into my LinkedIn feed from App Developer Bien Lim. Bien has enhanced my original AppSheetApp library for Apps Script with a powerful new feature: fetchAll(). This addition lets you run multiple AppSheet API calls at the same time, significantly boosting the performance of your Apps Script integrations.

Building on the library’s existing methods like Add, Delete, Edit, and Find, this new function allows developers to execute these calls in parallel. This can drastically reduce execution time, which is a big improvement for applications that rely on multiple API operations.

You can find the updated library on the code repository to start using this new feature today.

Example Code

Here is a snippet showing how you can use the new fetchAll() method:

/**
 * Executes multiple AppSheet API requests in parallel.
 * This example shows how to perform Add, Delete, Edit, and Find operations simultaneously.
 */
function parallelRequest(){
  // Replace with your actual App ID and Access Key
  const AppSheet = new AppSheetApp('YOUR_APP_ID', 'YOUR_ACCESS_KEY');

  // Placeholder data for demonstration
  const properties = { "Locale": "en-US" };

  // Sample data for adding a new record. The key field is usually omitted if it's auto-generated.
  const dataToAdd = [{"Name": "John Doe", "Age": 30}];

  // Sample data for editing an existing record. The key field is required to identify the row.
  const dataToEdit = [{"ID": "unique-id-123", "Age": 31}];

  // Sample data for deleting an existing record. The key field is required.
  const dataToDelete = [{"ID": "unique-id-456"}];

  // The FetchAll method takes multiple API calls as arguments.
  // The 'true' argument tells each method to return a parameter object instead of
  // making an immediate API call. These parameter objects are then passed to fetchAll().
  const responses = AppSheet.fetchAll(
    AppSheet.Add('People', dataToAdd, properties, true),
    AppSheet.Delete('People', dataToDelete, properties, true),
    AppSheet.Edit('People', dataToEdit, properties, true),
    AppSheet.Find('People', [], properties, true)
  );

  // The responses are returned in an array, in the same order as the requests.
  const [ respFromAdd, respFromDelete, respFromEdit, respFromFind ] = responses;

  // You can now handle each response individually
  console.log('Add Response:', respFromAdd);
  console.log('Delete Response:', respFromDelete);
  console.log('Edit Response:', respFromEdit);
  console.log('Find Response:', respFromFind);
}

Source: GitHub – bienlim/AppSheetApp: A Google Apps Script wrapper for the Google AppSheet API

Library, Solutions, Advanced

Unlocking Google’s Full API Universe and Authentication Flows in Google Apps Script

Tags:
| | 0 Comments |

A Google Apps Script project that dynamically generates modern, feature-rich client libraries for any public Google API directly from the Google API Discovery Service.

For many developers, Google Apps Script is the go-to platform for rapidly automating and extending Google Workspace. Its simplicity and deep integration are powerful. But as projects grow in ambition, developers often encounter two significant walls: needing to connect to a Google API that isn’t built-in, or requiring an authentication flow, like a service account, that the standard services don’t support.

What if you could break through those walls? What if you could use a robust client library for almost any Google API—from Firebase to Cloud Billing—in seconds, right from Apps Script itself?

Today, I’m excited to introduce the Google API Client Library Generator for Apps Script, a project and code repository designed to solve these very challenges. It comes with a full suite of pre-built libraries, enabling you to significantly expand what’s possible on the platform.

Why This Matters: Beyond the Built-in Services

While Apps Script’s built-in and advanced services are excellent, they represent just a fraction of Google’s vast API ecosystem. This collection of generated libraries unlocks the rest, offering two critical advantages:

  1. Complete API Coverage: The generator uses the Google APIs Discovery Service to create clients for over 400 APIs. If it’s in the Google Discovery Service then there is a library for it in the repository.
  2. Flexible Authentication Flows: Generated libraries are not tied to the standard user-permission model. This means you can use service accounts for server-to-server authentication, or implement other OAuth2 flows as needed.

Getting Started

Getting started is as simple as finding the library you need in the build/ directory of the GitHub repository and copying the code into your Apps Script project. For detailed setup instructions and other authentication options, please refer to the main README.md in the repository.

Unlocking Professional Workflows with Service Accounts

The real power of this approach comes from flexible authentication. For Google Workspace developers, this also unlocks the ability to use service accounts with domain-wide delegation to make API calls on behalf of other users in your domain.

To handle the authentication flow, you’ll need an OAuth2 library. The following example uses the OAuth2 for Apps Script library, but other options are also available. Once you have your chosen library set up, you can use the following pattern:

// The email of the user to impersonate (for domain-wide delegation).
const USER_EMAIL = '[email protected]'; 

function getService_() {
  // Credentials from the service account's JSON key file.
  const serviceAccountCreds = {
    "private_key": "-----BEGIN PRIVATE KEY-----\n...",
    "client_email": "[email protected]",
  };

  // Use a unique name for the service, like 'Drive' or 'BigQuery', to avoid
  // token collisions between different services.
  return OAuth2.createService('Drive:' + USER_EMAIL)
      .setTokenUrl('https://oauth2.googleapis.com/token')
      .setPrivateKey(serviceAccountCreds.private_key)
      .setIssuer(serviceAccountCreds.client_email)
      .setSubject(USER_EMAIL)
      .setCache(CacheService.getUserCache())
      .setScope('https://www.googleapis.com/auth/drive');
}

/**
 * Lists files using the configured service account.
 */
function listFilesWithServiceAccount() {
  const service = getService_();
  if (!service.hasAccess()) {
    console.log('Service Account authentication failed: ' + service.getLastError());
    return;
  }
  
  const token = service.getAccessToken();

  // This is where the generated library is used with the custom token.
  const drive = new Drive({
    token: token 
  });

  const files = drive.files.list({
    supportsAllDrives: true,
    pageSize: 10
  });
  
  console.log('Files found via service account:', JSON.stringify(files, null, 2));
}

Under the Bonnet: The Generator

For those who want to tweak the generation logic or integrate it into their own workflows, the generator itself is included in the repository. It’s a self-contained Apps Script project that fetches API metadata and programmatically constructs modern, robust ES6 classes with features like automatic exponential backoff for handling API errors.

Join the Community and Contribute

This project was heavily inspired by the work of Spencer Easton and aims to build upon that foundation. It’s a community effort.

While libraries for all APIs are generated, not all have been extensively tested. If you use a library and find a bug, or have an idea for an improvement, please open a GitHub Issue. Pull requests are, of course, always welcome. Happy scripting!

Source: GitHub – mhawksey/Google-API-Client-Library-Generator-for-Apps-Script

Solutions, AI, Docs, Gmail, Sheets, Intermediate

An AI Assistant to Triage Your Inbox and Draft Replies with Apps Script and the Gemini API

Tags:
| | 0 Comments |

Image credit: Zack Akil

🤖 AI-powered Gmail assistant that automatically analyzes emails and drafts responses using Google’s Gemini AI

Google is rapidly integrating Gemini across the Workspace platform, bringing powerful AI features directly into the tools we use every day. While these native integrations offer incredible value, developer-led solutions provide a tantalising glimpse into the future of hyper-personalised automation, especially as we look toward the potential of the new Google Workspace Flows. This is where the real magic begins, allowing for custom agents that can handle complex, multi-step tasks.

Google Developer Advocate Zack Akil has created one such example solution that turns your Gmail inbox into a smart, automated assistant. His open-source project, the “AI-got-this-gmail-delegator,” is a Google Apps Script that uses the Gemini API to analyse incoming emails, categorise them, and even draft replies based on your own knowledge and writing style.

This project is a great example of how to combine the power of Google Workspace automation with the intelligence of modern AI. The script works by:

  • Analysing Incoming Emails: When a new email arrives, the script sends the content to the Gemini API for analysis.
  • Providing Context: The AI’s analysis is guided by a “knowledge base” that you provide in a Google Doc. This could include your role, common responses, or specific project details.
  • Intelligent Triage: Based on the email’s content and your knowledge base, the script decides whether the email needs a reply, requires manual intervention, or can be archived.
  • Drafting Replies: For emails that need a response, the script uses Gemini to generate a draft reply in your own writing style, ready for you to review and send.

The entire process is logged in a Google Sheet, giving you a complete overview of your AI assistant’s activity.

What makes this project so compelling is its practicality and customisability. By modifying the Google Doc knowledge base and the writing style prompts, you can create a personalised email assistant that understands the nuances of your work.

To explore the code and set up your own AI email delegator, check out the project on GitHub.

Source: GitHub – ZackAkil/AI-got-this-gmail-delegator 

Solutions, Web App, Advanced

Bridging the Gap: A Framework for Securely Embedding Apps Script Web Apps on Custom Domains

Tags:
| | 0 Comments |

This framework integrates Google Apps Script web apps into a standard website

Integrating a Google Apps Script web app into a public website offers powerful possibilities, but developers can often hit a wall of limitations. Serving from a custom domain, managing multiple Google account logins, preventing security vulnerabilities like clickjacking, and providing a smooth user experience are significant hurdles.

A new open-source framework from developer Zig Mandel provides a comprehensive solution, offering a flexible framework for embedding Apps Script web apps securely and professionally. At its core, the framework uses a parent website to host the Apps Script in an iframe, using a secure postMessage protocol for communication between the parent website and your web app. A key innovation is its ability to dynamically and securely load different script deployments using a cryptographic signature (org/sig) system, preventing unauthorised use while enabling advanced features like centralised logging and analytics integration.

What This Framework Solves

This solution is more than just an iframe wrapper; it’s a complete integration kit designed to enhance your Apps Script web app to a professional standard. It addresses several key pain points:

  • Custom Domain Serving: Serve your app from your own domain, not the standard script.google.com URL.
  • Secure Embedding: A communication protocol and domain validation prevent your app from being embedded on unauthorized sites.
  • Multi-Account & Workspace Compatibility: The framework is built to handle complexities that arise when users are logged into multiple Google accounts or are using a Google Workspace account.
  • Seamless User Experience: The architecture eliminates the jarring “flash” of a new page loading within the iframe, creating a smooth transition for single-page application (MPA) style web apps.
  • Analytics & Logging Integration: Send events from your Apps Script directly to the parent website’s Google Tag Manager instance and forward client-side logs to a centralized location like Google Cloud Logging.

Summary

In short, this framework hopefully unlocks a better way to implement public-facing Google Apps Script for web applications. For developers it provides the tools to overcome common embedding hurdles, moving beyond simple scripts to create secure, professional, and seamlessly integrated user experiences. To explore the code and get started on your own integration, check out the repository on GitHub.

Source: GitHub – zmandel/demosite_appscript

Library, Snippet, Solutions, V8, Advanced

Kickstart Your Apps Script Projects with the Pinnacle of My Development — The Apps Script Engine

Tags:
| | 0 Comments |

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:

  1. Seamless ES6 Modules Integration: Finally, you can use this missing JavaScript feature with Apps Script.
  2. Blazing Fast Local Development: Mock functions and promisified google.script.run calls make local development a breeze.
  3. Front-End Framework Support: Includes Alpine.js and Tailwind CSS out of the box, with easy TypeScript integration.
  4. NPM Module Support: Integrate NPM modules into front-end and back-end code effortlessly.
  5. Automated Testing: Set up with Jest, so you can ensure your code works as expected.
  6. CI/CD Integration: Easy integration with tools like GitHub Actions and Cloud Build ensures smooth, automated deployments.
  7. 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!”

Source: Kickstart Your Apps Script Projects with the Pinnacle of My Development — The Apps Script Engine

Solutions, AI, Docs, Intermediate

Build a Google Drive Add-on with Gemini to rename Untitled Google Docs – Name with Intelligence

Tags:
| | 0 Comments |

Google Workspace Add-on for Google Drive, which uses AI to recommend new names for the selected Doc in Google Drive by passing the body of the document within the AI prompt for context.

Tired of staring at “Untitled document” in Google Drive? At Google Cloud Next ’24 and I/O 2024, the Google Workspace DevRel team showcased new Apps Script samples utilizing the Gemini API for AI-powered functionality.

One such sample, “Name with Intelligence” by Charles Maxson, helps developers overcome this common hurdle. This Google Drive add-on leverages the Gemini API to suggest relevant titles for your documents, saving you valuable time and effort.

This innovative Google Drive add-on tackles the common struggle of naming untitled documents. It utilizes the Gemini API to analyse the content of your Google Doc and suggest relevant titles based on its understanding of the text. This not only saves you time brainstorming titles, but also ensures your documents are clearly named for easy searchability later.

Want to see it in action? Check out this clip from Charles’ TU5.8 – Apps Script and Gemini Next ’24 Redux presentation.

Ready to give “Name with Intelligence” a try?

Head over to the GitHub repository to explore the source code.

For those interested in my GeminiApp library, you can also find the sample here.

Take Your Development Further

This is just a glimpse of what’s possible with the Gemini API and Apps Script. With a little creativity, you can develop your own AI-powered Google Workspace add-ons to streamline your workflows and boost your productivity.

I encourage you to experiment and create innovative solutions that enhance your Google Workspace experience!

Source: apps-script-samples/ai/drive-rename/README.md at main · googleworkspace/apps-script-samples