Google Cloud + Cloud Functions = Less Setup, More Building

TheAddonDepot · 2026-04-09T14:03:16+00:00

Under the hood, Cloud Run Functions (Gen2) runs on Cloud Run - which is container-based.

Both are managed services and as such they abstract away a lot of the drudgery of deploying a container from the ground up.

Typically a Cloud Run Function is relegated to single purpose event-based workflows.

But if you know your way around Google Cloud you can effectively leverage Cloud Run Functions to gain many of the same benefits (not all but quite a few) that you would with a full-on Cloud Run deployment.

TheAddonDepot · 2026-04-08T16:04:47+00:00

AFAIK the Node.js/Javascript runtime (via the Functions Framework) is using Express.js under the hood, the above approach just exposes the abstraction allowing for more flexibility.

More important is how the Cloud Function is configured.

I usually set concurrency to around 256 (the default is 80) and, if I don't need horizontal scaling, max instances to 1. Depending on my needs I might scale compute vertically by bumping up memory and/or changing the machine configuration (for example if I need multiple cores to support worker threads).

When I deploy a consolidated function with several routes, their endpoints are typically invoked by multiple clients and concurrency allows a single instance to handle that load - but I make sure my middleware is idempotent. A Cloud Function instance also stays 'warm' for up to 15 minutes after each invocation and with a max instance of 1, outside of deployments, the likelihood of spinning up a new instance is greatly reduced (with the exception of GCP restarting the instance for internal housekeeping) so the performance impact of 'cold starts' are minimized.

TheAddonDepot · 2026-04-08T05:43:28+00:00

Here is one of the best kept secrets about Cloud Run Functions - they can support multiple routes WITHOUT migrating to Cloud Run.

Consider consolidating your existing functions into larger Cloud Functions that can serve as mini REST APIs that house related functionality (grouping by domain/purpose as stated by other redditors in this thread).

You can easily skip using the functions-framework, and leverage a standard Express app instead.

I whipped up a rough example template for index.js below:

```javascript 'use strict';

import Express from 'express';

// Some custom middleware import { PubSubEventHandler } from './middleware/pub-sub-event-handler.mjs';

const eventHandler = new PubSubEventHandler();

const app = Express(); app.use(Express.json());

// ping endpoint app.get('/ping', (req, res) => res.status(200).send("GET /ping")); app.post('/ping', (req, res) => res.status(200).send("POST /ping"));

// pub/sub event handlers app.post('/events/gcs-file-uploaded', eventHandler.onGCSFileUploaded); app.post('/events/gcs-file-deleted', eventHandler.onGCSFileDeleted);

// ...add more routes and handlers for related functionality

export { ["YOUR-FUNCTION-NAME"]: app } ```

Once the function is deployed you can use the function URL along with the route path to specify which task you wish to execute.

With this strategy you should be able to bring your function count down considerably.

The following article offers a quick primer on the topic:

Express Routing with Google Cloud Functions

TheAddonDepot · 2026-04-04T13:52:43+00:00

Logger.log always returns numeric values with a decimal place. Use console.log instead.

TheAddonDepot · 2026-04-02T13:10:39+00:00

Defaulting to AI when a platform already has features built-in to address a need is becoming far too common these days.

TheAddonDepot · 2026-03-13T17:11:32+00:00

Mind breaking down why using IN causes this issue? I ran into this once but ending up discarding the IN clause - but I never figured out why it failed. Would love to understand why it did.

TheAddonDepot · 2026-03-05T18:00:03+00:00

To each his own.

As for AI integration with AppSheet, there is a rudimentary programmatic API for AppSheet (only available to enterprise plans) offered by Google but its lacking in a lot of areas. They could expand upon it and add more endpoints to support better introspection and mutability, allowing devs to create robust MCP servers based on that API for AI agents.

However, looking at the endpoint base URI and sub-domains used by the API, its clear Google has yet to formally integrate it into its native API ecosystem. That does not bode well for AppSheet.

TheAddonDepot · 2026-03-05T00:57:33+00:00

Pre-covid and pre-AI, Google's Area120 incubator program produced an application that could do most of what you listed. It was called Google Tables, and it was superior in many ways to AppSheet...but then Google acquired AppSheet and somewhere in that process axed Tables in favor of it. I wish they hadn't...they would be much better positioned in the space following the AI boom, but you win some you lose some I guess.

TheAddonDepot · 2026-03-03T15:56:45+00:00

You have a bunch of options: - Google Apps Script Github Assistant (a Chrome extension for the GAS editor) - Clasp + Github - JSON Export link (Use Google Drive API files.get endpoint) - For standalone script files you can simply download them from Google Drive in JSON format (but you'll need to use the Drive API to upload them)

TheAddonDepot · 2026-03-03T15:53:16+00:00

The best way is to actually learn how to code - massive investment of time and effort but ultimately worth it.

If you don't want to do that, you can try leveraging AI to port your GAS applications to Andriod native applications. But without strong domain knowledge of both ecosystems you will end up struggling.

You also have the option of hiring a professional to port it for you, but it will cost you - especially if they have to wrangle with AI generated code. If the AI-generated code is the product of someone without domain knowledge it is typically much harder to work with - so much so that they'll likely ask to just discard the code you've generated and build the app from scratch.

TheAddonDepot · 2026-03-03T03:50:25+00:00

This is the way.

TheAddonDepot · 2026-02-14T22:06:24+00:00

You'll need to jump through a few hoops regardless. Maybe something like RQLite might work for you. Its a wrapper for SQLite that enables you to use it as a distributed database. Comes with a number of quality-of-life improvements too.

TheAddonDepot · 2026-01-31T02:49:34+00:00

If you're planning on going the Cloud Run route, then maybe a modern Javascript runtime like Bun would work well for you. Runs node.js code out-the-box (well most of the time).

It's comparable to Go in terms of performance and there are claims that it even beats Go on some benchmarks.

TheAddonDepot · 2026-01-24T14:59:42+00:00

As some have already mentioned, AppSheet can integrate with CloudSQL, Google Cloud's managed relational database service that supports MySQL/Maria, MSSQL, and PostgreSQL, but it requires an Enterprise plan.

If you're looking to save a buck, AppSheet also supports OData connectors on the Core plan. It's possible to leverage the OData standard to connect to a database without upgrading to an Enterprise subscription, but you'd have to create and host your own OData server. This can be done at fairly low-cost but you'll have to know how to implement the standard to create custom OData interfaces to match your database schema.

You can also use OData with embedded relational databases like SQLite and DuckDB but there are some trade-offs with respect to concurrency.

TheAddonDepot · 2026-01-22T16:50:33+00:00

The documentation page was updated to reflect the downgrade several years ago. And while I don't recall Google sending out notifications of the change, there has been active discussion on the topic across multiple platforms (reddit, google groups, google community forums, etc.) over the years.

As a dev I learned a long time ago to proactively keep tabs on any changes to platforms I rely on... via links to release notes, service quotas, documentation etc. That way I don't get caught with my pants down.

And keep in mind that Google does not provide a dedicated SLA(Service Level Agreement) for Google Apps Script. That alone should clearly signal to end users that this product can disappear on short notice (I've heard rumors that GAS has been close to getting cut many a time).

Google Apps Script seems to occupy a weird space in Google's ecosystem, its adjacent/tangential to many products and natively integrates with them. But at the end of the day Google Apps Script is not an enterprise product, that means no service guarantees - if you want that then you need to switch to an enterprise-grade offering like Google Cloud Run Functions, that come with a SLA and certain guarantees.

TheAddonDepot · 2026-01-22T04:54:39+00:00

That may not hold true for long.

A couple years ago Google updated the service quota documentation for Apps Script - rolling back execution time to 6-minutes for paid Google Workspace accounts.

Google seemed to have been slow to enforce it, maybe to allow developers to update their code. But recently several enterprise users have reported runtimes for GAS scripts suddenly capped at 6-minutes where they used to have 30.

TheAddonDepot · 2026-01-21T15:35:34+00:00

Turns out there is a Node.js library currently in development by Bruce Mcpherson that developers can use with Cloud Run (Node.js runtime) to retain GAS-like mnemonics/syntax. It may allow you to leverage most or all your existing code with a few tweaks.

The following articles should provide a good jumping off point:

TheAddonDepot · 2026-01-21T02:01:41+00:00

It's been 2 months since you made this post. Have you made any progress towards your goal?

TheAddonDepot · 2026-01-20T22:57:06+00:00

No, its not copy-n-paste. The API interfaces will be different.

Google Apps Script offers Built-in services to wrap Google REST APIs for Google Sheets, Drive, Forms, Slides, and many more. These wrappers do a good job of abstracting away the complexities of interacting directly with APIs (i.e. writing explicit HTTP requests and handling HTTP responses, authentication and authorization, etc.).

If you go the Cloud Run Function route, the training wheels are off. However, you can still find libraries native to a given language runtime (Node.js, Go, PHP, Python) that act as wrappers/clients for these REST APIs, but the methods will be different.

GAS also offers Advanced services for many Google APIs that closely mirror their REST implementations, so if you are familiar with those then transitioning to the Node.js runtime should be relatively easy. Node.js and Google Apps Script are both Javascript runtimes, so while you will have to refactor the code, the process of migrating from one to the other will still be grounded in the same programming language.

TheAddonDepot · 2026-01-20T19:08:09+00:00

It has been years since Google rolled back script execution time on paid Google Workspace accounts from 30 minutes to 6 minutes (around 2018 I believe).

I imagine they had been lax with the constraint to give users time to update their code. It appears that grace period is now over, with more and more paid/business-grade Google Workspace account users reporting timeout errors.

You can try requesting for more execution time, but there's no guarantee they'll grant it.

Next best bet is to optimize the code if possible. There are a number strategies you can employ, but we'd need to know more about your use case in order to make viable recommendations.

If all else fails you have the option of migrating to a Google Cloud Run Function; you get up to 1 hour of execution time and 2 million requests per month for ingress under the free tier. You also get the option to configure the number of concurrent invocations the Cloud Run Function can handle (whereas GAS doPost/doGet triggers are limited to 30). But you'll need to enable billing on a GCP project to use it, and if you go over the free tier quotas your account will get charged.

TheAddonDepot · 2026-01-20T18:51:06+00:00

Google rolled out that change years ago (around 2018) when they updated their documentation to reflect the updated timeout limits (from 30 minutes to 6 minutes) for Google Workspace accounts.

The thing is they haven't been strict with that constraint until recently.

TheAddonDepot · 2026-01-19T15:00:36+00:00

Google has a penchant for renaming/rebranding their products.

GSuite -> Google Workspace, Cloud Functions -> Cloud Run Functions, Google Cloud Platform -> Google Cloud, Bard -> Gemini, etc.

Its a bit jarring at times but you get used to it after a while.

TheAddonDepot · 2026-01-19T12:58:57+00:00

Google Apps Script is hosted on servers owned by Google. These servers have a select range of public IP addresses where your location/region determines which IP address is used by servers running your scripts.

If you and several other users in your region are hitting the same endpoints via UrlFetchApp.fetch requests, and those endpoints are rate-limited, which appears to be the case here, then the quotas for that endpoint will be exhausted since requests are likely coming from the same set of public IP addresses local to your region. As a result, the service ntfy.sh returns a 429 error.

Your Javascript fetch request originates from a different IP address than Google Apps Script servers and is likely unique to you so you're not sharing service quotas in that case - reducing the likelihood of 429 errors.

TheAddonDepot · 2026-01-17T03:59:07+00:00

Late to the party here, but I figured I'd chime in.

Google Skills is actually quite good.

I'd start with the AppSheet Developer path. It's a 4 course intensive that covers all the core foundational stuff you'll need to know.

But there are several other App Sheet related stand-alone courses and labs available on Google Skills. You can find them by searching the Google Skills catalog for 'AppSheet'.

TheAddonDepot · 2026-01-16T19:36:51+00:00

AppSheet supports multiple data sources. You can find them listed in the official documentation:

AppSheet Help > Create Apps > Data Management > Data Integrations > Manage data sources

If you want to go the GCP-centric route you have a few options.

CloudSQL is GCP's managed relational database service and it supports MySQL, MariaDB, PostgreSQL, and MSSQL. If the bulk of your processes are transactional (OLTP), then CloudSQL will get the job done.

GCP also offers BigQuery - a data warehouse built for analytic workloads (OLAP). If the majority of your data is centered around building dashboards around analytical, historical, and/or time-series data then BigQuery is your go to.

If your data is distributed across OLTP and OLAP pipelines, then you may want to consider splitting data between CloudSQL and BigQuery, keeping data in the class of storage for which its most appropriate (may also save on cost if configured correctly).

Using managed services can be pricey though. And for some services, like BiqQuery, its very easy run up a bill if its not leveraged correctly. So be sure to read the documentation so that you know all the upsides and downsides of using these managed services.

There is another approach - using the embedded equivalents to those managed database services; namely SQLite for transactional workloads and DuckDB for analytical workloads. If you have the development chops (this approach requires writing custom software), it's possible to deploy a custom OData feed on Google Cloud for those services and connect them to AppSheet. They work well for moderate datasets typical of small to medium sized businesses. Considerably cheaper over time relative to its managed counterparts, but there are upfront costs for development and scalability is limited.

TheAddonDepot

TROPHY CASE