Gestion des utilisateurs/sessions entre Sencha Touch et Rails (backend)

Question

Je suis en train de programmer une application mobile dans Sencha Touch avec le backend Rails. J'ai découvert que je séparais les deux de plus en plus à mesure que je m'enfonçais dans Sencha: où je suis essentiellement au point où Rails fonctionne uniquement comme stockage de modèle (base de données) et Sencha tire tout ce dont il a besoin via JSON - reproduisant une grande partie de la logique déjà présente dans les rails.

Ma question, est ce que vous conseillez quand il s'agit de déléguer des fonctions à chaque application? J'ai implémenté REST dans mon application Sencha afin de pouvoir communiquer sur l'utilisateur et les données associées et de les stocker dans le même format.

Est-ce la bonne solution pour la gestion de session utilisateur? Dois-je donner plus de puissance aux rails? IE: où puis-je stocker la session? Puis-je le faire sur le serveur? Dois-je le faire en tant que gestion de stockage de session? Stockage local? Je ne sais pas.

J'apprécierais n'importe quel conseil. Merci.

Answer 1

Ce n'est pas exactement une réponse spécifique à votre question, mais je voudrais juste ajouter que je pense que vous êtes sur la bonne voie, et je ne serais pas inquiet que vous ayez outrepassé la ligne architecturale, pour ainsi dire.

Le Web va de l'un des documents rendus (où le serveur faisait absolument tout et le navigateur était essentiellement bête) à un où le navigateur et le serveur sont des pairs plus symétriques - et vos défis deviennent plus autour de deux à part entière Les applications MVC en synchronisation! Il est possible que nous voyions un monde dans lequel les serveurs deviendraient passablement stupides par rapport à la richesse des applications du côté client: je pense que ce n'est que le cycle suivant du pendule client lourd/client léger qui a été pendant des décennies ;-))

Mais pour le mobile, ce n'est pas seulement un problème informatique arbitraire - l'appareil mobile peut facilement avoir une couverture réseau partielle ou sporadique, et donc le test ultime de la conception de votre application est de travailler si l'utilisateur peut continuer à travailler sur l'application lorsque l'appareil est hors ligne - conduit dans un tunnel, par exemple - puis resynchroniser une fois que le réseau est à nouveau disponible. Un client riche et réactif est vraiment la seule solution.

Dans ce scénario, stocker la session richement dans le navigateur semble être une étape raisonnable. En fait, il est plus facile de synchroniser l'état de la session entre un client et un serveur qu'avec d'autres types de données (qui peuvent être manipulés simultanément par plusieurs clients).