Code reuse with Nerves and gen_statem/gen_state_machine

Straffern · September 1, 2023, 6:46am

I am currently tinkering with a poc, which is a rewrite of an existing product originally implemented in Python.
I recently saw a presentation on :gen_statem, and wanted to play around with it. I quickly realised that it might fit nicely my case.

The problem/case:

The existing product functions both as a SaaS product and a “firmware” for an IoT product. Given that I hope to utilise Nerves, for the IoT product, I suddenly see a case for adding additional states, that only is a concern for the Nerves variant of the product.

What I’m asking

Is it possible to develop a standalone software, that can run in a container, but also be imported and extended in the Nerves software?

Such that I can extend the “Sensor” gen_state_machine, adding additional states, and override a selection of callbacks already implemented in “Sensor” module?

Do I need a macro for this?
Is this bad practice?

Thanks!

LostKobrakai · September 1, 2023, 6:51am

You don’t. If you think about it you’re doing the same with gen_statem already. It provides the underlying logic on how to run a state machine, while the module you implement provides the logic of which states act how.

You could provide your own behaviour and extension points within to further allow another behaviour implementing module to extend what you built on top of gen_statem.

Straffern · September 1, 2023, 8:16am

Its possible that I’ve misunderstood behaviours.
So I basically just add a bunch of typespecs for callbacks & types, similar to the implementation of gen_state_machine, and then make some state_function overridable?

LostKobrakai · September 1, 2023, 8:54am

That would be one way to do that, yes.

You can see similar “stacked implementations” with e.g. LiveView.

The top is a live_view module you implement with use Phoenix.LiveView with all it’s callbacks: Phoenix.LiveView — Phoenix LiveView v0.19.5
That module is used by Phoenix.LiveView.Channel, which is a GenServer: phoenix_live_view/lib/phoenix_live_view/channel.ex at v0.19.5 · phoenixframework/phoenix_live_view · GitHub
- It implements all the callbacks of a GenServer.
[More abstractions to follow]

Similarly for plain channels use Phoenix.Channel modules are also started as GenServer processes.

Straffern · September 1, 2023, 5:25pm

I don’t think I understand.
Looking at the second link with Phoenix.Liveview.Channel, I see no use of Phoenix.Liveview

LostKobrakai · September 4, 2023, 7:21am

It’s the other way round. The channel isn’t a LV. But the channel is what “runs” a LV.

E.g. here you can see it forwarding non-internally-handled handle_info messages to the liveview:

github.com

phoenixframework/phoenix_live_view/blob/v0.19.5/lib/phoenix_live_view/channel.ex#L421


      
                end
              end
            )
          end
          
          defp view_handle_info(msg, %{view: view} = socket) do
            exported? = exported?(view, :handle_info, 2)
          
            case Lifecycle.handle_info(msg, socket) do
              {:cont, %Socket{} = socket} when exported? ->
                view.handle_info(msg, socket)
          
              {:cont, %Socket{} = socket} when not exported? ->
                Logger.debug(
                  "warning: undefined handle_info in #{inspect(view)}. Unhandled message: #{inspect(msg)}"
                )
          
                {:noreply, socket}
          
              {_, %Socket{} = socket} ->
                {:noreply, socket}