Soon You'll Need a CDN

[Bill_French]

One of the best features of Airtable is the ability to drag images, files, and even videos (i.e., digital artefacts) right into an attachment field. When you do this, Airtable makes a copy of your image and stores metadata about the image into your base. It also quietly moves the copy of your image to its content delivery network (CDN). The URL to your image has been openly accessible providing a wonderful way to share access to your assets For almost eight years, this has been possible but that’s going to change in significant ways later this fall.

Long Time Coming

I predicted this would happen in 2019. They warned us then and they are giving you almost a year to make plans. A lot of folks complained here, but this change is most certainly going to happen and it is in everyone’s best interest.

Now that Airtable has officially announced new specifications for its CDN, any solutions that depend heavily on images that need to be accessed outside the Airtable UI will probably require that you host them in your own CDN.

What’s a CDN?

Cloudflare provides one of the better definitions:

A content delivery network (CDN) refers to a geographically distributed group of servers which work together to provide fast delivery of Internet content. A CDN allows for the quick transfer of assets needed for loading Internet content including HTML pages, javascript files, stylesheets, images, and videos. The popularity of CDN services continues to grow, and today the majority of web traffic is served through CDNs, including traffic from major sites like Facebook, Netflix, and Amazon.

Airtable, of course, has its own CDN to provide access to the images and files you upload to attachment fields. The intent of this CDN is for it’s paying customers; not as a global hosting server. If you need to host your Airtable-bound digital artifacts, you’re going to need to essentially replicate Airtable’s CDN, so you might want to read on.

Thanks Google Drive!

One might think that Google Drive, or other services such as DropBox or Box will host these files for me, but that could be a mistake. These services don’t want to be your CDN any more than Airtable does. They include ToS clauses that allow them to throttle open access to your documents despite being fully shared to the open Internet.

One Approach

There are many ways to create a CDN for your attachment files. In fact, Cloudinary is an ideal ready-made CDN that also provides many features for sizing and rendering images in custom formats and styles. However, it’s not a magic bullet and the pricing might be a little steep depending on your needs.

The complex part requires that you create some sort of an integration that pulls (or pushed) your attachments from Airtable (perhaps using the API or script automation) and upload yet another copy into your CDN environment. If you have a serious commitment to attachments, this could be a sizeable challenge. There’s also the issue of keeping your CDN updated in near-real-time, a key requirement that is more easily addressed with Firebase.

These complexities may not be easy to build depending on your selection of a premade SaaS CDN solution. And, you might also get lucky with Zapier or another glue-factory approach. Experiment a little and see what works best for your situation.

I have already helped a few friends design an approach that uses Firebase, a Google Cloud Platform service that is very fast and provides a generous free tier and an integrated CDN.

WARNING - CDNs are not universal in features. Some are globally distributed while others provide localized servers in your country. The costs vary greatly as well. And it also depends on your hosting and delivery requirements.

[Olpy_Acaflo]

Hi @Thibaud_Donzier, @Bill.French ,
I’m already a miniExtensions Customer but I don’t have (yet) an account at CLOUDINARY so I haven’t tried it yet because I’m currently trying to build a reproduction of the Google Cloud path suggested by Bill French but with the help of ROWY UI and DX that I mentioned above, to make my life easier as a beginner in Firebase, Firestore, I think for the moment and until any evidence to the opposite.

At Firebase experience beginning, it filled my 3rd screen with ‘awesome’ :winking_face: logs and not very easy to interpret but I still have a few days left not too busy at work outside my own Airtable activities to try to finish and publish some kind of report to share with you for better or for worse, in the state I will have reached. If I can do it in this small remaining time.

About the miniExtension (ME) you are showing, I don’t see where I could automatically retrieve the URL (an URL pointing to Cloudinary of course) of the image saved (transformed) in Cloudinary at the end of the work done by both ME and Cloudinary, without additional means (which ones?) to what ME offers.

However it seems mostly important to me that if an image saved in an Attachment Field of Airtable reaches Cloudinary thanks to ME, when the image is returned processed (or not) from Cloudinary, its reference URL should be written in an URL Field of Airtable, in order to be able to subsequently use the image saved in Cloudinary by its reference URL in an App that is neither Airtable nor airtable’s Shared View. (a built-on-top-of Airtable API frontend App e.g.).
This ME is no longer maintained by its DEV, so it will probably not evolve in this direction.
oLπ

[Bill_French]

Olpy_Acaflo:

in order to be able to subsequently use the image saved in Cloudinary by its reference URL in an App that is neither Airtable nor airtable’s Shared View.

This is correct; you are responsible for tracking the immutable URI; Airtable doesn’t do that in attachments, and in fact, it destroys the origin URL. This - in my view - is unfortunate. Airtable could easily add an attachment attribute/feature that allows it to copy the image for its use in the Airtable UI as well as sustain it as an external URL from whatever CDN it came from.

[Olpy_Acaflo]

Bill.French:

tracking the immutable URI; Airtable doesn’t do that in attachments, and in fact, it destroys the origin URL

This is exactly the problem that Airtable currently causes us, and not as the Consumers of the URL of the CDN rented by Airtable might think, the fact that we ourselves have to rent a CDN from the current Market Outlet.

When you add that an Airtable Field that would allow to display the .jpg, .png or .svg from its URL in a CDN of our choice in the available market does not currently exist,
we have shown, I think, why the simple removal of the current ability to use the Airtable rented CDN in our self-designed or rented FrontEnd Application via Airtable’s public API is a bit short-sighted for us, the Customers, and that this decision by Airtable should be coupled with improvements on these two points.

oLπ

[Ambroise_Dhenai]

As Bill predicted, we ended up building our own CDN.

Feature request: Public CDN opt-in for attachments Product Suggestions

Following the lack of official statement and reply to this proposal, I built my own public CDN. Definitely complicated, not no-code or low-code either, but it works well. If you need a similar solution implemented for your organization, you can PM me, it is something I can build for you, as a consultant.

[Lawrence_Chen]

Hey all! Wanted to keep using Airtable to easily store images for my projects, so I built a service that automatically uploads images/attachments to a CDN, and creates stable URLs that my website can then use.

Check it out here: https://aircdn.io

It’s has complete compatibility with Airtable’s API, so all it takes is to switch api.airtable.com to api.aircdn.io in your application code.

As a bonus, Air CDN can also resize your images to make your website load faster. Only supports images at the moment, but reach out and let me know what else you’d like to see!

[dirknaves]

In case anyone stumbles on this thread and is wanting to host canonical images on their own CDN, but still see those images visually in Airtable, it's fairly easy to build an airtable automation to get you 90% of the way there. In my own use case, I want to use my DAM cdn for images because I want one source of truth for those assets. I ended up adding two fields to each record.

1. A text field into which I post the CDN url for the image. (this will only display as a URL in airtable)

2. An attachment field to display the image.

Then I wrote an automation to update the attachment field whenever the record was changed. It will take whatever is in the CDN url text field and will update the attachment to whatever it finds there. So if I change that image in my DAM CDN, whenever the record for that product is updated in Airtable, the automation will automatically grab that image from the DAM CDN and update the airtable attachment image. So yes, I do have airtable hosting its own copy of the image (to power the attachment field), but it remains in sync with the canonical image on my DAM CDN. I have it only checking if the record is edited, but you could devise your own most suitable trigger to achieve this.