Html5 локальное хранилище данных и синхронизация между устройствами

Question

Я создаю полнофункциональное веб-приложение.Естественно, вы можете сохранить, когда находитесь в автономном режиме в локальном хранилище данных.Я хочу иметь возможность синхронизации между устройствами, чтобы люди могли работать на одной машине, сохранять, а затем переходить на другую машину и загружать свои вещи.

Вопросы:

1)плохая идея хранить JSON на сервере?Зачем разбирать json на сервере на объекты модели, когда он просто будет передан (другим) клиентам в качестве json?

2) Я не уверен, хочу ли я попробовать NoSqlтехнология для этого.Я не сломал JSON, пока единственные отношения в БД будут от учетной записи пользователя до их записей.Помимо пользовательских данных, модель предметной области будет String, то есть json.Совет приветствуется.

Теоретически, в будущем я мог бы захотеть выполнить некоторую обработку на сервере или установить более сложные отношения.Другими словами, сейчас я просто хотел бы сохранить JSON, но в будущем мне может понадобиться более традиционная реляционная система.Не помешает ли этому подход NoSQL?

3) Есть ли какие-либо проблемы с безопасностью?Инъекция JS например?Теоретически для этого варианта использования пользователь не может ничего вводить, по крайней мере, прямо сейчас.

Заранее спасибо.

РЕДАКТИРОВАТЬ - Спасибо за ответы.Я выбрал ответ, который я сделал, потому что он подробно описал преимущества и недостатки NoSql.

Answer 1

JSON на СЕРВЕРЕ

Совсем неплохо хранить JSON на сервере, особенно если вы используете решение noSQL, такое как MongoDB или CouchDB.Оба используют JSON как свой собственный формат (MongoDB на самом деле использует BSON, но он довольно похож).

noSQL Подход: Предполагается, что CouchDB используется в качестве механизма хранения

• Запечено врепликация и обработка параллелизма
• Очень простой API отдыха, общение с базой данных с помощью HTTP.
• Хранение данных в формате JSON изначально, а не в двоичных объектах или текстовых полях
• Мощный просмотр /Механизм запросов, который позволит вам продолжать увеличивать сложность ваших документов
• Автономный режим.Вы можете напрямую общаться с CouchDb с помощью javascript и продолжать работу всего приложения на клиенте, если Интернет недоступен.

Безопасность

Сделатьуверен, что вы анализируете документы JSON с помощью браузера JSON.parse или безопасной библиотеки Javascript (json2.js).

Заключение

Я думаю, что причинаЯ бы посоветовал перейти с noSQL здесь, в частности, с CouchDB, который будет обрабатывать все сложные вещи для вас.Репликация будет проще простого.Вам не придется беспокоиться о параллелизме и т. Д.

Тем не менее, я не знаю, какое приложение вы создаете.Я не знаю, какими будут ваши отношения с клиентами и как легко будет заставить их установить CouchDB на своих машинах.

Links

1. CouchDB @ Apache
2. CouchOne
3. CouchDB полное руководство
4. MongoDB

Обновление:

После просмотра приложения я не думаю, что CouchDB будет хорошим вариантом на стороне клиента, поскольку вам не нужно, чтобы людиустановить движок базы данных, чтобы играть в содуку.Тем не менее, я все еще думаю, что это будет отличный вариант на стороне сервера.Если вы хотите синхронизировать экземпляр CouchDb на сервере с клиентом, вы можете использовать что-то вроде BrowserCouch , которое представляет собой реализацию CouchDB на JavaScript для локального хранилища.

Answer 2

1. Если большая часть вашей обработки будет выполняться на стороне клиента с использованием JavaScript, я не вижу никаких проблем при хранении JSON непосредственно на сервере.

2. Если вы просто хотите поиграть с новыми технологиями, вы можете попробовать что-то другое, но для большинства приложений нет реальной причины отходить от традиционных баз данных, а SQL упрощает жизнь.

3. Вы в безопасности, если вы используете стандартную функцию JSON.parse для анализа строк JSON - некоторые браузеры (например, Firefox 3.5 и выше) уже имеют собственную версию, а Крокфорд json2.js может копировать эту функцию в других.

Answer 3

Просто прочитайте ваш пост, и я должен сказать, что мне очень нравится ваш подход, он предвещает, как многие веб-приложения, вероятно, будут работать в будущем, как с элементом локального хранилища (для отключенного состояния), так и с онлайн-хранилищем (мастер).база данных - для сохранения всех записей клиентов в одном месте и синхронизации с другими клиентскими устройствами).

Вот мои ответы:

1) Хранение JSON на сервере: I 'Я не уверен, что я буду хранить объекты как JSON, это возможно сделать, если ваше приложение довольно простое, однако это затруднит усилия по использованию данных (например, запуск отчетов и отправка их по электронной почте в пакетном задании).Я бы предпочел использовать JSON для самой передачи информации и базу данных SQL для ее хранения.

2) Подход NoSQL: Я думаю, что вы ответили на свой вопрос.Мой предпочтительный подход заключается в настройке базы данных SQL сейчас (если дополнительный ресурс не является проблемой), таким образом вы сэкономите немного усилий, настроив уровень доступа к данным для NoSQL, поскольку вам, вероятно, придется удалить его.в будущем.SQLite - хороший выбор, если вам не нужна полнофункциональная СУБД.

Если написание схемы слишком хлопотно и вы все еще хотите сохранить JSON на сервере, то вы можете хэшировать систему управления объектами JSON с одной таблицей и несколько разборов на стороне сервера, чтобы получить соответствующие записи.,Это будет проще и потребует меньше прав, чем сохранение / удаление файлов.

3) Безопасность: Вы упомянули, что в данный момент нет ввода пользователя:

"для этого варианта использования пользователь не может ничего вводить"

Однако в начале вопроса вы также упомянули, что пользователь может

"работать на одной машине, сохранить, затем перейти на другую машину и загрузить их содержимое "

Если это так, то ваше приложение будет хранить пользовательские данные, не имеет значения, что вы не предоставилихороший графический интерфейс для них, вам придется беспокоиться о безопасности с нескольких точек зрения, а JSON.parse или подобные инструменты решают только половину проблемы (на стороне клиента).

По сути, вам также придется проверить содержимое вашего запроса POST на сервере, чтобы определить, являются ли отправляемые данные действительными и реалистичными.Целостность объекта JSON (или любых данных, которые вы связываете для сохранения) необходимо будет проверить на сервере (используя php или другой подобный язык) ПЕРЕД сохранением в вашем хранилище данных, это потому, что кто-то может легко обойти ваш уровень javascript«безопасность» и вмешиваться в POST-запрос, даже если вы не намеревались их сделать, и тогда ваше приложение все равно будет отправлять злой ввод клиенту.

Если у вас на стороне сервера все убрано, тогдаJSON.parse становится немного устаревшим с точки зрения предотвращения инъекций JS.Тем не менее, неплохо иметь дополнительный слой, особенно если вы используете API удаленного веб-сайта для получения некоторых своих данных.

Надеюсь, это полезно для вас.