NYCPHP Meetup

[David Krings]

On 5/20/2014 4:24 AM, Michael B Allen wrote:
> As for other's suggestions about storing state on the client by what
> is ultimately manipulating the DOM with JavaScript, I can see how that
> could be used to create sophisticated UI elements. But I don't think I
> would ever put any state on the client that I couldn't accept losing
> at any moment (e.g. as I type this, gmail is periodically saving this
> message with async requests). Even storing stuff in a cookie seems
> dubious for a shopping cart. I think I will just commit each change to
> the DB so that user's can be confident that what they see is actually
> in the DB.


Hi!

I understand your concern, but you are working on a true client/server based 
application (browser apps are nothing else). So until anything resides on the 
server you don't have it. Async requests are one option, but what does the 
server code do with half of an order? And what do you do when the user clicks 
the 'Buy stuff' button sending the final form submission? That step is as 
likely to fail or succeed as any other. And once you get the final submission 
you need to have the server clean up any of the partial saves, although that 
effort could be minimized by simply flagging the order record as incomplete 
until the final submission comes in.
In the current state of technology I'd be more worried about the connection 
between client and server than the client or server themselves. Unless the 
user uses Firefox 29 the chance of losing stuff through crashes are slim to none.
I'd focus on getting the cart in place storing items locally and then sending 
the order in one swoosh over. Yes, that risks that the user may lose stuff 
halfway through when their end does not behave, but I found that to be a 
rather rare occasion. In return you will reduce the client/server traffic and 
hits against the database which both are quite costly. Also keep in mind that 
there is still a substantial number of folks on dialup or at least slow 
connections, but that depends on the target audience for your store.
As far as the DOM manipulation with JS, I see that commonly done in enterprise 
grade browser based apps just for the sake of distributing computing tasks. 
Five or ten years ago that may have been different, but by now clients are 
running on generally beefy boxes and are very fast in executing JS. And now 
you even have access to local storage. So why not make use of that and bother 
the server with only that stuff that truly matters in the end? That is the 
only way to scale, I mean aside from buying bigger servers with bigger pipes.

Just my 2€

David