User/Session Management between Sencha Touch and Rails (backend)

Question

I'm programming a mobile application in Sencha Touch with the backend being Rails. I've found that I've been separating the two more and more as I get deeper into Sencha: where Im basically at the point where Rails only functions as my model storage (database) and Sencha pulls in everything it needs via JSON - reproducing much of the logic already present in rails.

My question, is what do you advise when it comes to delegating functions to each application? I've implemented REST in my Sencha app so it can communicate User, and associated data and store it in the same format.

Is this the right way to go for User Session management? Should I give more power back to rails? IE : where do I store the session? Can I do it on the server? Should I do it as session storage management? Local storage? I just dont know.

I'd appreciate any advice. Thanks.

Answer 1

This is not exactly a specific answer to your question, but I would just like to add that I do think you're on the right lines, and I wouldn't be worried that you've overstepped the architectural line, so to speak.

The web is going from one of rendered documents (where the server did absolutely everything and the browser was essentially dumb) to one where the browser and server are more symmetric peers - and your challenges become more around keeping two fully-fledged MVC apps in sync!

(Arguably, we might see a world where servers become fairly dumb, relative to the richness of the applications on the client side. I guess this is just the next cycle of the thick-client/thin-client pendulum that's been swinging for decades ;-) )

But for mobile, this is not just some arbitrary computer science problem - the mobile device might easily have partial or sporadic network coverage, and so the ultimate test of your application design is to work out whether the user can continue to work on the app when the device is offline - driven into a tunnel, for example - and then re-sync back once the network is available again. A rich, responsive client is really the only way to go.

In that scenario, storing the session richly in the browser seems like a reasonable step. In fact, it's easier to keep session state in sync between a single client and a server than it might for some other types of data record (that might be being manipulated by multiple clients simultaneously).