In tutorials I've seen, when data changes on the client (maybe a TODO is added to the TODOs list) the client side model (and often UI) is updated first, then the server is called to persist that change. This puzzles me as there's the potential for error and failure (in which case you would have to notify the client and revert the change on the data model/UI).
Is it best to update the server first, then the client data model/UI or the other way around?
It's generally easiest to update the server first and then update the UI when the server responds with success.
This allows you to avoid handling cases where you updated the UI but the server update fails.
But it also makes your users wait for the server request to complete before seeing the results in UI.
Which way is best depends on your priorities, and on your application. For some applications it's also easy (just a little more work) to handle cases where server updates fail by updating the UI again. For some applications this becomes quite complex and can lead users to make incorrect decisions with frustrating or even dangerous consequences.
For example, show a doctor on his/her iPad that a medication has been ordered before the server confirms it, and you just might have harmed the patient, if the medication was actually not ordered, due to a brief network outage or other problem, the doctor may put down the iPad and walk away thinking the job is done.
In this case, either a delay or a pending status seems in order in the UI. Although a pending status sounds nicer, sometimes e.g. for safety reasons, a delay and a formal confirmation is better. That's a question of user experience design.
Securities trading, another area from my experience, is one where you ought not to tell a user something is done when it's not. Traders are used to watching complex ui's with status indicators and they mostly hate delay. However, in this case the required status indicators and dynamic UI can add a lot more scope vs. simply waiting for the server to confirm.
Overall the answer is not a technical one. It's really user experience that should drive in this case, along with your budget for development.
loading..orwait for Authentication..) with a screen-lock until confirmation of both sides is true. If done correctly the order becomes almost irrelevant. the potential for errors exists on both ways .