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:
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.
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.
You’re right, I was internally thinking of different Attachment fields from different tables, those will need one dedicated automation, for each table.
Also, AFAIK the “create” and “update” events are different, so you might need to have one automation which triggers during the “create record” event, and another which triggers during “record update” while watching all the Attachment fields.
So, in this case, that would require 2 automations per table where you’d want to make any attachment public. Associated with the 50 automations limit, it can be a hindrance (sure, you could have them in another database, but there are other issues to think of when doing that).
And it makes things harder to maintain as well.
I’ve opened the Feature request: Public CDN opt-in for attachments feature request, I believe it’d be the simplest way to deal with all of that.
Once again, this can be overcome and simplified. Imagine a view that sweeps up all records based on the value of a field that tracks the last modified date/time. This allows you to see both created and modified records which trigger the webhook listener.
Hi @Bill.French ,
Your solution overall-diagram
is inspiring me for a while but as you know, airtable + js + integrations is not my first job,
so I’m delaying the moment I would jump into your favourite Firebase / Firestore you were still talking about e.g. around airborne, elastic search, indexed full-text search and inside other threads.
Between eggs+roasted bacon and coffee (this is my actual usual breakfast, even in Belgium),
I was bookmarking something that could help to browse and maintain some pictures and light-weight (in my useCase) videos , not CDN’ed by airtable, but by something called a “firebase project” that’s still dark stuff for me (but not yet a dark hole :winking_face: )
I can’t wait to go from a not yet very well founded wish to a well conducted learning experience but I still don’t get time available to cross this new milestone.
So it is still possible that it will never happen before the deadline of 1/11/2022…
You (and the Community) might think that I would take the risk of desynchronizing the Airtable Attachments, the CDNurl’s and the Firebase project by going to manipulate it behind the back of Airtable and the automation yet discussed today by using ROWY or something like that if it exists, but it’s not so!
I’m just so newbie in Firebase that it would be very comfortable for me to see my records and possibly help me when my workflow prototype wouldn’t work as expected, which will happen.
Disclaimer: although I’m bringing ROWY up in this thread, I emphasize that this is strictly within the scope of this thread and is not an invitation to drift away by trying to compare ROWY and Airtable, at least not here.
If you are interested in this discussion, please open another thread elsewhere in the forum, thank you very much!
I like it because it’s based on proven tech; Cloudinary is a very solid platform with years of testing and deep understanding of CDN requirements. It does come at a cost and layered on top of that is Mini Extensions cost, but perhaps a worthy combination with lots of very useful features.
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.
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.
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.
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
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!