Yesterday, we published version 2.0 of CDN, a release jam-packed with new features and updates to existing functionality. In this article, we’ll go through some of the main changes.
If you’d rather jump straight into action, you can update your existing CDN project to use version
2.0.0, or install a fresh one using DADI CLI.
$ dadi cdn new my-new-cdn
The biggest piece of news is the support for modular plugins. Our engineering team has heavily focused on the flexibility and modularity of the various microservices in the stack, and in the same way custom functionality can be added to API using hooks and to Web using events, CDN now supports modular plugins.
workspace directory, just like a recipe or route, and allows applications to define custom logic that could do anything from dynamically changing image manipulation parameters before processing begins, to augmenting image processing capabilities with new operations and even different engines.
We’ll soon be sharing an article that explores the power of CDN plugins in more detail, which will also explain how you go about building your own.
Simplified URL paths for assets
Traditionally, accessing a non-image asset required specifying the asset type and a numeric flag for the compression status in the URL. For example, to access a file named
test.js in its original state, the corresponding URL would be
/js/0/test.js. With CDN 2.0 it becomes simply
A couple of examples of how the new format differs to the old:
The old format is still supported, but it has been deprecated and will be removed in a future major release.
Support for any type of asset
CDN 2.0 adds a generic file handler, which in practice means you can serve any type of asset. Even if there are no manipulation operations available for a particular type of file, you can still take full advantage of CDN’s caching layer (and the correct MIME type will be added to the response, too).
To start using it, you can add it to a recipe using the
format property in the
settings block, or simply specify it as the output format in the URL (e.g. https://cdn.somedomain.tech/samples/dog.jpeg?format=webp).
Original aspect ratio maintained by default
In versions 1.x, any requests where the aspect ratio of the output image isn’t explicit (i.e. only one of the dimensions is specified and the
ratio parameter isn’t suppplied) result in a cropped image, since the missing dimension is directly replaced by the corresponding dimension of the original image.
The problem with this approach is that to simply request a smaller version of an image, one had to specify both new dimensions. In practice, it meant that if a consumer required a resized image with a width of
x, they had to manually calculate the height
y so that the original aspect ratio of the image was preserved.
In version 2.0, the original aspect ratio of the image is always preserved when the output aspect ratio isn’t explicit. As a result, for a request with a new width
x, CDN will calculate the appropriate height so that the aspect ratio is maintained and the image isn’t cropped.
To get the old behavior, consumers can add
resizeStyle=aspectfill to their requests.
This is the only breaking change in the release.
Deprecating legacy URL format
The first version of CDN used a path URL format, which is now being deprecated in favor of the querystring URL format. Version 2.0 adds a deprecation warning whenever a request with this format is processed.
Developers are encouraged to update their applications to the new format, as the path URL format will be removed in the next major release.
We’re super excited about this release and the road it paves for the future of CDN. Watch this space as we share new updates and features with the community.
In return, please tell us all about the awesome stuff you’re building with it? ❤️
Written by Eduardo Bouças, principal Engineer at DADI. Eduardo leads the development of several DADI web services, including DADI CDN.