Implement supervising strategies for domains

[z0s0]

It is a very common case when programmer wants to have high-level API to handle failures. It often makes sense to restart a part of application state in case of failures instead of letting user to encounter an error.

Proposal

A great implementation of fault-tolerance applications is already invented in Erlang-Elixir/OTP framework. They introduce a supervisor entity with several restart strategies. The idea is to return a part of application to its initial state, notify developer about error but let user to continue using the system. Of course these are code issues in most cases but it also covers errors from external sources such as network issues when system will continue performing properly after restart.

Elixir code example

children = [
  MyApp.DB1Connector,
  MyApp.DB2Connector,
  MyApp.Endpoint
]
options = [strategy: :one_for_one]
Supervisor.start_link(children, options)

Now our stores are being supervised with defined strategy.
List of proposed strategies:

• one_for_one

Means to restart a store with its initial state in case of error

• one_for_all

Means to restart all supervised nodes with initial states

• nothing

Keep default behavior to not crash the existing API.

It makes sense to focus attention on supervisor's structure. It is an Erlang process and worker is a process as well.
Hence it can be resolved by wrapping domain around another domain in case of effector terminology especially because Effector supports nested domains.
Also I can redefine restart strategy for particular domain manually to not break a Domain abstraction like this:
Each domain has restart options:

• permanent

The child is always restarted(default)

• temporary

the child is never restarted

So that I can improve my supervision tree like this:

children = [
  MyApp.DB1Connector,
  MyApp.DB2Connector,
  MyApp.Endpoint.child_spec(restart: :temporary)
]
options = [strategy: :one_for_all]
Supervisor.start_link(children, options)

This configuration will not restart an app in case of MyApp.Endpoint failure but will do it when MyApp.DB1Connector fails.
OTP keeps sync and async actions separately hence there is a direct analogy with Event and Effect.

Also supervisors and supervised domains would be a great framework to implement effector dev tools.

Effector API change request

createDomain('supervisedDomain', {supervisor: false, restart: 'permanent'}) createDomain('supervisorDomain', {supervisor: true, strategy: 'one_for_all'})
with default value false for supervisor option.

[goodmind]

What should supervisor do with events and effects? (since they also exist in domains)

[z0s0]

@goodmind Events and effects should be untouched, restart affects current state only

[goodmind]

What about current function in effect's use?

[zerobias]

seems like meaning of "restart" needs to be defined beforehand
for example, it looks pretty close to .reset in stores

[zerobias]

also, with this approach, we can remove obsolete subscriptions on the fly

[zerobias]

at first, we need to add .catch method to get semantic of "child is terminated", I mean, we need to have that anyway, isn't it?

for example

const store = createStore(null)

const computed = store.map(x => x)

computed.catch // event to forward to supervisor or something like that

[goodmind]

What should this do?

// old domain
const domain = createDomain('simple domain')

// supervised domain
const supervisedDomain = domain.domain('supervisedDomain', {supervisor: false, restart: 'permanent'})

[z0s0]

In this case behavior should remain untouched because supervisor option is not set in domain constructor

[zerobias]

https://github.com/elixir-lang/elixir/blob/master/lib/elixir/lib/supervisor.ex
https://github.com/blackberry/Erlang-OTP/blob/master/lib/stdlib/src/supervisor.erl

related links