Indeed. Cachex is much more actively maintained as well as more feature rich, so that’s what I’d recommend first.

ConCache happened organically. I needed it for production with exactly those features, and it is a third incarnation of the caching library (the first two were close sourced), applying the lessons learned from the previous attempts. It behaved very well for that scenario. I didn’t have a need for such caching since that project (which I left 4 years ago), so due to the lack of real needs and the lack of spare time, ConCache hasn’t progressed since then, save for an occasional contribution.

ConCache is currently not abandoned, although I wonder whether we need two caching solutions in the Elixir community. At first glance, it seems that there’s a lot of overlap between these two libraries. When I find the time I’ll study cachex in more details, and see if it makes sense to decommission ConCache in favour of cachex. In case anyone else has already compared the two, I’d be happy to hear your thoughts.

The main reason that you hear that is because of how efficient templating is with Phoenix. In Rails for example, when you break down the response time on a page a HUUUUUGE portion of it is spent rendering the view layer.

The other issue is the cost per response for the web server. When you’re working with a server that can’t handle a high volume of concurrent connections, you create a situation where you have to focus on getting in and out as fast as possible.

Elixir and Phoenix address both of these. Cost per connection is almost nothing because of the BEAM and the view layer is compiled into IO Lists.

The short explanation IO Lists of why that is that all of the strings that make up your template code are immutable values in a linked list. Rather than constructing a full string based response, this list is sent back to the socket and iterated over directly. The full page response doesn’t ever exist on the server because the pieces are sent individually to the socket, meaning all of the memory allocation from creating and destroying each part of the template on every request never happens.

Here’s the long explanation though: https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2-io-lists-in-phoenix/

For the volume of connections, even if you have a particularly slow database request, since the server can handle so many connections that one slow page isn’t going to degrade the experience of the others. If that particular page was dealing with a high volume of requests itself, it would be another story though.

The combination of these two means that the qualities that might normally cause a slow down that make you reach for different styles of caching are less necessary. The more you’re able to avoid caching the more you’re able to avoid cache invalidation, which gets to be more complicated as it grows.

If you do need caching, CacheEx is a very solid library that will let you wrap ETS and as a perk if you make 50 requests at the same time for the same piece of un-cached data, it will only make the request once and send the response back to all 50 requestors when it’s ready.

They can certainly become a bottleneck compared to ETS.. just going of the caching tangent..

btw, seems like Saša recommends checking out cachex first: