Add-on vs Extension and latency considerations

[Niki Parmar]

Hi everyone,

I'm looking for some general advise on differences between accessing Google Apps Script via a built-in Sheets add-on vs building my own Chrome extension.

In the extension setting, the user request goes from the extension front-end to my API server. The API server then makes calls to Google AppsScript via the 'web app' option which makes POST calls to the Google Apps Script project.

In the add-on, I'm imagining the add-on front-end first making calls to my API server, getting a response back and then calling the Google AppsScript which gets executed on Google backend.

A few questions, any general advise or help here is greatly appreciated

1. Is there a preference from your experience between the add-on route vs extension?

2. For small latency, which model is better or are they basically the same?

3. For the extension, I want to deploy the Web App such that it uses the quota of the end user accessing my extension rather than my (developer) quota. I searched online and it seems like it is possible, but can someone verify this? I also can't share the apps script project with the user and would like to use a simple oauth mechanism to generate a token and send it when making the POST request.

4. How should I think about quota in general? Is there a total runtime per day or per hour against a script that applies?

5. What is the general reliability of using Apps Script to do things with Sheets? I'm thinking about availability, latency and consistency.

Thank you for your help in advance. Please let me know if anything needs further clarification.

[Clark Lind]

Just thinking as I type, I suppose the best method depends on your audience/user base. If they all have Google accounts, then keeping everything on the Google servers makes sense. If they are non-Google users, then the extension may be more appropriate. The main difference is, do you want your code running on the Google servers, or in the user's browser. Those seem to be the main implications I can think of. 

[Clay Smith]

1. Is there a preference from your experience between the add-on route vs extension?

This is a major design choice. 

Addon types https://developers.google.com/apps-script/add-ons/concepts/types

An add-on is intended to extend Google Applications. They are serversided and rely on the user’s google identity. The quota is also user related. There are a few types of add-ons. 

The editor Add-On is intended to run from the menu selector. It provides a 6 min runtime for non-business accounts and 30 min for business accounts. Check out to quota documentation for more info. 

https://developers.google.com/apps-script/guides/services/quotas

There are also workspace addons which use a card display framework for the front end and appear to the right in the application it’s related to. They are limited to 6min runtimes for each function call. 

You can also use alternative languages to create addons. This is not my area so I’ll bypass in hopes some one else addresses. 

Extensions are from the perspective of the browser and the rendered page. They can provide an injected UI, popup ui, or individual html page as a front end. They can also save settings through a user account or local storage. They are extremely flexible but may lead to a higher amount of upkeep if you are directly interacting with a page. Extensions are browser dependent and may require some acrobatics for various browsers. 

Basically, in my opinion, if you can’t do it with an add-on you try it with an extension and if not with an extension you build your own application.   

2. For small latency, which model is better or are they basically the same?

Addons will experience more or less latency based on various criteria. I’m my experience it depends on the time of day and what is being called and how frequently. 

Extensions are dependent on the external APIs. They run client side so are typically low latency. If you are calling an AppScript api there is a low quota so be sure you are in range on use. 

3. For the extension, I want to deploy the Web App such that it uses the quota of the end user accessing my extension rather than my (developer) quota. I searched online and it seems like it is possible, but can someone verify this? I also can't share the apps script project with the user and would like to use a simple oauth mechanism to generate a token and send it when making the POST request.

This is possible. I use this method for my paid subscribers of applications. I believe the AppScript is exposed. If you need to keep things private better to use cloud functions or an app engine. Quotas can be increased if there’s a realistic need for it. Be sure to implement exponential back off. I hit multiple billions of calls during COVID by not understanding this concept of retrying. Google short me down until I redesigned. Oops. 

4. How should I think about quota in general? Is there a total runtime per day or per hour against a script that applies?

It all depends on what you are using. Quota can be per Google Cloud Project, User, User per x time frame. Happy to think through this complexity of you need. I’ve had quite a bit of experience and find it interesting.

https://developers.google.com/apps-script/guides/services/quotas

5. What is the general reliability of using Apps Script to do things with Sheets? I'm thinking about availability, latency and consistency.

Well over 95% uptime with very few major issues. And if there are issues they are resolved on a few hours. Latency is depends to on what you are using and doing. AppScript is server side. There’s documentation on latency of various functions out there. Tanaike in this group I think has some good documentation. 

https://tanaikech.github.io/

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/d2552a74-e9e7-4428-9284-4a17bc08c6f8n%40googlegroups.com.

--