Clarification of Events vs Observer vs MailboxProcessor in F#

Question

I have a system, connected to financial markets, that makes a very heavy use of events.

All the code is structured as a cascade of events with filters, aggregations, etc in between.

Originally the system was written in C# and then ported to F# (which in retrospect was a great move) and events in the C# code got replaced by events in F# without giving it much thoughts.

I have heard about the observer pattern, but I haven't really gone through the topic. And recently, I have read, through some random browsing, about F#'s Mailbox processor.

I read this: Difference between Observer Pattern and Event-Driven Approach and I didn't get it, but apparently over 150 people voted that the answer wasn't too clear as well :)

In an article like this: https://hackernoon.com/observer-vs-pub-sub-pattern-50d3b27f838c it seems like the observer pattern is strictly identical to events...

At first glance, they seem to be solving the same kind of problems, just with different interfaces but that got me to think about 2 questions:

• Is the mailbox processor really a thing being used? it seems to appear mostly in older documentation and, in the packages I'm using, I haven't come across any using it

• Regarding the observer pattern, only one package across the sizeable amount we're using makes internal use of it, but everything else is just using basic events.

Are there specific use cases fitting the Observable pattern and the MailboxProcessor? Do they have features that are unique? or are they just syntactic help around events in the end?

Answer 1

As simplified as possible:

Mailbox

This is a minimal implementation of the actor model. You post messages to a queue, and your loop reads the messages from the queue, one by one. Maybe it posts to another mailbox or it does something with the messages.

• Any action can only take place when a message is received.
• Posting to the queue is non-blocking, i.e, no back-pressure.
• All exceptions are caught and exposed as an event on the mailbox. They are expected to be handled by the actor above it.
• Other actor frameworks provide features like supervisors, contracts, failover, etc.

Events

Events are a language supported callback mechanism.

It's a simple implementation. You register a callback delegate, and when the event is raised, your delegate is called.

• Delegates are called in the order they are added.
• Events are blocking, and synchronous. The one delegate blocks, the rest are delayed.
• Events are about writing code to respond to events, as opposed what came before it, which was polling.
• The handler for an event is usually the final end-point for that event, and it usually has side-effects.
• Sharing a handler is common. For example, ten buttons might have the same function handling clicks, because the sender of the event is known.
• You handle exceptions by yourself, typically in the handler code

Observables

There's a source (Observable) which you can subscribe to with a sink (Observer). An observable represents a bounded or un-bounded stream of values. An unbounded stream (an Observable which never completes) seems similar to an event, but there are several important properties to Observables.

• An Observable emits a series of notifications, which follows this contract:

    OnNext* (OnError|OnCompleted)+

• All notifications are serialized
• Notifications may or may not be synchronous. There's no guarantee of back-pressure.
• The value of Observables lies in the fact that they are compose-able.
• An observable represents a stream of future notifications, operators act to transform this stream.
• This approach is sometimes called complex event processing (CEP).
• Exception handling is part of the pipeline, and there are many combinators to deal with it.
• You typically never implement an Observer yourself. You use combinators to set up a pipeline which models the behavior you want.