Singleton vs Entity type Fish: which to use when?

Hi there,
in the actyx academy, two types of fish were introduced: singleton (or registry) and entity type.
Do you have any suggestion or rule of thumb to decide which type to use when?

thank you!

Hi @Dipta-IIC-EU,

you’d use entity twins to model something that can exist multiple times in your domain and has an identity. Typical examples are production orders, machines, material requests, etc.

If only one ‘thing’ exists in your system, you’d use a singleton. You already mentioned the prime example: Registries. You want to have a single place to ask for, e.g. all open production orders or all machines.

Does this clear things up a bit?

I see. So the existence of the registry would make it cheaper when we want to ask about status of all entities, right?

Let’s say I’d like to create entity twins for the production orders, and a registry that monitor all of the orders.
In both (entity and registry) I want to have an attribute status which shows the status of the order (placed, started, etc).
In that case, both types of fish need to handle an event separately even though the event changes the same attribute (status), right?

I am thinking about other possible patterns,

  • with only a singleton containing all the orders (e.g. in a record with an id as the key, and the order object as the value)
  • with only entity fishes (and just call all the fishes when need to monitor the status) - (I haven’t tried this pattern, though).

I believe each of those patterns has advantages and drawbacks, but is there any preferable or recommended pattern for such case?

(please let me know if the question does not make sense, maybe I misunderstood something somewhere :sweat_smile:)

You often want to do something (e.g. show) all entities in an actionable state, e.g. all open orders or all material requests waiting to be served.

In this case, I’d use a separate registry for the different status I’m interested in, e.g. one for all orders in status placed. Record order twins in there once their status matches by listening to the corresponding event, e.g. OrderPlaced.
It’s absolutely fine to subscribe to one event from multiple parts in your application.
You wrote

In that case, both types of fish need to handle an event separately even though the event changes the same attribute ( status ), right?

I’d suggest thinking about it differently: The event does not change the state, but the twin changes its own state based on the event it receives. This may seem like a small difference, but it makes the scope and responsibility more obvious. The party emitting the event does not concern itself with how other parties chose to interpret it.

While it is fine to create a twin solely for the purpose of recording a subset of the state of several entities (e.g. the status of all orders), I’d recommend not to apply this as an optimization prematurely. State computation is quite fast (esp. since v2) and you might be just fine with hydrating multiple twins. However, once you are sure that it improves performance, it’s a valid pattern to pull. Just do some experiments or back-of-the-napkin calculations first.

Addressing the two patterns you mentioned:

  • Following the reasoning from above, tracking the order object (= the order twin’s state) in a singleton is not recommended. Calculating an entity’s state should be fast enough, and you’d just do it in another location, probably doing unnecessary work (when you have such a singleton and an order twin) and complicating the registry’s state computation.
  • If I understand you correctly, that’s basically the registry pattern. The registry just provides you with a way to get hold of an entity’s ID and hydrate the corresponding twin.

Makes sense?

Hi @wwerner ,

thank you for the answer, I think it helps with my understanding.
I guess I am still used to a centralized programming pattern, always use the “what does the event do to the states?” thinking. Changing it into “let the states change themeselves based on the events” takes a bit of practice. :wink:

1 Like