These are chat archives for jdubray/sam

7th
Mar 2016
Jean-Jacques Dubray
@jdubray
Mar 07 2016 04:41
A bit of fun tonight, I reimplemented the Blog Sample from Raja with SAM to show how easy it is to achieve Isomorphic JavaScript
https://twitter.com/rajaraodv/status/706571926865518592
Here is the code
All you have to do is switch the client and the server, otherwise, it is the same code running on the client or the server.
function present(data) {
    // client side
    model.present(data) ;

    // server side
    // $.post( "http://localhost:5425/app/v1/present", data) 
    //     .done(function( representation ) {
    //                  $( "#representation" ).html( representation );
    //         }        
    //     );
}

function init() {
    // client side
    view.display(view.init(model)) ;

    // server side
    // $.get( "http://localhost:5425/app/v1/init", function( data ) {
    //              $( "#representation" ).html( data );
    //     }        
    // );
}
Michael Solovyov
@msolovyov
Mar 07 2016 05:25
seems like in raja's code he's doing crud actions with a server, so shouldn't the sam example have it in the model crud calls to a server?
Jean-Jacques Dubray
@jdubray
Mar 07 2016 06:30
I chose to just implement the model.present method as the interface between the client and the server (it's a perfectly valid way to do it)
In SAM the CRUD is behind the model
There is no CRUD between the client and the server, that is the whole point of SAM.
I could have also implemented the actions on the server (just lazy)
you can also choose which action remain on the client and which ones are implemented on the server
The sample also shows something I like quite a bit, though I am sure most people won't. The server takes an API requests and returns an HTML snippet.
Michael Solovyov
@msolovyov
Mar 07 2016 12:47
I guess my use case is just using the server as a db storage medium for the model
Jean-Jacques Dubray
@jdubray
Mar 07 2016 16:02
It really depends. For instance Actions help implement Role-Based Access Control rules (when you need them, then actions should be implemented on the server).
In general it's not a good idea to have the browser make "CRUD" calls, it's like giving a database connection to a client (hard to make sure the client knows what it is doing, that's a big security concern).
That's probably the main issue I have with React, it was clearly designed for Facebook to run as many CPU cycle on the client as opposed to the server (for obvious cost reasons), but Facebook's data model is so specific that I am not sure the proposed architecture would fit many other use cases.
Have you tried isomorphic React? this is crazy.
Michael Solovyov
@msolovyov
Mar 07 2016 16:37
The way I will likely be using sam is opening up a websocket in the model on the front end, to send and receive, so that the view is updated live for all clients
Jean-Jacques Dubray
@jdubray
Mar 07 2016 16:42
Yes, SAM should work great for that, not sure if you have seem I have some WebSocket sample here:
https://bitbucket.org/jdubray/star-javascript/src/5806219be6d37bfed9fbba9122e0d8f6de584140/src/samples/node-apicall/?at=default
weepy
@weepy
Mar 07 2016 20:49
hey sam seems really interesting
In your github page you mention MobX -- but I'm not clear whether you advocate it as a good match for Sam or not ?
Jean-Jacques Dubray
@jdubray
Mar 07 2016 23:38
Thank you! My inclination is that Observables are generally not a great way to "wire" the pattern. The reason is that they make it inflexible to check if the action is allowed or not. The whole premise behind SAM is that your code must be deliberate about possible actions, in a given "State".
Happy to answer any question you have.
Jean-Jacques Dubray
@jdubray
Mar 07 2016 23:54
InfoQ is going to do a follow up post on SAM. I'd be happy to include 3-5 quotes from the community (good or bad as long as it is fair). Anyone would like to share a quote?