New: Remote fetch in Scripting App

[Taylor_Savage]

Happy February! We’re excited to announce that our new remoteFetchAsync function is now live within the Scripting App.

One of the most common issues we see users run into when writing scripts is in trying to use the fetch API to communicate with an external service. Because Scripting App scripts run directly in the user’s browser, fetch requests will be blocked by the browser if the target server doesn’t support Cross-Origin Resource Sharing (CORS).

The new remoteFetchAsync method transmits the request from Airtable’s own servers rather from the user’s browser, thereby getting around CORS issues. remoteFetchAsync works very similarly to fetch and expects the same inputs, except for a handful of “gotchas” stemming from the fact that this is run from a backend.

Resources to get started:

1. Read documentation: Learn about the functionality of remoteFetchAsync here.
2. Share your script template with Airtable customers: Already built a script that utilizes backend fetch? Submit here to get it listed in the Airtable marketplace.

Let us know if you have any questions or feedback in the comments below!

[Bill_French]

Taylor_Savage:

questions

One - are there any remote fetch limits or quotas?

[SergioCodes]

Thanks !!! :clap: :tada:

I really appreciate this upgrade;

I had to use proxies tons of times, and this change would save my clients and me a lot of time.

In the past, my clients were forced to set up AWS | pipedream | Heroku accounts just for using the scripting app (it didn´t make sense for a non-technical user).

Also, I was planning to submit some scripts, but some of them required a proxy; now, they don´t.

Opportunity: Avoid the restriction of FormData (this is also restricted in automation scripts).

[Bill_French]

Taylor_Savage:

except for a handful of “gotchas”

The follow redirect mode is not supported. Only error and manual are supported. As manual returns an ‘opaque’ response in order to respect atomic HTTP redirect handling, it’s effectively impossible to follow redirects at present.

Sorry, second question - doesn’t this rule out using remote fetch with the entirety of Google APIs since redirection is a fundamental security aspect of Google Cloud Platform and many other API platforms?

[Jonathan_Gaunt]

@Taylor_Savage can you point me in the right direction? If I used this code in an automation block, how would I rewrite it to use in an app scripting block? Thanks

let response = await fetch(‘https://api.companieshouse.gov.uk/company/’ + {COMPANY_NUMBER}, {
method: ‘GET’,
headers: {
‘Authorization’ : {API_KEY},
‘Content-Type’: ‘application/json’,
},
});
console.log(await response.json());

[Ben_Razon]

Hey @Jonathan_Gaunt ,
If api.companieshouse.gov.uk/company/ supports CORS, you can keep using your code snippet as is. If it doesn’t, I would try replacing fetch with remoteFetchAsync. They take the same arguments, so you shouldn’t need to make any other changes.

[Taylor_Savage]

By redirects, are you referring to OAuth redirects?

The scripting app isn’t really designed to be able to Auth into secured API’s this way (with no secure place to store things like tokens). This feature is more directly for at least being able to access open endpoints that don’t support CORS.

We are separately considering additional under-the-hood features that would allow a user to separately auth into 3P services, and then let things like the scripting app make requests that take advantage of those stored credentials (without providing direct access to the keys themselves).

[Bill_French]

Taylor_Savage:

By redirects, are you referring to OAuth redirects?

No. As per the gotcha’s…

The follow redirect mode is not supported.

[Taylor_Savage]

Yes it’s correct, follow redirect is not currently supported.

Do you have an example of a Google API that requires redirect that’s not an OAuth redirect? For example, the following code works (and doesn’t actually require remote fetch):

const API_KEY = "$MY_GOOGLE_API_KEY";
const GEOCODE_BASE_URL = "https://maps.googleapis.com/maps/api/geocode/json";

const address = '1600 Pennsylvania Avenue NW Washington, D.C. 20500'

const results = await remoteFetchAsync(GEOCODE_BASE_URL+`?address=${address}&key=${API_KEY}`)

const data = await results.json()

console.log(data);

[Bill_French]

Taylor_Savage:

Do you have an example of a Google API that requires redirect that’s not an OAuth redirect?

Sure. This.

What you’ve referenced is a specific Google Maps API that may (or may not) be used with oAuth.

Imagine, however, you wanted to create a webhook service in Google Apps Script using doPost() or doGet(). The resulting endpoint could be easily called by fetch, except that without followRedirects set to true, it won’t work because this is the only behavior Google Cloud Platform supports.

When testing HTTP requests in Google Script with utilities like CURL or Postman, ensure that that “Automatically follow redirects Follow HTTP 3xx responses as redirects” setting is turned on since the ContentService serves a 301 redirect from the script.googleusercontent.com domain. – https://www.labnol.org/code/19871-get-post-requests-google-script

I’m simply making the observation that while a CORS remedy is certainly ideal; it is not useful in a variety of platforms that seem to employ this technique for added security.

UPDATE: BTW, @Taylor_Savage - there are two other very recent threads related to this issue here and here that are worth reading.

[Taylor_Savage]

Got it, really interesting, thank you.

Playing a bit of catch-up here - it looks to me like these examples are using Google Apps Script to do some additional scripting-style work outside of the constraints of the Airtable Scripting App itself. Very curious - why specifically Google Apps Scripts? Is it that it’s the simplest environment to write script-style code that’s a) accessible via a public URL endpoint and b) has a lot of flexibility in terms of what you can actually do within the environment? Or that it can easily interface with other Google products? Or something else?