Stock de données local Html5 et synchronisation entre les périphériques

Question

Je crée une application Web complète. Naturellement, vous pouvez enregistrer lorsque vous êtes en mode "hors ligne" dans le magasin de données local. Je veux être en mesure de synchroniser entre les appareils, afin que les gens puissent travailler sur une machine, enregistrer, puis monter sur une autre machine et charger leurs affaires.

Les questions sont les suivantes:

1) Est-ce une mauvaise idée de stocker JSON sur le serveur? Pourquoi analyser json sur le serveur dans des objets de modèle quand il va juste être renvoyé au (autre) client (s) comme json?

2) Je ne sais pas si je voudrais essayer une technologie NoSQL pour cela. Je ne casse pas le json, pour l'instant les seules relations dans la base de données seraient d'un compte d'utilisateur à leurs entrées. Autre que les données utilisateur, le modèle de domaine serait une chaîne, qui est le json. Conseils bienvenus.

En théorie, à l'avenir, je pourrais vouloir faire un peu de traitement sur le serveur ou mettre en place des relations plus compliquées. En d'autres termes, en ce moment je sauverais le json, mais à l'avenir je pourrais vouloir un système relationnel plus traditionnel. Est-ce que l'approche NoSQL pourrait faire obstacle à cela?

3) Y a-t-il des problèmes de sécurité? Injection JS par exemple? En théorie, pour ce cas d'utilisation, l'utilisateur n'a rien à saisir, du moins pour l'instant.

Merci à l'avance.

EDIT - Merci pour les réponses. J'ai choisi la réponse que j'ai faite parce qu'elle est allée dans les détails sur les avantages et les inconvénients de NoSql.

Answer 1

JSON sur le serveur

Ce n'est pas une mauvaise idée du tout pour stocker JSON sur le serveur, surtout si vous allez avec une solution NoSQL comme MongoDB ou CouchDB. Les deux utilisent JSON comme format natif (MongoDB utilise BSON mais c'est assez similaire).

NoSQL Approche: En supposant CouchDB comme moteur de stockage

• cuit dans le traitement de la réplication et
• concurrency Très simple API Rest, parlez à la base de données avec HTTP.
• Stocke des données comme JSON natif et non dans blobs ou champs de texte
• moteur puissant View/requête qui vous permettra de continuer à développer la complexité de vos documents
• mode hors connexion. Vous pouvez parler à CouchDb directement à l'aide de javascript et faire en sorte que l'application entière continue à fonctionner sur le client si Internet n'est pas disponible.

sécurité

Assurez-vous que vous les documents de l'analyse syntaxique JSON avec les navigateurs JSON.parse ou une bibliothèque Javascript qui est sûr (json2.js).

Conclusion

Je pense que la raison pour laquelle je suggère d'aller avec NoSQL ici, CouchDB en particulier, est qu'il va gérer toutes les choses difficiles pour vous. La réplication va être un clin d'oeil à l'installation. Vous n'aurez pas à vous soucier de la concurrence, etc.

Cela dit, je ne sais pas quel type d'application vous construisez. Je ne sais pas quelle sera votre relation avec les clients et à quel point ce sera facile de les amener à mettre CouchDB sur leurs machines.

Liens

1. CouchDB @ Apache
2. CouchOne
3. CouchDB the definitive guide
4. MongoDB

Mise à jour:

Après avoir regardé l'application, je ne pense pas que CouchDB sera une bonne option côté client, car vous n'allez pas avoir besoin de gens pour installer un moteur de base de données pour jouer au soduku. Cela dit, je pense toujours que ce serait une excellente option côté serveur. Si vous voulez synchroniser l'instance CouchDb du serveur avec le client, vous pouvez utiliser quelque chose comme BrowserCouch qui est une implémentation JavaScript de CouchDB pour le stockage local.

Answer 2

1. Si la plupart de votre traitement va être fait sur le côté client en utilisant JavaScript, je ne vois aucun problème dans le stockage JSON directement sur le serveur. Si vous voulez simplement jouer avec les nouvelles technologies, vous pouvez essayer quelque chose de différent, mais pour la plupart des applications, il n'y a pas vraiment de raison de s'écarter des bases de données traditionnelles et SQL simplifie la vie.

2. Vous êtes en sécurité aussi longtemps que vous utilisez la fonction standard JSON.parse pour analyser les chaînes JSON - certains navigateurs (Firefox 3.5 et au-dessus, par exemple) ont déjà une version native, alors que json2.js de Crockford peut reproduire cette fonctionnalité dans d'autres.

Answer 3

Je viens de lire votre message et je dois dire que je tout à fait comme votre approche, il préfigure la façon dont beaucoup d'applications web fonctionnera probablement à l'avenir, à la fois un élément de stockage local (pour l'état déconnecté) et en ligne storage (la base de données master - pour enregistrer tous les enregistrements clients en un seul endroit et synchroniser avec d'autres périphériques clients).

Voici mes réponses:

1) Stockage sur le serveur JSON: Je ne suis pas sûr que je stocker les objets que JSON, il est possible de le faire si votre application est assez simple, mais cette volonté entraver les efforts pour utiliser les données (en exécutant des rapports et en les envoyant par courrier électronique sur un travail par lots, par exemple). Je préférerais utiliser JSON pour TRANSFÉRER les informations moi-même et une base de données SQL pour le stocker.

2) Approche NoSQL: Je pense que vous avez répondu à votre propre question.Mon approche préférée serait d'installer une base de données SQL maintenant (si la ressource supplémentaire n'est pas un problème), vous économiserez ainsi un peu de travail en configurant la couche d'accès aux données pour NoSQL puisque vous devrez probablement l'enlever A l'avenir. SQLite est un bon choix si vous ne voulez pas un SGBDR complet. Si l'écriture d'un schéma est trop compliquée et que vous voulez toujours enregistrer JSON sur le serveur, vous pouvez hacher un système de gestion d'objets JSON avec une seule table et analyser le serveur pour retourner les enregistrements pertinents. Cela sera plus facile et nécessitera moins d'autorisations que la sauvegarde/suppression de fichiers.

3) Sécurité: Vous avez dit qu'il n'y a pas d'entrée utilisateur au moment:

"pour ce cas d'utilisation, l'utilisateur ne obtenir d'entrer quoi que ce soit"

Toutefois, au début de la question, vous avez également mentionné que l'utilisateur peut

"travailler sur une machine, enregistrer, puis obtenir sur une autre machine et charger leurs trucs »

Si tel est le cas, votre demande sera le stockage des données de l'utilisateur, il n'a pas d'importance que vous ne avez fourni une interface graphique agréable pour eux de le faire, vous allez avoir à se soucier de la sécurité de plus d'un point de vue et JSON.parse ou des outils similaires ne résolvent que la moitié du problème (côté client).

Fondamentalement, vous devrez également vérifier le contenu de votre demande POST sur le serveur pour déterminer si les données envoyées sont valides et réalistes. L'intégrité de l'objet JSON (ou des données que vous voulez sauvegarder) devra être validée sur le serveur (en utilisant php ou un autre langage similaire) AVANT d'enregistrer dans votre magasin de données, car quelqu'un peut facilement contourner votre couche javascript "sécurité" et altérez la requête POST même si vous ne l'aviez pas l'intention de le faire et que votre application enverra quand même la mauvaise entrée sur le client.

Si vous avez le côté serveur des choses rangé, puis JSON.parse devient un peu obsolète en termes de prévention de l'injection JS. Il n'est pas mauvais d'avoir la couche supplémentaire, surtout si vous comptez sur des API de sites Web distants pour obtenir certaines de vos données.

Espérons que cela est utile pour vous.