Curious about something technically. I happened to see “unpkg.com” flash by in my browser status bar when my Bubble app page was loading. Does Bubble itself use unpkg? If so, that is rather concerning to me. I had a dreadful experience with unpkg last year (unrelated to Bubble) that almost led to the cancellation of a huge customer contract. For the uninitiated, unpkg is a CDN vouched for by Facebook in its React documentation. Turns out that unpkg, at least at that time, is a “best effort” service with no real SLA. It was infected with a virus last April and caused huge headaches for a lot of apps dependent on it. (We quickly switched to AWS CloudFront once the issue surfaced.)
Anyways, just want to make sure this is not a native Bubble dependency, or if it is, if someone from @Bubble could explain that decision. In the meantime, I’ll check my plugins, too – fair warning to everyone out there to be mindful of what you’re installing and what its dependencies are!
That new carousel plug-in uses it. See post from @ryley.randall. I’d never heard of unpkg and asked him in that thread why he loads the lib using that instead of cdnjs
If you installed that plug-in that’s where that’s coming from.
To that point, @emmanuel, I load some pretty big libs in my app and currently do this via cdnjs, but recently I uploaded a large config file that is stored in aws (clarification: by which I mean it’s stored in s3 via the built in Bubble facilities and find this works fine).
Would I actually get superior performance if I took my large libs (like moment, moment-Timezone, etc.) and just loaded them that way (referencing the aws URL) instead of via cdnjs?
[EDIT: Further in the thread, I learn that Bubble makes it easy to add files like this to its own CDN on Cloudfront, which is what emmanuel was referring to. I ended up doing that.]
The list of most popular library networks includes CDNjs, Unpkg and jsDelivr among others. Library authors have a preference as to where they’d like to host their libraries; Leaflet (which powers Mapbox) is offered on Unpkg, for example. As an alternative, plugin authors can upload directly to Bubble’s CDN (Cloudfront) via the Plugin Editor.
A-ha, @copilot. I’d never messed with the “shared assets” section of the plug-in editor. Thanks for the tip. That’s extremely handy! Your comment wins the Internet for me today.
So this makes me still wonder a modified version of my question: “For my big custom config file script, should I continue serving that via AWS, or would it be better to upload that to Cloudfront?” I’m guessing the latter might be superior (thinking being that the AWS file bucket probably doesn’t exist in a CDN-like environment with multiple geographically distributed servers and whatnot…).
(Note to self and others: You can just use that facility in the plug-in editor to upload customized libs or whatever right to Cloudfront. The interface returns you a path to the stored object in Cloudfront. That thing is then generally available via that URL. No need to actually complete or publish a plug-in to use this, just create a dummy plug-in and use that facility.
To break this down for future readers, we’ll assume your use of ‘AWS’ equates to AWS’ S3 product.
Cloudfront, unlike S3, is a content-delivery network (CDN); your file is distributed across the world and pulled from the closest server to a user verses an absolute location. Linking to an S3 file directly, without the help of a CDN (like AWS’ Cloudfront), would require the recipient to exclusively pull the file from the server location of your S3 bucket. Longer distances usually means slow loading, which isn’t ideal.
From cost and performance to developer-friendliness, shoot for Bubble’s built-in dependency tool.
I’d pretty much decided to to this already, but based on @copilot’s feedback, I’ve modified loading of my big config file to use Cloudfront CDN rather than serving from the AWS s3 file location.
(Again, this tip about the plug-in editor feature for uploading assets to Cloudfront is huge. I’m sure I’ve been in a situation before where I was like, “Hmm, I’d really like to load this funky library but it’s not available in a reliable CDN and I just can’t be bothered to hack around with packaging it a different way.” But turns out Bubble makes that super EZ.
Thanks @emmanuel and @copilot for the pointers! This is something I probably never would have discovered from the documentation.)
Also, thanks to @edd, the OP, for giving this info a reason to surface. (Sorry to hijack your thread a bit.)
It’s a good hijack, @keith! My faith in Bubble has been confirmed and more importantly maybe this thread will inspire past/present/future plugin authors to use native Bubble features rather than introduce new dependencies that can surprise unsuspecting users down the line. Win win!
So bubble is already on a CDN so registering our bubble app pages with any other CDN like cloudfare is not required and will not further boost the speed.
Sorry to open an older thread but I just want to make sure I got the correctly ? Thank you for clarifying in advance !
No, that’s not really what was being discussed here.
This is about different CDNs as sources of libraries and the fact that, if you’re building a plug-in that relies on some library, you can easily repackage a library that’s not available on a reliable CDN using the method that Emmanuel mentions and that copilot then clarifies for me in the thread above. (Cloudfront is Amazon’s CDN.)
(This is not to say that Unpkg is necessarily unreliable. The OP here relates some story that I don’t know the truth of. I just happened to chime in as I had seen unpkg used in another recently-released plugin and was like, “what the heck is that?” And then, completely coincidentally, this thread popped up [and, actually, that was likely no coincidence, but a prime example of the Baader-Meinhof phenomenon]… Anywhoo, I was at the time trying to solve a problem related not to a plugin but to the fact that on many of my own app’s pages, I run custom code (kind of the same thing) and was extending that code (based on moment / moment-timezone) with support for custom locales. I was trying to figure out the fastest way of delivering my custom collection of locales to my app – looking at the tradeoffs between delivering that file from “my own database” (which in this context just meant an AWS s3 bucket) vs via external means.
Back to unpkg for a second: I see more and more libs on Github / NPM that use unpkg as their CDN of choice. This is not to say that the same package is not available on cdnjs or whatever alternative.
If none of the above means anything to you, this thread does not hold much of any value to you. Though note that, for very large assets, it is worth considering whether you might snag them not from your own database but from a CDN. As is made clear in this thread, Bubble provides a very easy way to take some asset and package it in the cloudfront CDN and then consume it in Bubble.)
