HELP: what do we name this new feature? about redux-observable

[benlesh]

@jayphelps I think we decided on processManager, no?

[winkerVSbecks]

👍 for delegator.

[slorber]

I'd say coordinator if you want people to quite understand the purpose by the name, or epic if you want to invent some new fancy term :D

[tomkis]

It's pretty obvious that there are some similarities with redux-saga because the goal of those two libraries is basically same: react to actions and feed new actions into the action log.

Of course Saga is pattern which was originally meant to be used in BackEnd environment therefore the definition does not (and can't) 100% fit. Anyway, I am not exactly sure whether Saga is the right name but what I am sure of is that we are dealing here with Long Lived Transactions, technically Request <-> Response is transaction and is definitely Long Lived.

People have already agreed on fact that Redux is Event Sourcing implementation.

Redux based application architecture does have something in common with CQRS (Command Query Responsibility Segregation) but not as quite accurately as EventSourcing. The difference is that State does not need to be distributed unlike BE and that's why there's no concept of Command, since Command handler defines entity aggregate transaction boundaries which we technically don't need as we don't need to worry about concurrency.

And because even on BE EventSourcing is used just to deal with synchronous State transitions they still need some mechanism to deal with asynchronous workflow and side effects and that's exactly where Saga comes to play and look at those principal similarities:

public class OrderManagementSaga extends AbstractAnnotatedSaga {

    // Saga holds internal state which is specific to Long Lived Transaction
    // redux-saga holds this state inside Generator closure
    // redux-observable abstracts this state away into Stream (eg. debounce / takeLatest / filter)
    private boolean paid = false;
    private boolean delivered = false;

    // Saga Reacts to Events
    // parallel with  actions.ofType (redux-observable) or take (redux-saga)
    // don't worry about associationProperty, we don't need it, there is no
    // aggregate root on FE
    @StartSaga
    @SagaEventHandler(associationProperty = "orderId")
    public void handle(OrderCreatedEvent event) {

        // Saga is capable of dispatching new Actions
        // Where on BE there is always Command (because of concurrency)
        // and on FE there are just another plain Events (Actions)
        // redux-observable (output of the stream) / redux-saga (put)
        commandGateway.send(new PrepareShippingCommand(...));
        commandGateway.send(new CreateInvoiceCommand(...));
    }
    // ...

}

One more note about relation between redux-saga and this library. Technically asynchronous generators === Observables. redux-saga is building something very close to async generators to allow imperative approach over declarative Streams.

tldr: We don't have a strong argument to use term Saga but redux is Event Sourcing and it's common to use Sagas on BackEnd to solve exactly the same issues.

cc the right people @yelouafi @slorber @gaearon @jaysoo

[slorber]

@jayphelps I share @tomkis1 opinion

Apparently, the term "saga" is a real thing, outside of that redux-saga, but I feel like this is stretching that definition..chime in if you can provide a good argument in favor of using the term saga as well.

I've been the one introducing the term Saga in frontend environment. After our discussions @yelouafi choose to use that term for his own project. Maybe it was a good idea or a mistake... The fact is that you are true, there is an "official" definition with a paper about long running transactions, and all the code we see and people call "saga" feel a bit far away from the original paper.

Take a look at this link

Clarifying the terminology

The term saga is commonly used in discussions of CQRS to refer to a piece of code that coordinates and routes messages between bounded contexts and aggregates. However, for the purposes of this guidance we prefer to use the term process manager to refer to this type of code artifact. There are two reasons for this:

There is a well-known, pre-existing definition of the term saga that has a different meaning from the one generally understood in relation to CQRS. The term process manager is a better description of the role performed by this type of code artifact.

Although the term saga is often used in the context of the CQRS pattern, it has a pre-existing definition. We have chosen to use the term process manager in this guidance to avoid confusion with this pre-existing definition.

The term saga, in relation to distributed systems, was originally defined in the paper "Sagas" by Hector Garcia-Molina and Kenneth Salem. This paper proposes a mechanism that it calls a saga as an alternative to using a distributed transaction for managing a long-running business process. The paper recognizes that business processes are often comprised of multiple steps, each of which involves a transaction, and that overall consistency can be achieved by grouping these individual transactions into a distributed transaction. However, in long-running business processes, using distributed transactions can impact on the performance and concurrency of the system because of the locks that must be held for the duration of the distributed transaction.

My opinion:

• Saga: long running transactions a
• Process manager: orchestrate operation workflows across bounded contexts (ie decoupled components)

But we often need both at the same time, and on the backend there's also confusion and people do most often use the term "saga" in both cases.

Also it's annoying me that people think redux-saga is only meant to be used for async / api calls. The fact redux-saga is more testable than thunks is just an implementation details, and people really miss the most important advantage of it: decoupling

---

So I don't have a clear answer for a name, but just be aware that what you try to do has already been used for years in the backend, under different names like workflow, saga, process manager... You can create a new term if you want, but not sure it's a good idea. I don't know if the name "Flux" was a good idea. It may have helped spread a functional architecture on the frontend, but it also made the Flux users unaware that they are somehow doing event-sourcing in a bad way, and unaware that they can look at what have been done on the backend for decades in this field to improve their frontend applications.

Btw @tomkis1 is the code of @jayphelps very different of redux-saga-rxjs?

const saga = iterable => iterable
  .filter(({ action, state }) => action.type === 'FOO')
  .map(() => ({ type: 'BAR' }));

In both cases it looks like taking an observable of actions, and returning a new one of actions to be dispatched. But I've not used Rx for a long time so can't tell.

[yelouafi]

As @slorber said, the saga concept 'emerged' from a lengthy discussion about different alternatives to do side effects (the initial focus in this discussion was on IO) in a functional frontend architecture (I mean like Elm or Redux).

There were 2 key concepts behind the project

1. Business Events (i.e. Actions derived from other actions): with Observables it corresponds to the map operator (perhaps also a combinaison of bufferXXX/zip if the business event has not a 1-1 mapping with the input events): The main thing is that there is no IO involved here, we just derive a business Event from a sequence of input events.
2. Long running operations (but not necessarily with transactional semantics) this time involving IO; here the term Process Manager is more pertinent. I think this would correspond to dynamic switching in Observables (switchMap or flatmapLatest)

I agree the term Saga is perhaps confusing (or even unfortunate, but I think it's too late to change it now). Generators are an implementation detail. The same concepts can be expressed using streams, CSP, Actors or even raw state machines

[tomkis]

@slorber

Btw @tomkis1 is the code of @jayphelps very different of redux-saga-rxjs?

Not at all, I mean the idea is same.

[rgbkrk]

Fluorine uses the name agenda for this, which I thought mapped well to a series of actions.

[jayphelps]

@rgbkrk Thanks, I'll look into that.

We're currently leaning towards "process managers" because we feel saga definition doesn't apply and bonus, won't have confusion with redux-saga either (which incorrectly calls them sagas when they are actually more like process managers). http://kellabyte.com/2012/05/30/clarifying-the-saga-pattern/ tl;dr saga's don't have state.

[tomkis]

@jayphelps it's definitely worth coordinating with redux-saga I am afraid that naming the feature as process manager will lead to a serious confusion for some people. People may think that this is something different than the pattern used in redux-saga but that's of course not true.

@yelouafi maybe it's the right time about re-thinking the naming?

[slorber]

@jayphelps I'm not at all a saga expert but I think they hold state because if the saga crash you should be able to complete the transaction that crashed, so you need to persist where you are.

I don't know if we really need distrubuted transactions in the backend. Usually we talk to a single backend our intent to book a flight/car/hotel and it does that transaction for you (using locks, a hacky system, or a saga).

@tomkis1 do you think that there's a case where you issue request1, and then request2, and if request2 fails you need to compensate request1? Because even if a request can be considered as a long-lived transaction, it only involves one member in the distributed system. If you wish to book a flight/car/hotel you would generally send that to the backend in a single request. I'm not able to find any concrete frontend exemple where one could want to initiate a distributed transaction from the frontend (it can also be a security/consistency issue). So I don't think the strict definition of a saga applied well to what we are doing, even if that term is often misused in the same way by backend developers.

So the question is: do you want to name things for what they are, or do you want to name things for what they are known to be :)

It's not an easy question and in a perfect world it's probably better to name things for what they are. But I agree with @tomkis1 that it would be confusing to have 2 names in the frontend world for the same pattern. Good documentation on this topic can help.

[tomkis]

@slorber you are right that transaction does not (probably) need to be distributed on FE but isn't the whole point of Saga about Long Lived Transactions? For example optimistic updates does look really Sagish to me.

[slorber]

@tomkis1 kind of yes, but you usually only rollback the change you optimistically displayed to the user no?

If you look at @leebyron talk at Render 2016 about immutable architectures at 24'' it's about optimistic updates that are queued on top of each others. Sometimes you may want to display an optimistic state for an update that is not even yet sent to the server because it needs the result of another request. In this case perhaps the saga pattern may make sense because the failure of one request needs to revert optimistic updates of another, but I'm not sure having seen anyone using redux-saga for that unfortunatly

[jayphelps]

@Blesh confirm. Process Manager (until someone comes up with a totally unique buzz word hah)

[jayphelps]

OK people..turns out "process manager" is too long of name and using just "manager" is particularly ambiguous so some other suggestions were made. Please vote of them here: http://goo.gl/vNULnb

[tomkis]

+1 for coordinator

[zhenyulin]

reaction