IIIF Image API Server
IIIF (International Image Interoperability Framework) is a set of open standards for delivering high-quality, attributed digital objects online. rokka supports now the Image API part of the specification. This means, you can upload a high resolution image to rokka and then for example use an Open Source viewer like OpenSeadragon to deliver those images and zoom in like as far as the image goes. See our docs for the details and a demo image.
JPEG XL (JXL) and AVIF support
We improved the support for the new and upcoming image formats JPEG XL and AVIF. It's not enabled by default yet, if you use the autoformat stack option, but we're happy to enable those formats for you. But you can use and test them with the .jxl and .avif file extension in every rokka organisation.
If you use the autoformat stack option, then rokka will decide, which is the best format to be sent to your browser, you don't have to do anything else in your browser or client side code.
AVIF is supported by some browsers already (Chrome and Firefox, for example), JPEG XL support is not enabled by them yet, but can be with changing a flag.
This site does of course have this feature enabled, so you'll get the images in JPEG/PNG, WebP, AVIF or JPEG XL, depending what your browser supports.
Uploading any file
Some clients of ours didn't want to use rokka for just storing images, PDFs or videos, but basically any format. For example 3D files for a product or Office documents. This allows them to offer downloads for such files without having to use another storage system. And with all other benefits of rokka, like an easy ReST API to manage those files, adding metadata and search for them, secure and unlimited storage in 3 different regions and of course fast delivery through a CDN.
You can't do render operations on them, but that's also not needed in this case. For security reasons, this feature is not enabled by default. Talk to us, if you'd like to use it.
Video reencoding
rokka did support delivering videos via HLS and in different bit rates since quite some time. But you had to upload all the different sizes manually and link them. To make this easier, we recently introduced automatic reencoding of uploaded videos to support adaptive streaming out-of-the-box. The docs have much more info about that feature.
Protected images and stacks
In general, images on rokka are pretty safe from unwanted downloads thanks to the unpredictable hash. If people don't know the hash, they can't guess it in a reasonable amount of time, even with the short hash (which also can be disabled). But if they do know the hash, they can do their own stack operations on it (if you know how rokka works).
Or you just want to have an image available for a certain time. This is why we introduced protected images and stacks. With this feature, URLs of protected images and stacks have to be signed with a private key and then are only delivered, if the signing hash corresponds to this key.
The docs have much more information about this feature, and there's also a little demo.
Rotate Api Keys
Adding a new Api Key to your user and deleting the old one was possible with rokka since the beginning, but it was not super intuitive. Now you can do that directly in the Dashboard or via some new API calls specially made for that.
rokka.js in typescript
We released final version 3 of our JavaScript client library rokka.js a few weeks ago after a way too long beta period. It's written in TypeScript now, that should enhance your autocomplete and type checking experience in your IDE a lot. It's supposed to be 100% backwards compatible to version 2.x, but we nevertheless decided to release it as new major version.
rokka hosted (soonish) in Switzerland
rokka is of course developed in Switzerland, but currently mainly hosted in the AWS Frankfurt region. But AWS is coming to Switzerland in the second half of next year and as soon as feasible, rokka then will also move its main hosting to Switzerland. Still on AWS, there are no plans to change that but we can make sure that all your images and data stay in Switzerland (if you'll forgo the backups in other regions, but we can also talk about other solutions for such cases).
Performance improvements
Behind the scence, we worked on some performance improvements. If for example the first operation is a resize operation, we don't have to load the whole image into memory, but can use the "shrink-on-load" feature by libvips and the underlying libraries to just load the size we will eventually need. This is especially helpful if a huge image only needs to be rendered as a thumbnail.
We also improved our caching algorithm to not having to rerender often requested images every few months again. One issue for example was our Team page. It has 200 small images of all Liipers, which are unfortunately not lazy loaded yet (due to being background images, it's a little bit more complicated with the lazy loading, but certainly possible, but that's another topic). So if the caches are empty, we get 200 hits on rokka to rerender huge original jpegs down to this small thumbnails. The shrink-on-load helps already, but it can still slow down our servers significantly before autoscaling hits in. And since we support 4 different image formats and deliver retina and non-retina pictures, depending on your screen and browser, this can happen up to 8 times. Every 6 months, since that's out current cache time in the backend. We now prevent this with resetting the modification time on our cache S3 storage, if the image is hit after 4 months to give it another 6 months to live, and thus not needing a potentially expensive rerender 2 months later. And still purging not used renders, when their time is up. Leading to faster response times for everyone all the time. (In case you wonder, of course the CDN does cache the images as well for as long as possible but depending on how often they are requested and how full their caches are, it will get requested again from the backend long before we'd prefer to...)
Unrelated to this, we sometimes also had a "cache stampede" problem during some live events. Lots of people were requesting the same, yet uncached, image and our servers tried to generate the same image multiple times at the same time (our CDN doesn't protect against this). We solved this with a locking mechanism on the server side. If a 2nd request comes in for the same URL, we let the client wait until the first request put it in the cache and then deliver it immediatly. A better experience for everyone while handling some edge cases.
Final words
I hope you enjoyed this little updated, and we'd be happy to see you on the rokka side and are always happy to help and answer questions. For example on our Slack or via email at rokka@rokka.io.
Credits
Photo by Kate Townsend on Unsplash