These are chat archives for jdubray/sam

22nd
Nov 2017
Jean-Jacques Dubray
@jdubray
Nov 22 2017 12:26
@dfkaye_twitter that proves one more time that actions are a good place to make back-end calls. However, I prefer calling Commands from the Model and Queries from the actions. This would avoid (more exactly manage better) a discrepency between the back-end accepting (or rejecting) the mutation and the model doing the opposite. It seems more logical to me that a command is called once the state has mutated.
I have explained before that logically, that command API call is a next-action but from a user experience perspective, it is a synchronous next-action, so it's ok to drive it from the model, rather than the next-action-predicate.
It's not fundamentally wrong to call a command from the action, you just need to understand that the model must accept the result of that command (or do some cleanup operation).
thanks for sharing
Janne Siera
@jannesiera
Nov 22 2017 16:31
For me, the problem with calling commands from the model is that it has the possibility to completely freeze up your application (as the model operates synchronously).
Paolo Furini
@pfurini
Nov 22 2017 16:50
there should never be something "synchronous" anymore in any UI stack, and it's anyway impossible to achieve in the browser by nature.. so I can't get what do you mean by "synchronous" in this discussion..
Radosavljevic Slobodan
@radosavljevic
Nov 22 2017 18:08

@jdubray

If you have a single system of record (aka a monolith), I have a great API design for you! it's call SQL (no literally executing a SQL statement, but close enough).

could you explain this a bit more?

Also, what do you think about https://firebase.google.com/docs/firestore/ with regards to SAM pattern?
Victor Noël
@victornoel
Nov 22 2017 18:15
@radosavljevic I think it is because we were discussing graphql like APIs to query data from a backed: often people bother with complex solution while SQL is actually a perfect API (or you can use a subset of it depending on your needs) to query data from a remote system
Radosavljevic Slobodan
@radosavljevic
Nov 22 2017 18:17
Got it, thanks!
Jean-Jacques Dubray
@jdubray
Nov 22 2017 18:44
@jannesiera @pfurini it really depends, when I do a bank transaction or order something, I want a synchronous confirmation that the transaction went through. It would be bad to get control back and later see a "transaction failed" message. I expressed preference, SAM accommodates of course every model: Action, Model or NAP.
@radosavljevic yes, this was in the context of GraphQL. We have gone overboard with contracts & REST. B2B needs contracts, but not the internals of an app.
I get the minimum structure possible (when I am in control of both ends) and let SQL do the heavy lifting with column name matching my JSON conventions.
"Static" people don't get the power of dynamic/extensible data structures
david kaye
@dfkaye_twitter
Nov 22 2017 18:54
@jdubray ~ thanks for the mention ~ Gleb, who wrote the vuex impl, is posting some detail about it next week.
@jdubray thanks also for this => "prefer calling Commands from the Model and Queries from the actions" ~ should go on the twitter timeline soon...
Paolo Furini
@pfurini
Nov 22 2017 19:29

"Static" people don't get the power of dynamic/extensible data structures

haha, I like to be called "static", but pls keep in mind that static+extensible is possible though with several typed-first languages

but all-in-all I prefer correctness over freedom, primarily BC I don't like useless tests just to fill the "holes" leaved by dynamic freedom (let me see if I have all my props with correct names here.. oh well, I misspelled a couple, let's fix it! :P )
Victor Noël
@victornoel
Nov 22 2017 19:32

I get the minimum structure possible (when I am in control of both ends) and let SQL do the heavy lifting with column name matching my JSON conventions.

@jdubray so you just have one endpoint on the backend where you post a query-like datastructure that is then transformed to sql, something like that? I would really love to completely get rid of any transport problematic and call something on the front that results on whatever happening so that something is called on the backed. I really don't need to bother with all the REST/json wiring... something like the RMI of modern frontend/backend world :)

so much time lost doing that work for no advantage at all
Jean-Jacques Dubray
@jdubray
Nov 22 2017 21:10
@victornoel no I have a number of them but I try to make them as polymorphic as I can, I have a simple mapping from json to SQL for insert/update (very naive but works so well).
I just can't see myself updating the whole chain between View Component and RDBMS table each time I need to add a new property, this has zero value has you mentioned.
Jean-Jacques Dubray
@jdubray
Nov 22 2017 23:00
@dfkaye_twitter you are welcome! It's up for debate, it works well for me and it seems to match UX from expedia, amazon, bigbanks...