Автономное веб-приложение

Question

Я думаю о создании автономного веб-приложения.

Архитектура, которую я рассматриваю, выглядит следующим образом:
Веб-сервер (удаленный) <-> Веб-сервер / кэш (локальный) <-> Браузер / Призма

Преимущества, которые я вижу для этой модели:

• Развертывание происходит через Интернет, со всеми преимуществами этого подхода
• Offline поддержки
• Синхронизация пользовательского интерфейса (html/js) не является проблемой
• Синхронизация данных может быть в основном автоматизирована
  • пока я остаюсь в RESTful парадигме
  • Я могу сломать это по мере необходимости, но ручная синхронизация в значительной степени останется хирургической
• Локальный веб-сервер запускается как служба; Я могу запустить произвольный код, включая синхронизацию данных за сценой
• У меня есть полный контроль над данными (местоположение, без ограничения размера, нет возможности удаления пользователя по незнанию)
• Призма с расширением может позволить держать JavaScript закрытым исходным кодом

Есть мысли по поводу этой архитектуры? Почему я должен / не должен использовать это? Я особенно ищу истории успеха / ужасов.

Длинная версия

Заметки:

• Пользователи не очень разбираются в компьютерах. Например, даже поверхностное объяснение того, как работает Gears, совершенно исключено.
• Я буду нести ответственность, если данные будут потеряны, даже если это действительно ошибка пользователя (если не считать удаления случайных каталогов на своем компьютере)
• Я могу потребовать, чтобы пользователи установили что-то на свою машину. Это не должно быть на 100% веб-и / или работать в песочнице

Общие решения этой проблемы не чувствуют себя адекватными. Вот краткий анализ каждого. Шестерни /HTML5:

• нет контроля над данными, могут быть удалены пользователями без предупреждения
• нет контроля над местоположением данных (не одинаково для всех браузеров и платформ)
• пользователям необходимо открыть приложение в браузере для синхронизации; нет автоматической синхронизации за кадром
• разные браузеры обрабатываются по-разному, нет единого представления данных на одном компьютере
• ограниченное дисковое пространство доступно
• синхронизация полностью ручная, хранилище на основе SQL делает это болезненным (было бы менее сложно, если бы таблицы SQL полностью реплицировались, но в моем случае это не так). Это очень сложная проблема.
• мой код будет почти полностью открытым исходным кодом (HTML / JS)

Adobe AIR:

• некоторые из вышеперечисленных
• нет серверной части включает (!)
• может работать в фоновом режиме, но не без окон
• ручная синхронизация
• веб-кеширование кажется сложным
• как-то похоже на кучу, у меня были проблемы с установкой на некоторых машинах

Мои требования:

• Сетевой (обязательно). По ряду причин, например, для обмена данными между пользователями.
• Оффлайн (обязательно). Приложение должно быть полностью работоспособным в автономном режиме (с некоторыми редкими исключениями).
• Быстрое развитие (обязательно). Я - единственный разработчик, идущий против игроков с гораздо большими бизнес-ресурсами.
• Закрытый источник (приятно иметь). Да, я понимаю модель с открытым исходным кодом. Однако на данный момент я не хочу, чтобы конкуренты копировали меня слишком легко. Опять же, у них больше ресурсов, чтобы они могли взять мою тяжелую работу и сделать ее лучше за меньшее время, чем я сам. Очевидно, что они все еще могут скопировать меня, разрабатывающего свой собственный код - это нормально.

Answer 1

Ужасы от CRM-продукта:

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

Answer 2

Часть о запуске локального веб-сервера как службы выглядит неразумно. Помимо того, что вы привязаны к определенным операционным средам, доступным на клиенте, вы также налагаете дополнительное бремя управления сервером на конечного пользователя. Кроме того, локальный веб-сервер не может быть развернут в веб-модели.

В общем, я не слишком взволнован перспективой настоящего "локального веб-сервера". В этом есть определенная предвзятость, без сомнения, поскольку я предложил встроенные веб-серверы, которые работают внутри веб-браузера, как часть моего предложения по бесперебойному автономному веб-хранилищу. См. BITSY 0.5.0 ( http://www.oracle.com/technology/tech/feeds/spec/bitsy.html).

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

Answer 3

Единственный способ сделать это надежно - предложить что-то вроде "проверить и заблокировать" на уровне записи. Когда пользователь собирается удаленно, он должен проверить записи, с которыми он хочет работать. Эта проверка скопировала данные в локальную БД и предотвращает изменение записи в центральной БД во время извлечения записи.

Когда роуминговый пользователь повторно подключается и проверяет свои заблокированные записи, данные в нем обновляются в центральной БД и разблокируются.