Clojurians Log v2

What is recommended for gzip on ring? https://github.com/bertrandk/ring-gzip or https://github.com/amalloy/ring-gzip-middleware or something else?

@puzzler i did a quick look at both of the project and they all look good to me. It is pretty straightforward so I think either one is fine. We have been using the latter in production for almost a year without any problems

@lumengxi Thanks!

I'd like a little more guidance about how to use the ring-gzip-middleware effectively. Ideally, I'd like to gzip all the javascripts found in the js subdirectory of the resources directory. Problem is that the static resources are configured through site-defaults/wrap-defaults which puts the static file handling in the middle of a huge stack of middleware. It's not really obvious to me how to isolate the js subdirectory for gzip behavior, yet keep all the other options which are vital to good static resource handling. Can anyone point me to a good example?

@lumengxi The more I read up on this, the more it looks like a gzip middleware is not advisable unless you have some way of whitelisting or blacklisting certain content types. For example, you never want to gzip pdfs or pngs because those are already compressed and you'll just burn CPU time and make the file bigger. It doesn't look like either of these middleware libs support that out of the box. How are you using the ring-gzip-middleware lib? Are you applying it to everything and if not, how do you discriminate between file types?

Upon closer inspection, it looks like ring-gzip has its own reasonable whitelist built in, and there are forks that support static gzip files.

@puzzler it's also possible to gzip at the level of the server, e.g. in Jetty: http://martintrojer.github.io/clojure/2015/10/04/enable-gzip-with-ring-and-jetty

That's elegant. That may make more sense than to do it at the ring level. I wish immutant had as simple a way to add gzip.

@puzzler we use it only in API services, if your service is serving static contents, I would suggest doing that behind something like nginx, or as @metametadata suggested, in Jetty.