This is a great idea! Well I have been busy due to the whole… global situation, and have several projects in varying states of bakedness.

Full-baked (but not sure if this library is “literally the worst” or not, so i’m too scared to generally advertise it):

• a broader toolkit for letting you shard various forms of global shared state (a la Mox and Ecto allowances) https://hexdocs.pm/multiverses/Multiverses.html (I also have adapters for finch, and phoenix.pubsub)

Half-baked WIP, and you should probably use Matrex for now: https://github.com/ityonemo/linear_algebra

Cookie Dough: compile-time differentiable programming in elixir: https://asciinema.org/a/2fzfsorBgf1zzQK70TYOTG39T

And I have one project that I just need to untangle from some other software, make better tests, and document it (and come up with a name for it - I’m thinking “Fakebooks”), it’s basically “ansible for elixir”, except using actual elixir as code instead of yaml. (so when debugging it you can drop IO.inspects in, etc)

I was working on refactoring Slick Inbox and I looked at my admin tool and didn’t like what I saw. It’s built with LIveView, but I find that I am repeating a lot of the same things (search, pagination etc) on every admin page that I have. They’re pretty simple pages, they list the entities in the DB (Newsletter, User, Webhook etc), I can edit them etc, it’s just so I don’t need to always SSH into my DB to do admin stuffs (like manually verifying user).

I looked at the repetitive stuffs, extracted them, and right now it’s looking like it could actually be generalisable for a library idea, tentatively named Backoffice, but I thought it would be good to check here first.

I actually found that it somehow end up looking quite a bit like Kaffy, which looks like a pretty great project, but my approach slightly differs in some way.

1. Kaffy uses controllers. Backoffice uses LiveView

2. You use Kaffy by using it in your router, the available paths are hidden from you, and you need to find it elsewhere (config.exs or a different Config module)

3. Kaffy works by having one controller, and then it renders things for you with a single controller as seen here. Backoffice would seamlessly integrate into your router file, you still need to declare your individual Live pages, but you can use Backoffice and that basically bootstraps your Live to an admin interface.

With Kaffy:

# https://github.com/aesmail/kaffy-demo/blob/master/lib/bakery_web/router.ex#L16

# router.exs
defmodule YourApp.Router do
  use Kaffy.Routes
end

I’m not a fan of this idea since it’s not immediately obvious what pages are available (the routes are defined in config.exs which could potentially call out to a different Config module as well, but I prefer things to be colocated)

With Backoffice, it would sit right next to your current set-up.

# router.exs

scope "/admin", YourAppWeb, do
    live("/users", UserLive.Index, :index) # these are your existing pages
    live("/users/:id/edit", UserLive.Index, :edit)

    live("/newsletters", Backoffice.NewsletterLive.Index, :index)
    live("/newsletters/:id/edit", Backoffice.NewsletterLive.Index, :edit)
end

You still need to create your own LiveView module, but you can see it sits nicely in your router, and Backoffice provides you a starting template of some sorts that you can then customize. For example, at a minimum you’d need:

defmodule YourAppWeb.Backoffice.NewsletterLive.Index do
  use Backoffice.Resources,
    repo: YourAppWeb.Repo,
    resource: YourAppWeb.Newsletter
end

This is essentially a wrapper to use Phoenix.LiveView and defines most of the callbacks for you. It also handles pagination for you (right now I’m depending on Scrivener.Ecto), and search (with a raw ilike query that doesn’t deal with input sanitization for now… works for my internal usage ).

It has a list of things that you can override/customize, like what Kaffy does, so that part is not too surprising.

Kaffy already seems to be pretty great, but I didn’t like the way it configures. Backoffice is basically just me extracting out my current set-up, which may or may not be a good set-up as it might differ from how other people are building LiveViews.

I have already extracted it out in my codebase for a proof of concept and it’s working fine so far, but it still does make some assumption at a few places, so there’s quite a bit of work involved to remove those assumptions too.

What do you think? Is this something that is worth putting more effort into?

Making a finite-state automata library for Elixir might be worth it. People around here regularly use state machines to enforce proper state transitions and that certain persistent workers aren’t stuck in an invalid state that the code authors have no answer for.

FSTs sound like a good answer for part of these scenarios.

EDIT: There is such a library already: fsmx.

Here is the next crazy idea from the place that is my brain: (I’m committed to finishing Selectrix, don’t worry).

LiveView over WebRTC. The idea being that you could have a server behind a firewall, connecting up to a handshake server. Then you could from your device or terminal connect to the handshake server, and it would perform STUN/TURN and connect you P2P (ideally) to your server on the other side of the firewall.

I’m thinking the best use case would be a privacy-oriented storage device. You could build out the interface using phoenix liveview, and owners could connect into their own servers easily.

Before I write everything down, I want to say that I’m really interested in any kind of feedback you might have on this idea, because I’m not certain if there is actually an interest for it. So please tell me what you think.

I’ve been considering to create a bunch of micro frameworks to help with doing DDD-style development in elixir. What do I mean with that?

DDD is about actually understanding the problem domain and then translating this understanding into code which actually solves the underlying problems. While there is no “one true way” of doing that, there are a bunch of patterns which tend to be very helpful, such as aggregates, events, commands etc.

All of these are provided by Commanded, and while Commanded is a fine piece of software, it comes with a heavy buy-in. As far as I know there is no option to “pick and choose”. Only want to use commands, and aggregates but no events? Well that’s to bad.

Here is where this idea about the DDD micro frameworks come in. The thought is that there are multiple parts to it, each focusing on specific patterns while providing entry points to hook in functionality.

You might have a command library, but where those commands get routed is under your control.

You could have an aggregate modeling library, spinning up an aggregate as a process from a data store, but where the data is stored and how (snapshots or events) is under your control.

You might choose to go the event route, and publish and subscribe to them, but where they come from and where they go is under your control.

Each of these parts would then provide well defined APIs to hook into the edges of their functionality, and each of them could provide adapters for hooks of the other parts.

At the end of the day this would leave you with a modular group of libraries from which you can pick and choose what you need. Want to go full blown? Take them all, probably by using a single dependency which includes them all. Want to only do this one thing and maybe the other? Pick the respective parts.

The end result is that you stay in control about how much buy in you do. After all it is you who knows best what is needed in your particular problem domain.