Подход игродела к созданию современных веб приложений

[Ashur_451]

Немного напомнило мне как в Learning How To Learn на курсере рассказывали про свойства нейронных паттернов. Один нейронный паттерн созданный при обучении одной вещи может быть использован частично или полностью в выполнении другой. Я на пример, всегда видел много аналогий в музыкальной теории и математике.

PS: Ссылка на курс, очень советую, ru.coursera.org/learn/learning-how-to-learn

[Zav]

Оригинальное управление ресурсами — возьму на вооружение, спасибо.

Касательно размеров хранилища — можно ведь запросить ещё.
Ну и в зависимости от продукта это можно ещё решить, например, плагином для браузера.
В том же хроме сайт можно вообще вынести, что бы открывался отдельным ярлыком без интерфейса самого браузера.

Касательно метеора — это не ультимативное решение, мне приходилось ранее решать проблемы работы приложений оффлайн. Текущий мой проект реализован на метеоре, и в ближайший месяц-два обязательно напишу цикл статей по разработке. Но что хочу сказать так это то, что везде надо подходить с умом :-)
Один пример приведу. Метеор круто копит внешние запросы, когда нет подключения, и отсылает их пачкой когда оное появляется.
Пол года назад, на этапе закрытого бета теста, мы словили очень крутой само-ддос, когда в датацентре решили перезагрузить наш сервер и он сам подняться не смог, а с утра, те кто не выключал игру, начали слать тысячи запросов, которое накопились за это время.
Очевидным решением был контроль исходящей очереди.
Это я к тому, что с какого-то момента всё равно подобные детали приходится контролировать в полу-автоматическом режиме и любой отдельно взятый инструмент необходимо уметь грамотно применять.

_{Уважаемый модератор — если приведенные ссылки «не приемлимы» — просто удалите их, не надо мне в очередной раз блокировать аккаунт, пожалуйста.}

[ilya_radinsky]

Согласен. Собственно, вся эта возня с кэшами возникла для исключения потенциального ддос'а — livesearch.

[amakhrov]

> А что если сделать VRC (Virtual REST Call)!? Тогда ведь можно поддержать работу веб приложения вообще при отсутствии интернет соединения!…

Вы только что описали работу ServiceWorker :) developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API

[ilya_radinsky]

Очень похоже, до неприличия ;) Не знал, спасибо.

[Proteck]

Было бы интересно увидеть результаты, какое ускорение получилось по каждому из улучшений

[ilya_radinsky]

Честно говоря, таких цифр нет — просто боролись за приемлемую скорость загрузки и уменьшение трафика.

[atc]

Очень похоже на клиентские data layer пакеты, вроде ember-data, orbit.js, fortune.js, особенно в части построения графа зависимостей, оптимизации запросов, кешировании.
Автор, вы их не рассматривали?

[ilya_radinsky]

Нет, не рассматривали. У нас были жесткие рамки: бэкенд — MS (ASP.Net, MS SQL, Azure и тп), фронтенд — ангуляр (с поддержкой планшетов и мобильников).

[atc]

С ангуляром эти библиотеки вполне совместимы, к бекенду так же требований практически не предъявляют за исключением протокола (чаще всего используется jsonapi.org), но и это вполне преодолимо, так как в большинстве data layer возможно написание адаптеров под свое api.

[ilya_radinsky]

Деталей особо не помню, но мы в свое время ничего подходящего для себя не нашли. Те же веб сокеты мы смогли использовать только в рамках SignalR и Azure IoT Hub.

[yokotoka]

Кстати, насчёт оффлайновой работы POS-терминалов есть ещё вот такая интересная штука:
https://www.youtube.com/watch?v=uyZKWyciSXY

https://github.com/gritzko/swarm

[asvechkar]

Для больших объемов можно использовать IndexedDB. В одном из проектов мы загружали туда часть КЛАДР (~300т. записей). Нормально справляется. Причем кроме веб клиента сделали на Cordova обертку для мобильных устройств.