#clojure #synchronization #reactive-programming #clojurescript
#clojure #синхронизация #реактивное программирование #clojurescript
Вопрос:
Существует ли идиоматический способ выполнить реактивную синхронизацию данных между браузером и сервером с помощью Clojure и Clojurescript? Каковы плюсы и минусы одного метода по сравнению с другим?
Использовав Meteor.js в прошлом такого рода реактивная синхронизация базы данных была весьма предпочтительнее ручного написания маршрутов и опроса обновлений. Система pub / sub позволяет веб-разработчикам писать меньше шаблонного кода для перемещения данных. Clojure кажется, что это было бы естественным для такой техники. Я не смог определить, является ли это решаемой проблемой в экосистеме clj / cljs.
Комментарии:
1. Поэтому не одобряет такие широкие вопросы. Однако это не означает, что ваш вопрос неправильный.
2. Хм, я не хотел, чтобы вопрос был широким. Я спрашиваю о конкретной технике, использующей определенный набор инструментов. Поиск информации по теме мало что дал, поэтому я надеялся получить здесь информацию от экспертов, которая была бы полезна другим, таким как я, ищущим информацию о синхронизации данных с использованием clj / cljs.
3. Видите ли, у каждого человека есть свой специфический набор инструментов. И это делает ответ на этот вопрос вопросом мнения.
4. Я не совсем понимаю, что вы имеете в виду. Да, у людей могут быть мнения о том, каков наилучший способ решения этой проблемы, но ИМО, который не зависит от вопроса о возможных решениях (или если они вообще существуют). Несмотря на это, я отредактировал свой вопрос в попытке прояснить.
5. Я не использовал Meteor, но вы, очевидно, могли бы использовать XHR и WebSockets для асинхронной передачи данных от серверной части к интерфейсу, а затем Reagent или другие библиотеки на основе React во интерфейсе для рендеринга
Ответ №1:
Короткий ответ — «нет».
Я использовал Meteor.js в рабочей среде, а также искал то же самое при входе в CLJ (Ы). Самые близкие, о которых я знаю, это:
- Datsync
- Использует Datomic и Datoms в качестве протокола синхронизации
- Кажется, альфа
- Fulcro
- Имеет поддержку для оптимистичных обновлений, но не прямую синхронизацию данных, как у Meteor с Minimongo, ближе к методам Meteor (т. Е. клиентская и серверная реализации одного и того же вызова)
- Готов к производству, широко используется
Почему не был написан Meteor-killer в CLJ (Ах)?
- Это сложно сделать (вообще, эффективно)
- Компания, стоящая за Meteor, за последнее десятилетие привлекла десятки миллионов долларов для работы в этом пространстве и до сих пор не решила всех проблем масштабируемости или семантических неровностей в дизайне синхронизации данных
- Хранилища данных, которые обычно используют пользователи Clojure (Datomic или relational), вероятно, делают синхронизацию данных еще более сложной и, безусловно, совершенно иной (это не был бы порт из реализации Meteor).
- Разработчики Clojure, как правило, предпочитают собирать систему в соответствии с потребностями конкретной проблемы / решения / требования, а не собирать решение вокруг определенной функции / фреймворка (например, документы Mongo, которые синхронизируют полный стек).
Однако люди все еще думают об этом, как внутри сообщества Clojure, так и за его пределами. Проверьте:
- Завершение (и их блог, сравнивающий с Meteor.js, Firebase, RechinkDB)
- «Веб после завтра» (разработчиком DataScript)
- Реактивный журнал данных
Единственный значимый способ сравнить — рассмотреть их оба в вашем контексте. Я помню, что в то время отказ от Meteor’s magic казался значительным, но я не обнаружил, что хочу возвращаться. Я рассматриваю это как волшебный обмен на простоту и гибкость.