Never think about image-processing infrastructure again
- industryFintech
- headquartersNew York, USA
- employees70
- tenure1 year
- cindicator.com
Cindicator offers a predictive analytics platform to help their clients improve their investment decisions in crypto and traditional financial markets. This system crowdsources market predictions from over a hundred thousand analysts, runs these forecasts through Cindicator’s machine learning models, and offers the resulting signals to their clients.
As a part of this platform, Cindicator interacts with a large number of images. Analysts upload avatar images to enhance their profiles, and Cindicator embeds images within their market prediction requests sent to those analysts.
In both of these cases, Cindicator needs a way to accept, process, serve the image uploads. Avatar images must be resized, and internal images must be processed to generate responsive image variants.
Unfortunately, performing these tasks at scale is quite difficult. File uploads fail, image processing is painful to automate, and serving images from your own servers rather than a CDN is a recipe for degraded application performance.
Sergey Bliznetsov, Cindicator’s Front End Architect, knows all of this quite well.
Before using Uploadcare, I just did all the image processing myself with scripts. You would give it the original image, and it would output five or six different versions. You would have to put them in different folders and maintain the folder structure and so on and so on. It was a nightmare. It’s a lot more work, and it’s not interesting work.
Uploadcare’s Smart CDN integrates the functionality of a traditional CDN with on-the-fly file processing. It allows you specify file transformations directly in the URL that will then be automatically processed and cached in the CDN. This combination allows you to manage all of your file processing without batch-processing requests or manually integrating the output with a CDN.
At Cindicator, Sergey uses this Smart CDN to resize their avatar images and generate responsive image variants. This system has three benefits:
First, Sergey can easily generate responsive images as needed without having to modify, test, commit, or run any image-processing scripts. He just specifies the image variant he needs in the URL, and drops that into his code.
On the front end, I really like that you can make a responsive image just by modifying the URL. It’s really easy to write the code. You just drop in the formatted URL for the image, and Uploadcare does everything else. It’s like ten times less work.
Second, Sergey gets an integrated CDN with his image processing, so he never needs to manage where his images are by hand. It’s with this combination that Sergey can simply forget about the details of his image processing infrastructure.
Even if you do generate responsive images automatically, you need a CDN to deliver them. Uploadcare contains both of these, so you don’t need to integrate with another service. If you use Uploadcare, managing and serving images is just not your concern at all.
Lastly, Sergey can save time and develop Cindicator’s software faster. He no longer needs to build and manage image-processing infrastructure, but can instead focus his energy on building Cindicator’s platform.
On a previous project, I didn’t take the opportunity to use Uploadcare because I was afraid it would take me a bit more time to implement than my usual way. I regret it all the way. I spent ten times more time than integrating Uploadcare.
Handling files is hard.
We make it easy.
Read similar stories
