- The npm package published on the npm registry
Providing those two ways allows us to target different use cases:
Our goal with this strategy is to reduce the friction of using our service at every level of the developer experience.
Publishing on npm is rather easy: you just run `npm publish` in your directory and that’s it.
That’s when we found out about jsDelivr.
Delivering your libraries with jsDelivr
jsDelivr is a free CDN built exactly for this. It offers production quality of service and natively integrates with npm.
Our deployment process looks like this:
As you can see, the only manual action is to run `npm publish`. After that, the npm registry and jsDelivr handles everything.
Dive into jsDelivr
jsDelivr was launched in 2012 and is currently developed and maintained by Prospect One, a company opened by the original founders of the project. Since the start, it was fully open source and focused on developers, including the development of an API for all public CDNs with the help of the community.
jsDelivr has a unique-among-public-CDNs infrastructure: it uses multiple CDN providers and load-balances between them based on performance and uptime, instead of using a single CDN provider.
At the moment, jsDelivr uses Cloudflare, Fastly and Stackpath for all global file delivery except for mainland China, which is exclusively served by Quantil, a company that has a large network of servers across all major Chinese cities. This is made possible by the ICP license held by jsDelivr.
In total, jsDelivr serves about 19 billion requests every month. That’s almost 500TB of bandwidth of small ~3kb js files — all that from 176 locations all around the world.
To see more detail on how jsDelivr works under the hood, check the infographic below that visually explains all the failover systems integrated into it.
Pro tip: websites do not need auto updates
jsDelivr has some great features to automatically provide updated version of packages to consumers. For example, you can use scripts like:
- https://cdn.jsdelivr.net/npm/instantsearch.js@latest would be always updated with any latest version
- https://cdn.jsdelivr.net/npm/instantsearch.js@2 would always be updated with the last minor version of instantsearch.js v2 (following semver)
This sounded very cool for early Algolia: we could update our client websites at any moment with auto updating, and we could advertise that they would be always up to date. Alas, WRONG!
In fact, this turned out to have many disadvantages:
- Extra consciousness about any line of code added to our libraries
Ultimately, when your website works and has no issues on Monday, there’s no need to push an update on Tuesday from our side. When there are new features and fixes you might want, we will communicate with you via our community forum or change log.
Nowadays, for production systems, we recommend using fixed versions (like https://firstname.lastname@example.org), and being aware of new updates when you need them.
Still, auto updating packages has their advantages. When creating jsFiddle or CodeSandbox examples for our users to show us bugs to be fixed, we use auto updating so that we never have to manually updates those templates.
This feature is now coming to Node.js and browsers, which means there will be adjustments to make to both our build and delivery strategy, so we can support new usages like `<script type=”module”></script>`.
Big thanks to Dmitriy Akulov for his help with this post.