@jdubray my another attempt using SAM to build webapp :relieved:
https://github.com/imnutz/dashboard
In this, I tried to split the webapp into folders and components.
May you take a look?
It looks great except for one thing, I would not put the CRUD operations (services) in the actions and call these actions from nap(). Logically this is truly what happens but IMHO, it is better when the model persists its values
There could be some race conditions that occur when you handle the persistence with nap()
@jdubray so from what you said, there should be some thing like this in the model:
model.fetchingData = function() {
callRestAPI({})
.then(function(response) {
- update model's data
- call State.render
})
}
model.updateContact = function() {
callRestAPI({})
.then(function(response) {
- update model's data
- call State.render
})
}
// same for create and delete
the rationale is that there is no point in rendering the view until the model has persisted and the persistence layer has also accepted the values of the model. If you could be guaranteed that whatever value has been accepted by the model will persist as is, then you could use actions in nap().
the other aspect to consider is concurrency. As soon as actions can be triggered and processed before the present model has completed, then you will run into concurrency issues. The SAFE middleware "blocks" the present method and serializes all action execution, in particular it would check for the "allowedActions" in the new State before processing an action waiting in the queue.
You have to always ask the concurrency question when you build such a system.
I don't see actions in server.js but I do see it in blog.js
Did you do npm install?
Let me check if I pushed the latest code
Looks like the latest code is available in the repo
let me try on my macbook
// server side
$.post( "http://localhost:5425/app/v1/present", data)
.done(function( representation ) {
$( "#representation" ).html( representation );
}
);
which line is the error?
Is the error on the server?
The HTML should be wired to the blog.js actions. If you look in blog.js it should look like this:
var actions = {} ;
actions.edit = function(data) {
data.lastEdited = {title: data.title, description: data.description, id: data.id } ;
present(data) ;
return false ;
} ;
actions.save = function(data) {
data.item = {title: data.title, description: data.description, id: data.id || null} ;
present(data) ;
return false ;
} ;
actions.delete = function(data) {
data = {deletedItemId: data.id} ;
present(data) ;
return false ;
} ;
actions.cancel = function(data) {
present(data) ;
return false ;
} ;
You can also run the sample without a server, you should uncomment the client code and comment the server code
sorry have to go
OK, I got it working. The problem was that I was using the wrong url in my browser. Instead of C://crud-blog/blog.html, I was using http://localhost:5425/app/v1/init
Thank you for all of your work!
@jdubray Hi JJ its me again, I am looking at the code of your website http://www.ebpml.org and I am trying to get an understanding of how SAM can be used in the "real world". Lets say for example, that I published the crud-blog example where a jquery HTTP request is made to the server. Is it safe to expose the server address and file structure to the client? How did you address security in your site?
In the http://www.ebpml.org/about page, I simply make a request to the feed.xml file so there is security (but that's server side)
On the Web there is only one security architecture for back-end APIs, either it is safe for anyone to call them (say like feed.xml) or you need users to login and either call the API with a valid session token from the browser or you need to call them safely from the server (say with APIKey)
You should never bring API credentials on the browser (say like API key), it is 100% unsafe.
I am a server side guy, I don't believe much in complex browser-based apps. I like the UX of SPA but I prefer when most of the SPA comes from the server rather than making AJAX calls from the browser.
That's why SAM is 100% isomorphic and I came up with it because I felt that the Front-End driving API signatures was the wrong thing to do.