These are chat archives for jdubray/sam

12th
May 2016
Tomas Roos
@ptomasroos
May 12 2016 05:56
Then I would like to tip you on the following blog regarding structure large applications. http://jaysoo.ca/2016/02/28/organizing-redux-application/
Jean-Jacques Dubray
@jdubray
May 12 2016 07:49
You may want to look at the TODO application
SAM is just a programming model, it is not prescriptive as to how you "wire" the elements of the pattern together (observables would work just fine). It is not prescriptive on the architecture of your app either. I believe it's one of the simplest way to write isomorphic JavaScript.
The SAFE library may be useful to you when you deploy some elements on the server.
Tomas Roos
@ptomasroos
May 12 2016 07:54
Sure thing. Will take a look
Thanks
Jean-Jacques Dubray
@jdubray
May 12 2016 07:56
The things you want to watch for:
  • make sure that your theme (the view components) is as decoupled as possible from the application. SAM should be able to achieve close 100% decoupling
  • State needs to know about actions because of NAP()
  • The State function and the View can be reasonably decoupled
  • you have to decide how the present method routes the requests between the actions and the model. I prefer a DataSet type of interaction, but it's really up to you and there will be cases where you need to know which action/intent is presenting the data, it's not possible to achieve 100% decoupling
As we discussed SAM is less concerned about effects (and decoupling the logic from the effects). SAM factors the logic in three buckets: Propose/Accept/Learn, it is that decoupling of the different types of business logic that I believe leads to a better outcome. In particular, as I said the phase that is missing in other frameworks is the "accept" phase. In Redux for instance the store must accept everything the reducer proposes. There is no room (as I understand it) for the store to decide whether to accept / reject some values.
Tomas Roos
@ptomasroos
May 12 2016 08:02
That is def true
Thats why I think the semantics of a event would be better in the context of Redux
Since its not possible to reject it, rather make a compensating action (but again this is only possible with sagas, you can't dispatch from a reducer)
Jean-Jacques Dubray
@jdubray
May 12 2016 08:03
yes, exactly my point
and Sagas have their own state tree
Tomas Roos
@ptomasroos
May 12 2016 08:04
Indeed
Jean-Jacques Dubray
@jdubray
May 12 2016 08:04
I am not saying never use Sagas, but if you use them to tackle that problem, you are dead, your code will be awful.
Tomas Roos
@ptomasroos
May 12 2016 08:04
Why do you think so? The sagas per se, or the combination of reducer to write to state tree and saga's outcome/conclusions?
Jean-Jacques Dubray
@jdubray
May 12 2016 08:07
It's a fundamental reason, I know a thing or two about stateful orchestration since I built some of the early integration brokers / business process engines in the late 90s. I also built the chorus.js project (stateful orchestration for node.js) and contributed to many related specifications (WS-TX, ebBP, WS-CDL).
State Machines have "no memory", once you are in a state you don't need to know how you got there. The problem with Sagas is that they have a "memory" you write your code as if nothing else is happening. As you mentioned they are good (and were designed) for compensating transactions, but they have to be written in an imperative style.
As soon as you are going to need to write this logic in sagas you are going to start coordinating across sagas, it will become ugly very quickly
Jean-Jacques Dubray
@jdubray
May 12 2016 08:13
That's why I think the right way to do it, is:
  • do as much work as you can in the acceptor
  • use nap() when true compensation is needed or trigger new units of work
The other aspects that Redux does not have is the notion of "step", which important in some scenarios when you need to do action cancellation for instance. This kind of logic is very hard to model in Redux/Sagas
All this is coming from TLA+ for free (it's not like I made it up)
I know it's cool to put on your resume that you know how to use generators, but it's better if you know when not to use them...
Tomas Roos
@ptomasroos
May 12 2016 08:17
Hah. Do not care about my resume ;-) Rather trying to find pragmatic ways to use the technologies that are available and maximise the value i can get out of it.
Jean-Jacques Dubray
@jdubray
May 12 2016 08:17
I am with you
Tomas Roos
@ptomasroos
May 12 2016 08:17
I do recognise some concern you highlight. That everything gets intertwined pretty fast with the structure of React applications these days
Jean-Jacques Dubray
@jdubray
May 12 2016 08:18
Yes, that's exactly my point
Now don't get me wrong, SAM is not magical but because it is closer to the semantics of "state machines" it has less of this "memory effect" where you write your code from the point of view where you know exactly the sequence of events
because what we know is precisely that the sequence of events cannot be predicted
there lies the value of SAM/TLA+
Tomas Roos
@ptomasroos
May 12 2016 08:20
everything around scheduling is indeed unpredictable.
Jean-Jacques Dubray
@jdubray
May 12 2016 08:20
That's why you need to control with precision the boundary when you start mutating the application state
Tomas Roos
@ptomasroos
May 12 2016 08:20
Have you tried out using SAM as a pattern at the server side as well? On other languages
Jean-Jacques Dubray
@jdubray
May 12 2016 08:20
Yes, this is actually where I started
Tomas Roos
@ptomasroos
May 12 2016 08:20
I think that was the goal of having a single dispatcher in flux as well
To remove concurrency
It works very well
Tomas Roos
@ptomasroos
May 12 2016 08:21
And then the enhances around a single state tree came because it made it more simple
Jean-Jacques Dubray
@jdubray
May 12 2016 08:22
Yes, SST is essential, cannot be compromised
Tomas Roos
@ptomasroos
May 12 2016 08:22
Perfect. Will take a look at that bitbucket repo later today.
Jean-Jacques Dubray
@jdubray
May 12 2016 08:23
This is more "state machine" like because it is trying to solve the problem of complex API orchestrations.
Tomas Roos
@ptomasroos
May 12 2016 08:24
I see. And that makes perfect sense. Since we're in that situation across the world now.
Jean-Jacques Dubray
@jdubray
May 12 2016 08:24
There are some examples using WebSocket and a Queues
Tomas Roos
@ptomasroos
May 12 2016 08:24
More apps, more integrations, more complexity in terms of api's, multiple versions running ect
Is that using message passing then?
Since you broke the temporal coupling with a queue?
Jean-Jacques Dubray
@jdubray
May 12 2016 08:25
Well this is just wiring, you can still do request/response with a correlation id
Tomas Roos
@ptomasroos
May 12 2016 08:25
Indeed.
Jean-Jacques Dubray
@jdubray
May 12 2016 08:25
The state machine makes sure you don't get out of sequence
I tend to be very specific in decoupling programming model, wiring and architecture
All too often in our industry we tend to force fit one into another
E.g. the wiring or the architecture drive the programming model
Michael Terry
@formido
May 12 2016 17:57
What are examples of other programming models besides SAM
I can't google a definition of programming model that seems to fit your discussion
Jean-Jacques Dubray
@jdubray
May 12 2016 18:05
programming model simply refers to the way you factor your code. The programming model is generally very opinionated and somewhat arbitrary. Sometimes the wiring or the architecture get in the way, for instance when MVC is wired over HTTP you lose an important aspect of the original programming model where the controller updates the view (it's true with SAM too of course).
As we have seen there are multiple ways to factor the same code (keeping architecture and wiring aside) and even though Redux and SAM are fairly similar at a high level, in the details very small opinions drive major factoring differences such Sagas.
Sagas were carelessly introduced in the Redux programming model, to fix some deficiencies and probably because it was a way to use generators.
Michael Terry
@formido
May 12 2016 18:27
so programming model is SAM, MVC, MVVM, etc?
design patterns
Jean-Jacques Dubray
@jdubray
May 12 2016 18:28
It's a bit more than design pattern. It's the underlying semantics you overlay over programming constructs from which your solution is built.
An algorithm does not have a programming model per se
Michael Terry
@formido
May 12 2016 18:29
sure and no one calls that a design pattern
Jean-Jacques Dubray
@jdubray
May 12 2016 18:29
JEE is a bit more than a design pattern
I agree that the boundary is fuzzy
Michael Terry
@formido
May 12 2016 18:29
what is jee
Jean-Jacques Dubray
@jdubray
May 12 2016 18:29
but it's a bit more opinionated than a design pattern
? JEE?
Michael Terry
@formido
May 12 2016 18:30
yes
Jean-Jacques Dubray
@jdubray
May 12 2016 18:30
Enterprise Java?
Or Spring
Spring is based on a pattern DI
Michael Terry
@formido
May 12 2016 18:30
Luckily I've never had to do any Java
Jean-Jacques Dubray
@jdubray
May 12 2016 18:30
You are so lucky
Michael Terry
@formido
May 12 2016 18:30
JEE is a programming model similar to SAM?
Jean-Jacques Dubray
@jdubray
May 12 2016 18:31
No, not at all
Michael Terry
@formido
May 12 2016 18:31
JEE is a bit more than a design pattern
What did you mean by that?
Jean-Jacques Dubray
@jdubray
May 12 2016 18:31
But it has opinionated semantics: session bean, entity bean, ...
Michael Terry
@formido
May 12 2016 18:31
I see
but isn't some of this wiring pretty opinionated semantics?
I think cycle.js is opinionated
Jean-Jacques Dubray
@jdubray
May 12 2016 18:32
As I mentioned, JEE comes with strong semantics in which you fit your code
I guess that's the difference for me between framework and library. JEE is a framework, Redux is a framework
Yes, that's the problem sometimes the wiring you choose drives some of the programming model, that's ok as long as you understand the implications
But often, like in the case of Cycle.js, people feel that the wiring IS_THE programming model
Pub/Sub is also a wiring that ends up to be pretty opinionated because you cannot overlay your code seeamlessly
I guess what I am trying to say is that everything we code amounts to executing actions reaching specific states. It does not mean that this has to be your programming model, that's not a good one, we all know that.
Michael Terry
@formido
May 12 2016 18:37
Wiring meaning the way events and/or messages flow through the system?
Jean-Jacques Dubray
@jdubray
May 12 2016 18:37
Yes
That being said, anything we overlay on top of these actions and states will have a huge impact on the clarity, stability and maintability of the code.
That's why Spring won over JEE for instance
Michael Terry
@formido
May 12 2016 18:38
And what do you characterize as being part of the architecture?
Client/server over HTTP?
Jean-Jacques Dubray
@jdubray
May 12 2016 18:38
That's where the elements of your programming model runs (how many tiers,...)
HTTP is wiring
I could use Websockets too
WIth SAM you have a choice as to where all the element are executed, in separate processes, not just client/server.
You look at Isomorphic React (at least that's how it looked last fall, I don't know if React 15 changed anything) and you know you don't want write React Isomorphic code.
Michael Terry
@formido
May 12 2016 18:41
Right, right, so what's an example of architecture then
Jean-Jacques Dubray
@jdubray
May 12 2016 18:41
AWS Lambda
Serverless !
You'd have to start making decisions about session management for instance.
That is an architecture concern, not a pattern or programming model concern
Michael Terry
@formido
May 12 2016 18:43
So architecture is heroku vs google app engine vs aws lambda vs colocation vs etc
Jean-Jacques Dubray
@jdubray
May 12 2016 18:44
I guess a pattern can have several programming models, which can be implemented with different wiring technologies over several architectures
It's also deliberately deciding where you run actions, models, states and views
Michael Terry
@formido
May 12 2016 18:45
ah
Jean-Jacques Dubray
@jdubray
May 12 2016 18:45
When things are truly isomorphic, then you realize that architecture becomes a choice
not a constraint
Spring too was fairly isomorphic when compared to JEE
Michael Terry
@formido
May 12 2016 18:45
I've enjoyed some of the links you've surfaced
Jean-Jacques Dubray
@jdubray
May 12 2016 18:45
happy to hear
Michael Terry
@formido
May 12 2016 18:46
I liked the one on vanilla js modules
presentation
state management is really hard
I like to get news on it :)
Jean-Jacques Dubray
@jdubray
May 12 2016 18:46
No question about it...