If you want a simple, easily understood cache and didn't want to write all the logic using GenServers and ETS you could use dcache.

Nebulex looks more complicated than dcache, just comparing the getting started info: "In order to give more flexibility and loading only needed dependencies, Nebulex makes all its dependencies as optional." Then it goes on to describing shards, decorators, telemetry and external adapters like Cachex and Redis. So before I can run `mix deps.get` to include this package I now have to make decisions or at least read thru what those things are for this package.

I prefer picking simple dependencies and add complexity later on if needed.

> I prefer picking simple dependencies and add complexity later on if needed.

That's exactly what having optional dependencies does, though. Except that when you inevitably realize that e.g. you need to monitor your cache-hit ratio in production, enablement for that means adding a suggested dep and then flipping a config flag to use it, rather than finding your own separate dep that does that thing, and then gluing the two "simple" components together using code that is both only maintained by you (rather than the upstream), and which must necessarily only touch the outside interface of both of the components, and so may be many times less efficient than code that hooks into one component or the other.

In my experience people get wooed by libraries that have a lot of configurations, settings, optional features, etc. and then rarely use them. Just pick a simpler tool that does specifically what you need at the time. Also, modularize it so your entire code base isn’t impacted by swapping out a cache tool (or http, etc.)

I do know what you mean, but the Elixir ecosystem is fairly exceptional in this regard. (It helps that Elixir is a compiled language with macros; many libraries implement optional-dep support via the compile-time-macro equivalent of the strategy pattern, where you only get the runtime code you ask for, rather than a bunch of useless calls to hooks that have no subscribers in your codebase. And if you're imagining that results in awful codegen code, it doesn't; in many cases, this is just as simple as putting an if statement directly into a module body, with method definitions inside the if branches.)

It's also helped by an eye toward low coupling of these support libraries. Elixir's Phoenix web framework, for example, is "batteries included" in some senses; but all those batteries are only included because your own generated skeleton code pulls them in; not because the framework itself depends on them in any way. So if you don't need e.g. i18n, or views, or really anything beyond an API that responds with JSON; then you can delete ~five lines from your skeleton project, drop the relevant deps, and the resulting project will be a lightweight web framework that just serves API calls. (This is why there isn't really a "lightweight" Elixir web framework ala Flask/Sinatra/etc.; Phoenix is both Elixir's batteries-included web framework, and its lightweight/minimal web framework, depending on how you use it.)

I agree but setting up a basic Nebulex cache is on par with most elixir "app wide" libraries.

But yeah I guess the docs can be a bit overwhelming at first glance.

Personally I like the decorators, especially as Ecto does not provide a cache solution.

Nebulex shines when you need a distributed cache. ETS is per-node so you'd need to handle synchronizing the data if you ever scale horizontally.

To keep it simple, you could rewrite this post using ex_shards as it handles scaling ETS (which IIRC is the backend by default for Nebulex).

That said, I was able to write a distributed session store with Nebulex pretty quickly. Then extended it to support live sessions, though it's not up to feature parity with its ETS counterpart if anyone wants to help out with my PR https://github.com/pentacent/phoenix_live_session/pull/14