2019-05-27 One of the most useful things when working on several projects simultaneously is common and similar tasks. It is completely obvious that the same functionality can be implemented once to save time on it in the future. Most software development teams use this in practice at every opportunity. In this post, we’d like to share own similar experience.

Not long ago we faced with the task of processing a large amount of images. One of our projects had to use eleven different versions of the same image! Well, you know — small, large, with a watermark, black and white, blurred and stuff. And in total there were about ...teen million such images there. A typical task of the app could be like “replace three versions of an image and add two more”. As is usually the case, all that stuff was stored on Amazon, with all the consequences that stem from that.

In another project we had to process images on the fly, while publishing. We mean something like “let’s crop it, let’s also resize, add filters, add a preview and so on”. Several image versions also had to be saved, not to mention an option “recover the original”.

Well, actually, hardly a project was finished without image processing at least at a basic level. The same avatars and other trifles, but images were present almost everywhere.

With this approach, in addition to development issues and twice work, we had also got additional administrative tasks: backups, suddenly, had to include extra image files; virtualization, in turn, happened to be not completely isolated. There were tasks which we’d prefer to do as rarely as possible.

A good solution in that case would be to use ready-made libraries and not to stand out, as most projects do. But we have opted for the dragonfly standard — developed our own service — and did the right thing.

As a result, we’d got a service for domestic use which processed images for all our applications and coped quite well. An additional advantage of an own service over third-party solutions was the ability to synchronize images with Amazon storage and keep locally only the most popular instances. While all the original, rarely used images were kept on Amazon and pulled out only as needed. Thus, the rest of the services didn’t work with files themselves in general anymore, and felt great without a permanent “file system”.

The new service turned out pretty convenient and facilitated the further development of many apps. Since we decided to spend time on it, everything had to be done for all occasions at once, so that it really became a common tool for all similar tasks. We made sure that it could be safely migrated anywhere, for example, deployed on the client-side server, if they asked for that, and safely upload images directly from the browser to the service, bypassing the request from one server to another. And certainly, we also made the necessary API. As a result, even though we have not attempted to sell it anybody else at that moment, its development quickly paid off.

When is it worth creating and improving your services, and when is it better to use existing solutions? In the last couple of posts we’ve touched this issue and described several principles which, in our opinion, can help to make a decision.