Начало обсуждения здесь: Платформа CUBA как альтернатива 1С решил вынести в отдельную тему
Видеоролик: http://www.youtube.com/watch?v=UcBGQGqwUro&list=PLiVLBB_TTj5njgxk5E_EjwxzCGM4XyKlQ&index=1

Изнутри реактивность устроена предельно просто.
На стороне 1С работает так:
* В той же локальной сети или в большом интернете (в зависимости от задачи) запущена служба на NodeJS с интерфейсами websocket и http
* В 1С добавлен определяемый тип ИнтеграцияОбъект, в котором перечислены документы, справочники и т.д., которые должны распространяться реактивно
* Для объектов этого типа определены подписки на события при записи и при удалении. Внутри подписок делается http-запрос на Node-сервер. В моём окружении, сериализация и передача изменений типичного объекта занимает 1-2 миллисекунды
Всё. 1С-ная часть работы закончилась и состояла она в том, чтобы проинформировать сервер интеграции об изменении или удалении неких объектов.

Сервер интеграции можно рассматривать, как внешний план обмена. Отличия от 1С-ного:
* Нет узлов обмена и нет отдельной регистрации для каждого клиента. Запись изменений на 1000 узлах работала бы крайне неэффективно
* Есть два списка: изменённые и удаленные, ключ: Зона (для поддержки разделённых баз fresh) + Имя типа + GUID ссылки
* Для каждой записи есть timestamp с точностью до миллисекунды. При регистрации, учитывается возможный сдвиг времени между серверами

Теперь, клиенты:
* У них есть своя браузерная база данных, в которой хранятся кешируемые перечисления, справочники и при необходимости некоторые документы
* При старте устанавливают websocket соединение с сервером интеграции
* Протокол websocket устроен так, что и клиент и сервер узнают об обрывах связи и восстанавливают соединение автоматически. Клиентское приложение может подписаться на события сетевых ошибок и ошибок в сообщениях и дополнительно их обработать
* При старте вычисляется сдвиг времени между клиентом и сервером интеграции и клиент получает изменения всех кешируемых объектов, которые произошли со времени последнего сеанса. При первом старте это может потребовать значительного времени, но на реальных базах моих клиентов (5-7 тыс. элементов номенклатуры), начальная синхронизация занимала не более 5-10 секунд, файл начального образа около 10Mb
* Движок данных metadata.js подписывается на события websocket (там могут быть сообщения, адресованные не только движку данных) и добавляет-изменяет-удаляет объекты в соответствии с содержимым сообщений
* Запись изменений со стороны лёгкого клиента по умолчанию выполняется прямо в 1С, но есть работающее приложение с отложенной записью. Если будет интерес, расскажу про него отдельно.

Описание реактивности закончилась, но остался вопрос визуализации изменений объектов в формах. Работает это так:
* В отличие от 1С, в metadata.js для каждой ссылки существует только один экземпляр объекта данных. Если открыть в двух окнах одинаковый элемент одного и того же справочника и начать редактировать, изменения синхронно отразятся в двух окнах, т.к. формы будут смотреть на один и тот же объект в памяти браузера
* Для системы не важно, изменён объект в форме или неким кодом. Формы объектов подписываются на события изменения своих объектов и перерисовывают себя в случае изменений. При изменениях объекта неким кодом, беспокоиться о визуализации не нужно. Система об этом позаботится
* В текущей редакции, в формах списков и выбора, слушатели изменений не реализованы. Сделать совсем просто. 10-30 строчек кода. Но у задачи низкий приоритет

(0) "Новые" проходят как "измененные"?

(3) Да

" запущена служба на NodeJS с интерфейсами websocket и http "
- что это такое и кто эту фигню запускает?

т.е. если пользователь правит документ(справочник), а в этот момент его правит и записывает другой - вуаля, первый получает данные второго и теряет свои?

(5) node.js это такой интерпретатор javascript чтобы не в броузере выполнять а в ОСи

а с интерфейсами это вместо апача (веб сервера) пашет js код и вебсервисы поддерживает

(6) думаю это настройками разруливается, можно блокировку делать

(6) кто первый встал того и тапки... битва крема от загара с битвокремя для загара!

(6) Это называется оптимистическая блокировка
https://ru.wikipedia.org/wiki/Блокировка_(СУБД)

(0) т.е. вы изобрели "meteor для 1С"?

Закладка

Чтобы не заводить отдельную ветку:

Возможно ли сделать и каким простейшим образом "metadata.js для 1С 7.7"?

(13)+ понятно что на код в формах забиваем (поначалу), только проведение документов остается

но чтобы формочки с контролами не рисовать а сами строились по базе
и можно было дописать куда то поведение контролов/код (пусть ручками но транслитерировать)

(13) Да, но в одиночку мне не справиться. Контрибьюторов жду на https://github.com/oknosoft/metadata.js/issues
13+ уже реализовано для DataObj

(11) Концепция metadata.js сильно отличается от meteor. Даже не знаю, что в них похожего.
У нас предлагаются 1С-подобные классы метаданных и данных - регистры, документы и справочники. Метеор просто транслирует модель (объект js) на форму и базу данных.
У нас SQL на клиенте и на сервере, meteor предлагает nosql-подход.

ага инфу по формам можно через formex получить... потом с метаданными соединить

да можно выходит, но все равно свою ВК специальную делать придется для нормальной скорости работы

(10) (8) В общем случае, когда разрешено оффлайн-редактирование, блокировку наложить не получится.
Нужно решать задачу распределенной консистентной репликации:
http://www.duct-tape-architect.ru/?p=982
https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type

(18) так РИБ же? правами и местами разруливать с датой последнего записавшего чти тапки

(19) Тогда, скорее, не "кто первый встал", а "кто последний записал", но важно помнить про оффлайн.
Кто-то на льдине поправил данные в своей реплике сегодня, а связь у него появится только завтра.

(20) дык так и написал "с датой последнего записавшего"

а насчет полярников так и полярный лис с ними

(18) (20) Это подходит далеко не для всех бизнес процессов.

(16) То, что вы перечисли, - просто особенности реализации. Ключевой момент - фоновая синхронизация локального и серверного хранилищ данных, при котором слой UI работает исключительно с локальным хранилищем.

(3) дошел до 3-го видео...
есть пара замечаний / вопросов.

1. сравнивается производительность веб-клиента и продукта. но сравнение не кажется объективным .
Не буду защищать 1С - управляемые формы сами по себе не очень производительные, а через веб-клиент они ещё медленнее работают. Но это не повод проводить сравнения так как хочется и делать после этого далеко идущие выводы.. Теперь сами замечания:
1.1. сравнивается "реальная" форма 1С-ки - с "кодом" и "красивостями" и "автосгенеренная форма продукта, без кода

1.2 у Управляемого приложения есть особенность - первое открытие любой формы всегда довольно медленное - происходит инициализация многих вещей и сопутствующее кеширование.
В этот момент идет большой объём данных и делается много "лишних" серверных вызовов.
Все последующие открытия новых экземпляров данного типа объекта происходят намного быстрее, Есть оптимизация по передаваемым данным, нет "лишних" (не предусмотренных прикладным разработчиком) серверных вызовов и т.д.

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

Так вот на видео мы видим сравнения времени именно первого открытия формы...

1.3 Недостатком динамического списка упр.формы и достоинством продукта указано то, что 1С-кий дин.список работает только с "видимой" областью данных и только в процессе перемещения по списку "подкачивает" новые данные, делая серверные вызовы...

Для "реактивного" продукта указано, что весь список будет "закеширован" на клиенете...
А что будет, если там несколько миллионов элементов? Они тоже все "закешируются"? А памяти на клиенте хватит? А сколько будет открываться такой список?

Вообще-то динамическая подкачка данных списка это вообще-то не 1С-кая придумка. И придумано это было как раз для нормальной работы на "тонких" клиентах. Может я чего не понял?

P.S. ну и в качестве завершающего штриха - в 8.3.7 сделали новый механизм визуализации формы, который делает меньше серверных вызовов и больше расчетов отдает на клиент...  см. http://v8.1c.ru/o7/201505layout/index.htm

(24) Обвинения довольно серьезные, но посудите сами: какой мне смысл использовать дешевые инсинуации, которые так легко опровергнуть?
По пунктам:
1. Трафик тонкого и web-клиентов почти не отличается - можете сами убедиться, посмотрев на пакеты 1С-ки через wireshark или tcpdump.
Для тонкого используется внутренний http-сервер 1С:Enterprise (тот самый, который в 8.4 разрешили использовать вместо apache для внешних публикаций)

2. Для иллюстрации выбран web, а не тонкий клиент для того, чтобы любой сомневающийся мог повторить эксперимент на своём оборудовании со своими данными.
Трафик web-клиента анализировать проще и удобнее

3. Лёгкий клиент не конкурирует со стандартным 1С-ным. Вообще не конкурирует. Он для другого.
В аннотации к проекту https://github.com/oknosoft/metadata.js внятно написано, что если некая задача решается традиционной платформой, не надо тратить время на освоение metadata.js.
Использовать лёгкий имеет смысл в случаях:
* Если надо обеспечить работу при плохой связи (у нас экономия трафика в 20 раз)
* Если требуется автономная работа
* Если в задаче интенсивные вычисления на клиенте (например, графический векторный редактор)
* Если нужны нестандартные элементы интерфейса
Еще, в аннотации написано: "чудес на бывает. ускорение достигнуто за счет отказа от избыточной для большинства проектов функциональности стандартного клиента 1С"

4. > сравнивается "реальная" форма 1С-ки и "автосгенеренная форма без кода
Как раз в этом примере, используется форма заказа с кодом, но это не важно, т.к. код наших форм живёт в appcache браузера и доступен молниеносно, а 1С-ка каждый раз загружает код модуля формы при открытии c сервера и выгружает при закрытии

5. >  есть особенность - первое открытие [...] довольно медленное
Естественно, при записи ролика пропущены первые 3-5 открытий формы.
Сравнивать первое открытие совсем глупо.
Задержка при первом открытии вызвана работой сервера, а не клиента.
Трафик при первом и при десятом открытии совершенно одинаковый, но при первом открытии, время тратится на заполнение кеша на сервере 1С

6. > А что будет, если там несколько миллионов элементов?
В Metadata есть три сценария кеширования: на клиенте, на промежуточном сервере NodeJS и "не кешировать". Последний по умолчанию используется для документов и для справочников, длиннее 30 тыс. элементов.
Реальные базы моих реальных клиентов редко содержат справочники длиннее 10 тыс. записей.
Документов, действительно, бывают миллионы, но там RLS, ограничивающий длину списка для конкретного дилера и пагинация (просмотр динсписков страницами по 30-60 записей)

7. > сделали новый механизм визуализации формы
К сожалению, реализованный в 8.3.7 механизм layout-ов, никак не сказался на трафике клиентских форм типовых конфигураций.
В октябре 2015 я собирался написать подробную статью с диаграммами про трафик клиентов 1С и отложил её написание из-за анонса новой математики 8.3.7.
Оказалось - зря отложил. Замеры, произведенные на последних релизах платформы показали лишь незначительное 3-5% улучшение ситуации.
95% по прежнему занимает служебный паразитный трафик и только 5% полезные данные - собственно сериализованный объект формы.

(23) Вынужден согласится. Сходство, действительно есть, но и отличия велики.
Фоновая синхронизация устроена по разному + у нас мощный движок данных на клиенте (sql + метаданные + подписки на события)

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

Не знаю, как будет в 1С, а у меня в Web-системе разрешение на редактирование поля запрашивалось с сервера, чтобы выдавать только одному из подключившихся, а после окончания изменения событие рассылается всем участникам редактирования.
Только вот пользователи, почему-то, сказали что всё это хрень, так как пока ты меняешь одно поле, кто-то успевает поменять другое.
Опять же остаётся вопрос с отменой изменений, так как в случае множественного редактирования просто нет сохранения или отмены, так как всё редактирование разбито на множество маленьких действий по изменению полей.

Что касается 1С, то они остались заложниками "пустого" сервера, когда все данные просто хранятся на клиенте и передаются на сервер только тогда, когда нужно выполнить какое-то действие там, причём, передаются все сразу.
Конечно, можно управлять данными, размещая их в клиентских объектах, которые не передаются на сервер, но это выглядит изобретением велосипеда.

И по поводу Web-сокет, могу сказать, что некоторые proxy с ним очень даже интересно работают, задерживая пакеты на какое-то время.

Хы... ничего не понимаю, но интересно :)

(27) > разрешение на редактирование поля запрашивалось с сервера
Мне хотелось, чтобы движок изначально ориентировался на автономную работу.
В вебдизайне сейчас модная фраза: mobile-first.
Типа, сначала рисуем под малое разрешение телефона и планшета, а потом довешиваем бантики для большого экрана.
Metadata проповедует подход offline-first. Программируем, чтобы работало без сервера, а если сервер доступен, добавляем ништяков.

(29) Если пишется Web-приложение, то "работает без сервера" - это не есть хорошо, так как непонятно, что делать, если пользователь его закрывает.

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

С точки зрения безопасности системы, мы предполагаем, что на пользовательской машине не должны хранится данные, к которым у пользователя нет доступа и доступ частично ограничен, значит, данные должны быть на сервере.
Также открытым остаётся вопрос разрешения изменений и их отслеживания в "автономном" режиме.
Вполне вероятна ситуация, когда в случае разрешения автономной работы мы будем иметь в различных частях системы различные данные, что неприемлемо и приводит к проблемам.

Опять же, гибкость системы должна требовать различных способов и сценарием синхронизации данных при восстановлении связи - какие-то объекты нужно обновить сразу, а какие-то оставить до необходимости.

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

Ну и второй пример - у нас есть морковь в упаковке 2 кг в количестве 100 упаковок - в базу ввели вместо 200 кг - 100 кг, забыв про то, что в упаковке 2 кг.
Вася и Петя увидели, что введено неправильно, только Вася исправил единицу, и написал, что шт. имеет коэффициент 2, а Петя исправил общее количество, то есть 100 на 200.
В итоге, мы получаем, что морковь в штуках (2кг штука) в количестве 200 штук. Для системы же всё выглядело красиво: Вася:ChangeUnit(кг=>шт), а Петя:ChangeQuantity(100=>200).

(30) Поддержка offline в ядре не означает, что методист и разработчик должны отключить голову.
Естественно, для каждого рабочего места должен существовать разумный сценарий и так же естественно, что некоторые рабочие места никак не сделать автономными.

(31) Сейчас ещё есть идея, которая называется "offline-proxy", то есть когда удалённый офис или группа операторов подключаются через кеширующую систему, которая накапливает данные изменений и держит в себе основные объекты базы, чтобы позволить что-то выполнять в Offline, когда нет связи, но в тоже время успевать работать в online-режиме, когда есть соединения.

Опять же, offline сильно упирается в вопросы безопасности, так как хранение данных отдельно от основной базы требует пересмотра модели угроз из-за возможности получения доступа к данным, хранящимся в памяти Proxy.

(31) Из начального описания не совсем понятно два момента, можете пояснить?

>>В той же локальной сети или в большом интернете (в зависимости от задачи) запущена служба на NodeJS с интерфейсами websocket и http

Что это за служба, что она делает? Это какая-то самописная служба?

>>Внутри подписок делается http-запрос на Node-сервер

Что за Node сервер, что он делает? Имеется ввиду сервер, на котором запущена служба на NodeJS

(33) > Что это за служба, что она делает
Как любой сетевой сервис, эта служба слушает tcp порты и отвечает на запросы клиентов.
Клиентом в данном случае, является сервер 1С-предприятия.
Про Node в сети много материалов, например https://ru.wikipedia.org/wiki/Node.js

(34) Частично понял, вот этот сервер интеграции, на котором запущена Node.js служба нужен для хранения актуальных данных? Т.е. 1с шлет запросы ему при изменении данных, он хранит актаульные данные? На нем стоит какая-то база данных или как? Клиенты взаимодействуют непосредственно с сервером интеграции через websocket?

(35) Да, примерно так. Для простоты можно считать, что это внешний план обмена.
Там есть своя база. По умолчанию используется postgres.
Для очень крупных проектов можно задействовать специализированные inmemory базы. Например, tarantool (на котором вся почта mail.ru крутится)

(30) (31) Коллеги, по-моему, вы пытаетесь решить CAP-теорему. Вроде как, пока это еще никому не удалось на практике.