Разрабатывать на metadata.js – нифига не просто. По крайней мере мне, закоренелому, или даже закостенелому 1Снику.
Среда разработки 1С, с одной стороны, просто шикарная, потому что позволяет не думать ни о чем, находящимся за пределами конфигуратора. С другой стороны, как ни прискорбно, эта же среда приучает к ограничениям – как в функциональности, так и в решаемых задачах.
Ты просто перестаешь задавать вопрос «а можно ли еще вот такую штуку сделать?», потому что знаешь ответ – «нет, нельзя так сделать, да и не надо оно, хрень это все». Ну и заказчикам начинаешь так же отвечать – тем, которые с богатой фантазией.
Но, тем не менее, пересесть на metadata.js вполне возможно. В процессе этой пересадки я, как 1Сник, постоянно делаю некоторые наблюдения и маленькие открытия. Не всемирного масштаба, а так, «для себя». Зная, что я не один такой, я стал записывать эти открытия, отличающие разработку на metadata.js от 1С. Возможно, они для кого-то окажутся полезными.
Изложу некоторые из них.
Метаданные «на лету»
Шикарно все-таки на metadata.js разрабатывать, потому что у тебя под рукой, в доступе, почти все - и прикладное решение, и платформа.
Взять те же вычисляемые свойства. Захотел, чтобы у справочника "Номенклатура" было свойство, вычисляемое на лету, с учетом контекста - на здоровье!
Пишешь код, свойство добавляется и вычисляется - хоть на старте, хоть при обращении к менеджеру справочника, хоть при обращении к элементу справочника. Там же его кешируешь, если хочешь, чтобы два раза не вычислять.
И все, свойство доступно их любого места! Хоть через точку, хоть запросом (спасибо, alasql). Видно в формах - и элемента, и списка.
Жаль, в 1С так нельзя пока.
Наряду с вычисляемыми свойствами, в metadata.js можно на лету корректировать метаданные.
Вот в 1С, например, все привыкли к работе с доп.свойствами. В УПП они хранились в регистре сведений, сейчас хранятся в табличной части объекта.
А в metadata.js их можно выпрямить - развернуть таб.часть свойств в реквизиты объекта. Причем, хранить в базе данных можно, как и раньше, в виде таб.части, а при получении объекта в ОЗУ - выпрямлять.
Ну и, соответственно, пользоваться доп.свойствами, как обычными реквизитами - показывать в формах, делать по ним отбор и сортировку, и т.д.
Можно вываливать в объект все доп.свойства, можно - определенный перечень, не важно. Можно даже сделать список выпрямляемых свойств зависимым от контекста. Можно делать вычисляемые доп.свойства, и т.д.
В итоге метаданные становятся невероятно гибкими. Они не возвышаются, как гранитный монумент, доступный только сложными способами избранным.
Производительность
Когда в 2015 и 2016 годах Евгений Маляров, автор metadata.js, рассказывал о возможностях платформы, была одна проблема - отсутствовали реальные внедрения и, соответственно, подтверждение его слов.
Главное, что было не доказанным - реальная способность системы, созданной на metadata.js, держать сотни и тысячи пользователей.
Сейчас, когда несколько крупных клиентов запустили систему в реальную эксплуатацию, уже появились фактические данные.
Пока можно привести две цифры - 400 и 700. Столько пользователей держит приложение «Заказ дилера», созданное на metadata.js, у двух наших клиентов.
Активных пользователей бывает и больше, т.к. многократный вход под одной учеткой вполне допустим.
Количество пользователей продолжает активно расти. Думаю, до конца этого года кто-то из клиентов перевалит за 1000 пользователей.
Табличные части
Прикольно в metadata.js работать с табличными частями, например - сворачивать их.
В 1С ведь как? При свертке перечисляем колонки, по которым надо сгруппировать, и колонки, по которым посчитать итог. Тут внимание - итогом может быть только сумма.
А в metadata.js итогом может быть целый ворох функций. Максимум, минимум, среднее и т.д.
А еще - внимание - можно подсунуть свою функцию, которая лежит где-то в стороне, и вычисляет агрегат по нужным вам правилам. Хоть медиану считайте.
Код функции свертки лежит в открытом виде, как и весь остальной код metadata.js. В платформе 1С, увы, пока такого нет.
Или вот еще. Попробуйте в 1С, имея строку табличной части, узнать ее метаданные, хотя бы названия колонок. Не получится. Нужна, как минимум, вся табличная часть, и то она даст только названия колонок.
А для получения метаданных придется таскать с собой объект или ссылку, которому принадлежит табличная часть, потому что у табличной части нет реквизита вроде «Владелец» или «Объект». Так же, как у строки таб.части нет реквизита типа "Табличная часть".
В metadata.js у строки есть владелец (owner) - таб.часть, и у таб.части есть owner - объект. Соответственно, можно, имея строку таб.части, не сходя с места добраться до объекта.
Просто приятные мелочи.
Offline
После 1С никак не могу привыкнуть к тому, что решения на metadata.js могут работать без связи с сервером. Даже вообще без Интернета.
Так получается благодаря разным способам кеширования. Например, номенклатура у нас с типом кеширования «ram». Это значит, что при первом старте приложения, подключенного к интернету, весь справочник номенклатуры грузится в ОЗУ, и сохраняется в базе данных браузера (кажется, она называется IndexedDB).
В следующий раз, если интернета нет, будет использован справочник из базы браузера. Можно оформлять документы, рисовать изделия - в общем, работать. Все, что нужно (в том числе цены) есть в локальной базе браузера.
Разумеется, пока нет интернета, оформленные заказы не попадут в центральную базу. Но, как только связь появится - например, полевой работник приедет в офис с ноутбуком или планшетом - и зайдет в приложение, данные сразу убегут в центральную базу. А у пользователя обновятся справочники, если в них были изменения.
Так работают, например, замерщики у наших клиентов. Они могут приехать к клиенту, и не просто измерить окна, но и нарисовать конечные изделия, посчитать спецификацию и сказать клиенту цену. Клиент сразу увидит на экране свои окна со всеми параметрами. Сможет вместе с замерщиком отрегулировать параметры - например, выбрать другую фурнитуру, или систему профилей подешевле - и увидеть результат.
Что важно: вся работа ведется в том же браузерном приложении, что и в офисе. Это не отдельная, мобильная версия, которую надо устанавливать и запускать обмен.
В моем 1Сном мозге такое пока не уложилось. Должен ведь быть сервер! И с ним должна быть связь! А если связи нет, то должна быть распределенная база данных, со всем вытекающим геморроем с обменами!
Настоящее единство
Опять же, после 1С в голове не укладывается новый класс задач, которые решает metadata.js - единая информационная система для компании и ее клиентов.
В практике работы с 1С УПП и Документооборота часто возникал вопрос: как запустить в систему, например, поставщиков? Приходилось делать на сайте, который на битриксе, личные кабинеты поставщиков.
Но личный кабинет на сайте - это не информационная система. Что там может поставщик? Какие-нибудь статичные файлы посмотреть, вроде потребностей, или договор согласовать, или протокол цен. Как говорится, пост-лайк-коммент.
Запустить его в свою систему нельзя по объективным причинам. Во-первых, доп. лицензии нужны. Во-вторых, если это УПП, то только через RDP, а это зло. Если даже это не УПП, а что-то с тонким или веб-клиентом, то все равно нужны лицензии.
Аналогичные трудности - если нужно, например, организовать единое информационное пространство для работы с заказчиком над совместным проектом.
Веб-приложений для управления проектами полно, но там все достаточно скучно - задачи, этапы, графики. Если хочется видеть что-то про взаиморасчеты, затраты, отгрузки, закупки и т.д. - придется городить огород. А это не всегда возможно - сервис управления проектами не даст себя портить программистам.
В итоге, такие системы если и появлялись, то были монструозными, с убийственными обменами данных и страшными затратами на администрирование.
А в metadata.js работа компании с клиентами и поставщиками в одном приложении - один из базовых принципов. Например, в решении «Заказ дилера» такой подход заложен прямо в названии.
Дилер (например, оконного завода) работает прямо в приложении, предоставленном заводом. Рисует окошки, используя технологические справочники, настроенные заводом. Получает расчет цен, установленный правилами завода. Видит свои взаиморасчеты с заводом. Отправляет своих замерщиков к клиентам, и те рисуют изделия в приложении завода.
Но это все мелочи. Важно (лично мне) выйти на новый уровень мышления, перестать думать об индивидуальных системах для конкретных компаний, и даже о типовых решениях, подходящих разным компаниям.
Надо научиться мыслить об одном решении для нескольких компаний одновременно. Не о сайтах, порталах или сетях обмена данными, а именно о едином информационном пространстве.
Так ведь весь мир покорить можно, если мышление перестроить. Пока, правда, плохо получается - слишком я закостенелый стал за годы работы.
СУБД
Мозг никак не привыкнет к работе с СУБД, которая практикуется в metadata.js.
Вот в 1С есть четкая граница: моя база, и чужие базы. Неважно, файловая или серверная база. Всегда есть ИБ, с которой можно общаться напрямую, и есть посторонние ИБ, с которыми можно общаться обменами, веб-сервисами или COM-соединением.
А в metadata.js, по сути, у тебя есть все и ничего - CouchDB. Типовое приложение работает тремя базами - ram, doc и remote. Где они лежат - вообще не важно. Одна может быть в локальной сети, вторая в Германии, третья в Москве. А со стороны приложения работа с ними совершенно идентична.
И нет никакой разницы, «моя» это база или «чужая» - интерфейс взаимодействия абсолютно одинаков. Я долго тупил на этом месте, потому что парадигма 1С прочно в голове засела. Все пытался узнать - а как вон с той базой мне соединяться? Какой там интерфейс, API? На что получал ответ - точно такой же. Если знаешь строку подключения, логин и пароль, то все операции со всеми базами выполняются одинаково.
Причем, есть несколько способов работы с ними. Рекомендуемый - через конструкции metadata.js. Например, хочешь выбрать документы определенного типа за период - обращаешься к соответствующему методу менеджера документов, ровно как в 1С. А дальше работает адаптер (PouchDB), который сходит в нужные базы CouchDB и притащит документы.
Другой способ - обращаться не через менеджер, а прям к базе запрос делать, через API CouchDB. Тут уже полная свобода.
Недавно у одного из клиентов, например, вытащили версии в отдельную базу. Ну как вытащили - просто репликацию настроили, и они сами стали сливаться, автоматически. В результате данные лежат в одних базах, а версии - в других. А потом один отчет, который по истории версий, все это собрал в кучу.
Сервис планирования, например, вообще стоит отдельно от основного приложения и у него нет «своей» базы. К нему обращается, например, заказ, и говорит - запланируй меня, в смысле производство. Сервис планирования сам сходит в нужные базы, возьмет данные (загрузку, мощности и т.д.) и выдаст результат в заказ.
Резюме
Понятно, что многие из вас – асы в веб-разработке, и написанное в публикации покажется наивным лепетом зеленого гимназиста. Я на звание веб-разработчика не претендую, равно как и на должность программиста на metadata.js. Не дорос еще.
Но многие, опять же, такие же, как я – почти чистые 1Сники. Я это точно знаю по опыту общения с ребятами, которые пытаются чего-то сделать на metadata.js.
Metadata.js стоит посередине между 1С и веб. Это – ее преимущество. Но это же – и ее беда. 1Сник не понимает веб, вебщик не понимает 1С. Потому сообщество разработчиков, пока еще, очень невелико – лишь десятки человек.
Данная публикация, как и мои «записки 1Сника», из которых она собрана – это взгляд на платформу metadata.js со стороны паттернов разработки 1С. Вообще, я не планировал эти материалы публиковать в виде статьи – просто записывал, чтобы не забыть, в facebook. Но вчера ребята попросили написать что-нибудь про metadata.js, вот я и исполняю.
Если подобные материалы вам интересны, я это учту. Ну и, соответственно, учту, если не интересны.
