Default Config and Url Formarts about imgproxy HOT 9 CLOSED

🎉 imgproxy v2.0 has been released 🎉 Take a look at the new features, including new URL format, presets and default config (via presets): https://github.com/DarthSim/imgproxy/blob/master/CHANGELOG.md#v200

from imgproxy.

It is not 12factor-ready;

I take back the config file part. I would load configs from a config server, but that is too specific, instead I just mentioned config file. I still think presets could be useful; how to load them is app / org dependent.

It is not simple;

It's just switching from parsing the url to populating the processingOptions with a preset. (still need to get the preset though, but I don't see what's hard about that)

It doesn't solve any problem.

It does not solve any significant technical problem. Organization wise, you could let the design team handle the config presets and the dev team only need to know when to use which preset, e.g. thumbnail in list views vs large image in detail views. Given there is nice config/infra setup. Also, it would kill a few bytes if you have lots of images and you have to return complete urls from your app server to your clients.

from imgproxy.

Thanks a lot for the great works!

from imgproxy.

I'm going to keep the current URL format as a common way to use imgproxy, and develop a new format for a more advanced processing. But this feature is not going to appear in a short time because of my work load.

from imgproxy.

Might be great to be able to define presets with a config file, then simply do /%signature/%preset/%encoded_url.%extension

from imgproxy.

It is totally no:

1. It is not 12factor-ready;
2. It is not simple;
3. It doesn't solve any problem.

from imgproxy.

I take back the config file part. I would load configs from a config server, but that is too specific, instead I just mentioned config file. I still think presets could be useful; how to load them is app / org dependent.

Still doesn't work well with 12factor, and still too specific for your case

It's just switching from parsing the url to populating the processingOptions with a preset. (still need to get the preset though, but I don't see what's hard about that)

It's not simple for usage. Instead of just specifying params, you need to make a config file.

It does not solve any significant technical problem. Organization wise, you could let the design team handle the config presets and the dev team only need to know when to use which preset, e.g. thumbnail in list views vs large image in detail views. Given there is nice config/infra setup. Also, it would kill a few bytes if you have lots of images and you have to return complete urls from your app server to your clients.

The design team shouldn't config your servers or apps, it's developers purpose. In the end, frontend guys will put the URLs in the template. If you write the code to generate URLs, you can add presets support there without modifying imgproxy, just like we did.

Actually, presets aren't much related to this issue, it's better to open another one if you'd like to discuss the feature.

from imgproxy.

Actually, presets aren't much related to this issue, it's better to open another one if you'd like to discuss the feature.

Cool.

from imgproxy.

In my use case, changing the URL format would help with caching. If parts like the signature (we sign S3 URLs as well as imgproxy requests) could be kept in query strings, and the rest in the URL path, then we can ignore query strings on the CDN side to keep the signature from busting the cache. Has anyone else run into this? How do you solve it?

from imgproxy.