Comments 14
А как Logus подружить с Service Workers?
Так как SW и служат для решения проблемы оффлайна, то логично всю логику Логуса исполнять там.
Так как SW и служат для решения проблемы оффлайна, то логично всю логику Логуса исполнять там.
Есть две разные задачи в поддержке оффлайна:
1. Кеширование HTML/JS/CSS-файлов приложение.
2. Организация работы с данными приложения без связи.
Эти задачи очень разные. Сервис-воркеры созданы для решения только первой задачи. Для решения второй задачи они не созданы.
Можно конечно перенести работу с логом в сервис-воркер, но это только усложнит код и уменьшит поддержку браузеров.
1. Кеширование HTML/JS/CSS-файлов приложение.
2. Организация работы с данными приложения без связи.
Эти задачи очень разные. Сервис-воркеры созданы для решения только первой задачи. Для решения второй задачи они не созданы.
Можно конечно перенести работу с логом в сервис-воркер, но это только усложнит код и уменьшит поддержку браузеров.
Если запросы к API идут по HTTP(s), то в принципе можно кешировать их на уровне Service Workers.
Когда связи нет, то выполнять запросы отложенно а клиенту возращать, например, что все ок.
Как бонус — это прозрачно для приложения. Из минусов — не получится перехватить WebSockets, ну и меньше поддержка браузером
Когда связи нет, то выполнять запросы отложенно а клиенту возращать, например, что все ок.
Как бонус — это прозрачно для приложения. Из минусов — не получится перехватить WebSockets, ну и меньше поддержка браузером
Да, так можно — но смысла мало. На клиенте всё равно больше кода для AJAX-запроса. Непонятно как понятно и прозрачно интегрировать получение таких же событий с сервера.
Плюс запуск и обновление сервис-воркера — хитрая задача. В спеке есть не очень очевидные моменты (например, с адресом воркер-файла).
Ну и преимуществ не будет никаких (в фоне воркер сокет не может держать).
Плюс запуск и обновление сервис-воркера — хитрая задача. В спеке есть не очень очевидные моменты (например, с адресом воркер-файла).
Ну и преимуществ не будет никаких (в фоне воркер сокет не может держать).
Каким образом гарантируется доставка данных от клиента серверу и наоборот? Как бороться с повторной отправкой данных в случае, если сломались клиент, сервер или интернет между ними? Через идемпотентные операции?
Я правильно понимаю, что Logux работает на WebSocket?
Это не создаёт проблем? Старые брауззеры, прокси?
Это не создаёт проблем? Старые брауззеры, прокси?
Прокси большая проблема для обычных веб-сокетов, но если перейти на сокеты поверх SSL (WSS), то большинство проблем решится. Мы стараемся везде в интерфейсе форсить WSS.
Сокеты — IE 10+, это нормально. Логакс ориентирован на SPA, а для IE <10 SPA создают редко.
Но, сам Логакс не ограничивает как передаются данные. Просто стандартный драйвер использует веб-сокеты. Можно заменить на AJAX + keep-alive. Или внедрить протокол Логакса внутрь какого-то нибудь корпоративного XML.
Сокеты — IE 10+, это нормально. Логакс ориентирован на SPA, а для IE <10 SPA создают редко.
Но, сам Логакс не ограничивает как передаются данные. Просто стандартный драйвер использует веб-сокеты. Можно заменить на AJAX + keep-alive. Или внедрить протокол Логакса внутрь какого-то нибудь корпоративного XML.
Может задам тупой вопрос, но почему бы в БД и на клиенте не хранить дату последнего изменения каждого поля?
При синхронизации сверять даты и обновлять поля с датой меньше присланной. Побеждает тот, кто последний менял данные.
При синхронизации сверять даты и обновлять поля с датой меньше присланной. Побеждает тот, кто последний менял данные.
Правильно мыслите — собственно в CRDT примерно так и сделано.
Но разделение по полям не идеальный способ. Есть типы данных, которые так мержить не получится — например, счётчики или длинный текст (где хочется параллельное редактирование). Для этого и придумали более абстрактный способ — хранить действие.
Но сборщик мусора в логе и так удаляет все старые значения поля (если это CRDT Map). Так что хранится очень близко к вашей идей. Просто чуть универсальнее для других типов.
Но разделение по полям не идеальный способ. Есть типы данных, которые так мержить не получится — например, счётчики или длинный текст (где хочется параллельное редактирование). Для этого и придумали более абстрактный способ — хранить действие.
Но сборщик мусора в логе и так удаляет все старые значения поля (если это CRDT Map). Так что хранится очень близко к вашей идей. Просто чуть универсальнее для других типов.
Кстати, как хранить конечные данные на сервере решаете вы. Так что даты полей можете не хранить, а использовать обычное хранение. Или хранить именно с датами, чтобы мерж работал, даже если клиента не было онлайн более месяца.
В общем Логакс никак не ограничивает БД на сервер. Свой лог он хранит в отдельном файле и этот лог лишь дополнительная вещь. Его можно смело чистить через неделю.
В общем Логакс никак не ограничивает БД на сервер. Свой лог он хранит в отдельном файле и этот лог лишь дополнительная вещь. Его можно смело чистить через неделю.
Не нашёл ничегошеньки про SSR (Server Side Rendering). Изоморфный logux-client, или на сервере юзать redux?
Любое веб-приложение выиграет от оптимистичного интерфейса, так как пользователи всегда любят быстрые интерфейсы.
Совсем не любое. Если у меня в голове есть алгоритм действий и я его пошагово выполняю в приложении, а потом в середине процесса оказывается, что все не так или что-то не так, я готов убить авторов различных идей «optimistic updates». Хотелось бы более сильных аргументов, кроме «все любят скорость в ущерб консистентности». Может быть это верно только для развлекательных приложений, иначе зачем нам CAP-теорема, закрываем вопрос?
Sign up to leave a comment.
Logux: Connection lost, data synchronized – интервью с Андреем Ситником (Злые Марсиане)