I’m working on learning Ember by building a Rails/Ember application. I’ve had success with basic CRUD, and am starting to do analysis on the existing models in the system.
Is there any definitive rule on when logic should be performed by the server? If I have an inventory system that knows I have 5 of apples, and I have Checkout resource that indicate 3 are checked out, should the server provide the number of available apples when the model is loaded from the store, or is it better to load all the checkout models for apples and do the math client-side?
To my way of thinking it is all about the interface that you construct between client and server, and the implied contract and semantics that you represent to your users.
If it is convenient to implement logic locally then do so. There is typically a lot of performance that can be gained by this approach. And the state changes will appear to happen much faster. The “perceived” performance of your application will be better. But having a clear phase of committing changes back to your server is really about making sure you are doing right thing by end users expectations. The server is really the final arbiter of persisted state. For example, if your app makes a bunch of changes and then you present your user with a “save” then that is where you want to make sure you don’t surprise your users. Follow a pattern that is the least “surprising” and avoid situations where the user can’t find their info missing next time they visit the site.
I think the server is definitely where the final validation logic should reside before a final save to a database. This is where you can ask important design questions: is the user allowed to make this change? was this data mutable? read only? Does this change affect other users of the system? Those kinds of questions are important to deal with on the server. And if you have data and state changes that are shared between lots of different users then server is really the only place where you can answer these questions.
If a change to data made by one user is going to materially impact the impact the interactions of other users of the system, then you definitely want to make sure you are fetching the data frequently enough to conform to users expectations.
In a well designed system it is all about passing messages. For high level theory on some of this stuff you may want to read up on
I was more wondering if it is an ember antipattern to do logic on the server. I think it will be ok, and so far as meeting user expectations may be better, because it will force me to check on the server’s data more often, which may be affected by other users.
Most definitely not. Like @eccegordo said, the server has the final say. Client side logic should be thought of as convenience for the end user, not the law. The server should definitely contain logic to prevent users from spoofing false/malicious information.