From Image Server to a Whole New Image Service
CCP Convict | 2019-11-01 00:00
As outlined by the previous blog, we're upgrading the image server to an entirely new service that better fits the modern developer environment and needs. This means a friendlier, RESTful API, dynamic resizing, multi-tenancy support, and all these will be served through a global CDN.
A New Domain
Initially, we thought about sharing the same domain as the previous image server, but the change is way too subtle. So we will use a completely new domain for the new image service: images.evetech.net
Actually, the new service has already been deployed and running for a while, so go ahead and give it a try! It has some documentation with a very "minimalistic design" for now, which will likely be improved in the future.
The New APIs
There are two main APIs in the new image service, we refer to them as "variations" and "image" here.
Different kinds of resources provide different variations of images. E.g. corporations have logos, characters have portraits, (EVE) types have both icons and renders. Variations for a resource are listed under resource_type/resource_id, for exmaple:
https://images.evetech.net/types/587
https://images.evetech.net/corporations/109299958
Appending the variation to the path above, and the service will respond with actual images. Currently the service supports:
Alliance logos: https://images.evetech.net/alliances/434243723/logo
Character portraits: https://images.evetech.net/characters/1338057886/portrait
Corporation logos: https://images.evetech.net/corporations/109299958/logo
Type icons: https://images.evetech.net/types/587/icon
Type renders: https://images.evetech.net/types/587/render
Resizing and multi-tenancy are supported through query parameters: size and tenant, respectively. For exmaple:
https://images.evetech.net/types/587?tenant=singularity
https://images.evetech.net/types/587/render?size=256&tenant=singularity
Currently the service only supports a set of sizes that are powers of 2, i.e.: 32, 64, 128, 256, 512 and 1024. When size is not supplied explicitly, the service will use an arbitary size. So it's usually better to query a specific size, especially when the target size is known ahead of time.
The service currently supports tranquility and singularity for tenants, and defaults to tranquility.
Migration Path
For new applications we recommend to start using the new image service immediately, with the new RESTful API. But for existing applications, we will try our best to provide an easier migration path, so that our developers that have poured a lot of effort into these applications will have enough time to try and test the new image service before deployment. The following will happen:
The new image service supports "old-style path" for now, e.g. https://images.evetech.net/Alliance/434243723_1024.png still works
We will change the DNS to point existing image server domains to the new service so that existing applications will continue to work for a while
bear in mind that this is nevertheless a network change, and the underlying network routes and even HTTP responses won't be 100% the same. But as far as image content is concerned, we expect no change
For any request that uses the "old-style path", the new image service will respond with a Warning header, indicating our intent to deprecate these in the future, just like how we deprecate legacy endpoints in ESI
Again, keep in mind this is only provided for smoothly transitioning developers of existing applications to the new image service. This will never be documented anywhere in the new image service, and we are planning to remove these support after a couple of months, for example when we're happy with usage metrics on these "old-style path", and the old domains will likely be deprecated at some point in the future as well.
Why the Upgrade
This change should (hopefully) be trivial for applications that use the current Image Server since it's mostly just a URL path change - just shuffle a few things around in your printf.
However. this means a lot internally to many teams inside CCP and for EVE development. The current "pipeline" involves a lot of manual work which are time consuming and prone to error, the new pipeline will be fully automated and also integrated into the EVE build system. This means that asset changes will be reflected as they're released - at most a couple of hours due to CDN caching - and developers will be immediately notified on any failure at build time.
On top of the pipeline change, the multi-tenancy support means it's a hell of a lot easier to support images for local servers we EVE developers use during day-to-day work. This bridges another gap between what a developer sees locally and what EVE players see after changes are released, so there will be less chance for bad changes to reach production servers unnoticed.
As famously said, a small step for you, but a big step for us!
And the IEC?
As mentioned in the previous blog, we will provide a final package for IEC and stop updating them. This plan is unchanged, at least in the forseeable future. The blocker for us to support it on the new image service boils down to discovery and addressability. But we will be happy to work with the community to seek a solution if there is enough interest.
Thanks for All the Fish
Before closing out, remember that all usage of developer resources need to be in compliance with our license.
And now, let's say goodbye to the good old Image Server!