Today marks the release of another major update to DADI CDN: version 3.0. Our main focus was making the app ready for our decentralised network, throwing in huge performance improvements and a couple of new features along the way. World, meet CDN 3.
🔗Support for multiple domains
Every installation of CDN contains two key directories:
config/: holds configuration data, with one file for each runtime environment.workspace/: holds application components like recipes, routes and plugins.
Both tend to be specific to each site or application, so if you were serving somedomain.tech and someotherdomain.tech, each with their own set of recipes, plugins and configuration settings, you’d need two separate instances of CDN running.
This creates some resource and maintenance overhead, which is particularly undesired on the DADI network. To address that, CDN 3.0 adds support for multiple domains, allowing instances to define different configuration and workspace directories for each domain being served.
Key resources like the image manipulation engine and the caching layer are still shared, but domain-specific parts can be broken out.
To get started with a multi-domain instance, head straight to the Multi-domain section of the updated documentation pages.
🔗Decentralised authentication
In CDN, some operations require authentication, such as flushing a cached item or creating a new recipe. We use a 2-step authentication process, where clients first send an ID/secret to a specific endpoint (the token store) and get back a bearer token with a pre-defined expiry time, which can be used to authenticate a request.
Every time a new token was issued by the token store, it was added to an internal database kept by every CDN instance. When an authenticated request came through, CDN would compare its bearer token against the internal database to see if it the token existed and was still valid.
Whilst this works on a typical architecture, it doesn’t adapt to a scenario where a request can be served by any one of hundreds (or thousands) of CDN instances running on the DADI network, as a token issued by instance A would only exist in its own local database and therefore it would not be recognised by instance B. So, we abandoned the concept of a local database altogether and adopted JSON Web Tokens (JWT).
By using JWT to generate bearer tokens we tie a token to the cryptographic key used to generate it, not to the CDN instance it runs on. In practice, this means that as long as all CDN instances share the same key, a bearer token will work across all nodes of the network.
🔗Digital Ocean Spaces
CDN 3.0 adds Digital Ocean Spaces to the list of sources supported for images and assets, joining Amazon S3, local file system and remote HTTP server.
Configuring CDN to use Spaces is pretty straightforward. In the coming days, we’ll release a tutorial that will guide you through the process step-by-step. In the meantime, you can take a peek under the hood and read the pull request notes.
🔗Performance improvements
One of the side-effects of having CDN as the first web service to launch on the DADI network is the immense amount of data that comes out of its use on the testnet. We’ve been analysing it closely and using it to inform decisions on the development of the product itself, mainly around performance optimisations for extreme load scenarios.
For CDN 3.0, we optimised the way assets from remote servers are fetched and processed. We also made changes to the caching layer, made possible by a new major release of our own cache module, extending the types of requests that can be cached and, therefore, made faster.
The result? The graph below shows a comparison between CDN 2.0 and CDN 3.0 when handling the same stress test, ranging from 15 to 120 requests per second, with up to 40 concurrent clients.
With our fast-paced develpoment cycle, we’ll continue to fine-tune the product with performance in mind as more data comes in from the testnet and, soon, the mainnet.
🔗Wrapping up
There’s more in the release than we can fit in an article, like the ability for recipes to define their own remote URL path or the option to flush cached items by domain, asset path or manipulation parameters. You can check the release notes for a full list of changes.
From today, version 3.0 is available via npm. Whether you’re updating an existing instance or setting up a new one, check the installation instructions on our documentation site. And, like always, we’re around if you have any questions or feedback. 👋
