Reality check your library idea

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) Multiverses — multiverses v0.11.0 (I also have adapters for finch, and phoenix.pubsub)

Half-baked WIP, and you should probably use Matrex for now: GitHub - ityonemo/linear_algebra: Linear Algebra for Elixir · GitHub

Cookie Dough: compile-time differentiable programming in elixir: untitled - asciinema.org

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)

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.

That’s probably born out of my ignorance but aren’t there already options for state machines on the BEAM? How would this be different?

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.

Yeah, I got a brain fart and I forgot that there are libraries like that already. Sorry.

What might be interesting in that direction could be an implementation of Petri Nets in Elixir.

I saw an interesting talk at the Code BEAM STO a few years ago about them, and was under the impression that they can solve certain kinds of problems which are hard to model in a state machine.

Haha no prob that’s what this thread is for! I also have one that’s been humming along in prod for a year now: StateServer — state_server v0.4.10

It is in erlang, but its already there: gen_pnet | Hex

as promised, untangled “ansible for elixir”, very much version 0.1.0… I haven’t tested it against deploying my lab or production machines in the “untangled state” yet, so, expect errors unless my tests actually do correctly recapitulate everything correctly… Realbook — realbook v0.3.1

I’ve spent the day working on an idea of mine which had been lying in my backlog for too long:

Easy schema validation for incoming requests on a per-route basis.

In past projects I’ve occasionally used JSON schemas to ensure that incoming data actually looked like I was expecting it, which is especially relevant when doing API development.

This boiled down to either assigning the path to the schema in conn.private and evaluating it in a plug:

pipeline :api do
  # ...
  plug JSONSchemaValidator, private_key: :json_schema
end

scope "/", MyAppWeb do
  post "thing", MyController, :create, private: %{json_schema: "path/to/schema.json"}
end

or defining a plug per-route in the controller:

plug JSONSchemaValidator, [schema: "path/to/schema.json"] when action == :create

While this works it feels a bit clunky, so I dabbled a bit and ended up at this (I’m using Validation as a placeholder here, don’t have a name yet):

defmodule MyAppWeb.MyController do
  use Validation,
    adapter: Validation.JSONSchema,
    resolver: Validation.JSONSchema

  use MyAppWeb, :controller

  @validate schema: "path/to/schema.json"
  def create(conn, params) do
    # ...
  end
end

This actually complies down to the plug + action version from above but I feel like it’s so much clearer. The adapter and resolver options can of course also be defined in the config. The idea here is to stay agnostic from the kind of schema and provide these as separate libraries. One for JSON schema, one for Protobuf, etc.

What do you think? And do you have any name suggestions (I’m considering Gandalf - you shall not pass)?