These are chat archives for jdubray/sam

Jun 2018
Antanas A.
Jun 28 2018 07:22
Antanas A.
Jun 28 2018 07:59

I'm trying to prototype some concepts of SAM into server side and raised some issues on actions.

  1. If an action is only a "proposal generator" for models, whom will execute process like sending email to customer or connecting with 3rd party API?
  2. If an action to do it's job needs to propose changes to n-models to achieve it's goal?
  3. If an action is dependent on another action's results how to compose them?
  4. As I understood models is responsible to accept "proposals" generated from actions ("commit action"), but can they not accept it? And how to propagate back "not-accepted" event into action. How to determine is accepting is completed?
  5. Who wraps all SAM logic? In the top most system layer I want only have an "BusinessDefinedActionDefinition" which can be triggered by some external force (button click, http call, etc.)

Done some prototyping and results feels too complicated. Result of actions is Monadic, model acceptors is some kind of an Interpreter with Event emitting. 3rd party API, sending email actions is wrapped into like SendEmailModel which acceptor submits email and also emits events (like regular model). And all architecture feels like it should be actor-model based without any direct request-response coupling.
Please share you thoughts about it, have you been done or trying to do similar kind of implementation? Have a feeling that if this could be done correctly it could nicely be fitted into microservices.

Jean-Jacques Dubray
Jun 28 2018 12:37
1/ Theoretically only actions can call APIs, so there are two cases, either there is no reason to not send an email, then you can proceed directly and report the result to the model with a proposal, or your action proposes to send an email, in which case the model will evaluate whether the email can be sent in which case the state should change such that the next-action-predicate will trigger the sendEmail action. If sending the email is synchronous with respect to the state of the system, it's ok to take a short cut and do it in the model, as long as you can be garanteed that no other action will be processed in the mean time.
2/ Actions can propose to any number of models, model and actions are entirely decoupled, I have expressed before that 3rd parties could propose to the model with an auth token .
3/ Logically an action cannot depend on another action, this maybe what you observe, but only the model and NAP should correlate/orchestrate the execution of the second action. Now for code reuse, one can functionally decompose an action into two functions which proposal could be added or even manipulated but logically the flow Action -> Mutation -> Action cannot be tempered with, only optimized.
4/ SAM is reactive, you never communicate "back", only forward. Action -> Model -> State Representation -> NAP -> Action ...
The model can of course reject a proposal and if a 3rd party agent is interested in the result of the action, it should query the state representation which should give a hint as to what happened (accept/reject).
5/ Sorry I don't understand your question. I am not sure if you have seen the component model I created and I use all the time. Logic is organized in "components" which mount into the SAM implementation. Components contain actions, acceptors and reactors. They could also contain NAPs. Is that what you are talking about? In theory the model is the "next-state-function" that's why the present method triggers all the acceptors.
With respect to your last point, it really depends what you are building (Front-End?) or something more state machine like. I am not claiming that SAM will lead to less code, but easier to reason about and more maintainable code. If you want to share your repo, I'd be happy to take a look.
Antanas A.
Jun 28 2018 13:16
Hi, thank you @jdubray for your detailed response.
I'm trying to design/prototype a concept for backend programming. My domain is actually almost enterprise automation - line of business apps. What I'm trying to do is to move out from general crud base designs where are two concepts: Entity --> DataSource --> GUI Component, and GUI Component -> RPC Manager -> Command.
Antanas A.
Jun 28 2018 13:49
What if we could somehow create a reactive "view"/materialize functions like f(ModelA.changes[], ModelB.changes[]) ->view[id, name] instead of Entity bound DataSources, and Command could be replaced into SAM style: Action --proposes changes to model--> Model (model emits change events).
For a 5. point I mean who will be responsible for certain action orchestration as in SAM Action itself does nothing only generates stateless proposals in these Actions I cannot implement any "action logging" into database, I cannot implement these into Models either because some actions need to hit multiple models to be accomplished ("committed"). So I'm speculating that there must be higher level who orchestrates specific "Business Action". I think your "Components" could be that I don't know.
Actually It's only for back-end, no direct View considered (only "view" as materialization functions).
Jean-Jacques Dubray
Jun 28 2018 18:15
@antanas-arvasevicius SAM is only useful for the "application state" which also includes a headless application, it does not make any assumptions. Persisted state is irrelevant to SAM, SAM only sees proposals, model and state representation what you do in between (call and API) display the state representation or publish it to a channel has no impact on SAM. SAM helps you manage the application state. Of course this means that SAM can be used to manage the (eventual) consistency of your back-end, but it is solely focused on "application state".
Otherwise I am not sure I fully understand what you are trying to do.