lsFusion - открытая платформа для разработки бизнес-приложений

Я правильно понимаю, что это 1С под лицензией LGPL v3?

С точки зрения целевого назначения - да. С точки зрения реализации - не совсем. Как минимум, в 1С многое построено на визуальном программировании, ORM, а в lsFusion - нет. Плюс в 1С очень плохо сделано ООП и модульность. Но вообще отличий достаточно много.

Там есть чатик
https://demo.lsfusion.org/hockeystats/

Да, это почему-то первое, что находят - там мистовцы повесились. Надо конечно грохнуть их творчество.

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

Склад - интереснее. Продаю белый. Выбираю покупателя, выбираю склад, выбираю товар, вываливается список всего товара вообще, а не только на складе. Туда бы остатки еще, фильтры эти куда-нибудь сохранять надо в набор, чтобы каждый раз не натыкивать, остатки надо проверять еще при вводе, а не после нажатия ОК.

Несколько раз нажимаю расходные накладные, открывается несколько вкладок, так не должно быть.
Ну так - хз, интересно, с учётом того, как там не много кода надо, может и замочите когда-нибудь 1сников.

Короче ui надо подковырять. Работать руками на этом будет очень не удобно. А если соберётесь и запилите какие-нибудь шаблоны, чтобы шлёп шлёп и сразу в продакшон, на этом начнут делать интернет магазины, то очень даже может быть оно взлетит.

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

Так это самый простенький пример. Есть более сложное ERP : https://demo.lsfusion.org/erp

Но вообще обычно при ручном вводе используется подбор как здесь : https://habr.com/ru/company/lsfusion/blog/464487/

Несколько раз открытие одной формы настраивается для пользователя. В некоторых случаях это бывает удобно и полезно. 1сников мочить никто не собирается - просто предлагается бесплатная альтернатива. А вообще больше будет идти позиционирование на мировой рынок.

Пока планируется, что встроенный ui делается исключительно для сотрудников (B2B). Отличие сотрудников в том, что там не важен дизайн, а важна продуктивность. Для B2C обычно делается React, который общается через JSON-API с сервером (для этого тоже есть своя инфраструктура).

по ссылкам глянул код и что-то про КОБОЛ вспомнилось :-)

а так наверное неплохо. Остаётся сделать хороший гайд и «коробочное решение» где ткнул мышом и всё развернулось.

Глянул, выглядит круто. Честно, я ничего не понял, потому что видимо не спец в тематике, но всё довольно наворочено. Производит впечатление чего-то что долго разрабатывалось и многое может.

Что касается 1С - оно с хорошей техподдержкой, кучей литературы и тому подобным. Взял и работай. А тут как и что? Вот есть Windows - все его знают много что поддерживает и куча литературы. А есть Linux, он то может и лучше, но на десктопах слаб хоть и многообещающий и открыт. Вот так же 1С и lsfusion.

Не спец но любопытно. Что такое бизнес-приложения? Бухгалтерия или что-то еще?

Тут больше за основу брался SQL. Только так как там по сути функциональная СУБД внутр. С коробочным решением все сложнее - платформа все-таки относительно универсальная. Нельзя же сделать «коробочное решение» для Python. Но сейчас да, есть вариант сделать открытую базовую простую ERP, которую уже кто хочет, сможет себе дорабатывать как захочет.

Ну не забывайте, что в 1С документация вообще-то платная :) Хоть и с 7-дневным trial. И с 1С прямо так взял и работай тоже не очень прокатывает. Обычно приходится отталкиваться от типовых конфигураций, а там, если открыть какое-нибудь Управление торговлей, вот так просто не начнешь работать. Там просто десятиэтажные вложенные процедуры, к которым страшно прикасаться. И куча литературы сильно не поможет.

Здесь больше ориентация на начинающих программистов, которые ни 1С, ни Java ничего другого не знают. И порог вхождения в lsFusion - ниже. У нас на платформе пишут бывшие менеджеры по продажам, системные администраторы и прочие не программисты.

Бизнес-приложение - это можно сказать практически любое приложение по вводу и обработке информации, которым пользуются сотрудники компании. Любой, так называемый, бэк-офис (кроме BI, естественно)

Визуальное программирование не используется как класс

это не альтернатива 1С

Визуальный билдер как https://www.codejig.com/en/block-based-coding/ планируется?

Нет. Пока не планируется. У визуального программирования есть свои недостатки. Например, тяжело решать merge conflict'ы, поддерживать gitflow, делать copy/paste с заменами, организовывать модульность и т.д. Поэтому для нас это явно не является основным приоритетом. Но кое-что в обратную сторону мы визуализируем. Вот, например, как устроена IDE : https://habr.com/ru/company/lsfusion/blog/465573/

Не очень понятно как вообще можно не идти на сервак ? Нельзя же со чтением списка матчей тянуть все команды.

Один раз идешь на сервак и хватит.

А если их 100 млн ?

Обычно их там не 100 млн, а намного меньше. Если много, ну да, куда денешься.

Для B2C обычно делается React, который общается через JSON-API с сервером (для этого тоже есть своя инфраструктура).

Если кто-то может делать json-api и react, он и бек может себе сваять. Надо совсем для домохозяек что-то, ну и чтобы можно было что-то приделать с боку.

Один раз идешь на сервак и хватит.

А как гарантировать, что данные с того момента не изменились ? По сути, Вы предлагаете делать стандартный кэш, как в ORM. Там есть ряд известных проблем. Что, если мне нужно сделать запрос к базе, где будут те же данные, но более свежие ? Как решить несогласованность тогда ? Понятно, что есть методики, но они все сводятся к тому, что с базы данных просто все расчеты перекинуть на серверы приложений. И в чем проблема того, что будут считываться 50 записей при каждом открытии формы ? Это миллисекунда, которая даже к диску не обратится, а считает из shared buffers. Там и так есть кэши диска, кэши СУБД, кэши сервера приложения тут избыточны. И не забываем, что тут B2B решение и пользователей будет, например, 5000, а не 5млн, как в B2C. И запросы у них будут другие. В общем смысла в этом мало.

Обычно их там не 100 млн, а намного меньше. Если много, ну да, куда денешься.

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

Если кто-то может делать json-api и react, он и бек может себе сваять. Надо совсем для домохозяек что-то, ну и чтобы можно было что-то приделать с боку.

Вы только что из всех фронтенд разработчиков сделали full stack разработчиков. Не так просто бэк сваять. На B2C интерфейсах там в любом случае нужна тонкая настройка, а у нас интерфейсы для B2B пользователей (то есть сотрудников). В них интерфейс не столь важен. Кроме того, сейчас уже не 90е : операторов по набиванию информации особо нету. Все делается через электронный обмен данными. Интерфейс нужен, чтобы корректировать и управлять, а не набивать документы.

А как гарантировать, что данные с того момента не изменились ?

Event+websocket, etc.

И в чем проблема того, что будут считываться 50 записей при каждом открытии формы ?

В том, что это тормозно.

Это миллисекунда

4 мс только соединиться в локалке. В интернетах пинг до яднекса - 50мс, до гугла - 70мс.

Да даже, если их там 10К, все равно считывать и хранить их в кэше - накладно, как минимум по памяти, так и по самому чтению, передаче, обработке.

10к записей на js - это ни о чём ни по памяти, ни по времени выборки.

Кроме того, как при разработке определить, сколько будет конкретных объектов ?

По тому сколько у клиента памяти.

Переписывать все ?

Поменять настройки клиента, если вдруг не влазит.

Вы только что из всех фронтенд разработчиков сделали full stack разработчиков. Не так просто бэк сваять.

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

Интерфейс нужен, чтобы корректировать и управлять

Тогда там выборки какие-то надо, олап и или что-то такое.

На B2C интерфейсах там в любом случае нужна тонкая настройка

Это должно работать так: тебе надо склад. Делаешь шлёп, шлёп и у тебя склад. Тебе надо к нему веб магазин. Делаешь шлёп и у тебя магазин. Надо шаблон в магазине поправить. Зовешь фрилансера, даешь ему просрочку, он правит.

Если бы вы предоставляли сервис, а конфиги складов с магазинами были бы под каким-нибудь гпл, фичи бы добавлялись по запросу клиентов, всё бы это добавлялось модульно кому что надо, оно бы убило 1с, потому что тупо, дешево и работает, а вы бы брали бабло за сервис и хостинг всяких ИП Иванов А.О.

Event+websocket, etc.

Не очень понял. Какой Event+WebSocket от PostgreSQL до сервера приложений ? Кто-то сделал INSERT в таблицу, как это должен узнать сервер приложений ?

4 мс только соединиться в локалке. В интернетах пинг до яднекса - 50мс, до гугла - 70мс.

Еще раз - это B2B приложения. Тут чаще всего пинг до клиента несколько миллисекунд. Во-вторых 50мс практически незаметно для пользователя на одном запросе. А в lsFusion все оптимизировано, чтобы запросов было минимально.

10к записей на js - это ни о чём ни по памяти, ни по времени выборки.

Хорошо, а если 100к и таких объектов допустим 100. Мы же говорим о сложном бизнес-приложении, а не о простенькой программке с 3мя сущностями.

По тому сколько у клиента памяти.

Так у разных клиентов разное количество памяти. И вообще причем здесь это ? Как разработчику узнать, пользователь в базу запихнет 10 команд или 10млн ?

Поменять настройки клиента, если вдруг не влазит.

Какие настройки ? Нужно при разработке сразу решать - делать sliding window или нет ? Даже в React плавающее окно в таблице делается далеко не просто (ну или киньте ссылку как это просто сделать)

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

Основные наши клиенты - это компании с >2K сотрудников. На них и рассчитано вобщем-то. И там цель не дизайн, а скорость, стоимость и качество разработки при условии, что нужно делать сотни бизнес-процессов с различными формами и сотнями сотрудников.

Кто-то сделал INSERT в таблицу, как это должен узнать сервер приложений ?

Ну кто-то же что-то сделал, чтобы этот insert сделался. База данных же не существует сама по себе.

А в lsFusion все оптимизировано, чтобы запросов было минимально.

https://demo.lsfusion.org/erp/
http://i.imgur.com/tLonRXN.png
Запрос по таймауту каждую секунду.

Хорошо, а если 100к и таких объектов допустим 100. Мы же говорим о сложном бизнес-приложении, а не о простенькой программке с 3мя сущностями.

Я работаю с товаром. Я принимаю товар, выдаю товар у меня там 100+к этих наименований, 10к поставщиков, 10к складов. Почему нельзя запихать всё это в кеш клиента и не дёргать каждый раз сервак, когда тётя Зина будет делать накладную? Я же не говорю, что она будет работать сразу со всеми сущносями системы.

Так у разных клиентов разное количество памяти.

Ну пусть указывают сколько можно сожрать памяти ради того, чтобы не дёргать сервак.

Даже в React плавающее окно в таблице

Тут юзабилити интерфейса такой, что о плавающих окнах думать еще рано.

Основные наши клиенты - это компании с >2K сотрудников. На них и рассчитано вобщем-то. И там цель не дизайн, а скорость, стоимость и качество разработки при условии, что нужно делать сотни бизнес-процессов с различными формами и сотнями сотрудников.

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

А еще походу оно у вас течёт (фронт).

Ну кто-то же что-то сделал, чтобы этот insert сделался. База данных же не существует сама по себе.

Все равно, все это придется обрабатывать разработчиком вручную, что мягко говоря не просто. В lsFusion это все работает из коробки. Тут вообще важно понимать, что разработчик на lsFusion пишет исключительно высокоуровневый код, который отвечает за бизнес-логику. Он не знает ничего ни про WebSocket, кэши, sliding window и прочее.

Запрос по таймауту каждую секунду.

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

Я работаю с товаром. Я принимаю товар, выдаю товар у меня там 100+к этих наименований, 10к поставщиков, 10к складов. Почему нельзя запихать всё это в кеш клиента и не дёргать каждый раз сервак, когда тётя Зина будет делать накладную? Я же не говорю, что она будет работать сразу со всеми сущносями системы.

Потому что, тетя Маша создаст новый товар, а тетя Зина его не увидит. Ну или придется опять же уведомлять всех клиентов на перечитывание всей информации (или инкрементно, что еще сложнее). И всем этим придется заниматься разработчику. Да и в чем выигрыш тянуть 100К товаров, если работа будет идти с сотней, которые можно считывать по мере надобности ? Понятно, что можно делать как Вы говорите. Но там будут свои плюсы и минусы.

Ну пусть указывают сколько можно сожрать памяти ради того, чтобы не дёргать сервак.

Сервак не дергается никак от этого. Мы запускали на крупном клиенте логирование всех запросов и время их выполнения. Так вот совокупное время выполнения запросов на чтение справочников в диалогах - минимальное. Гораздо больше съедают ресурсов разные аналитические запросы.

Тут юзабилити интерфейса такой, что о плавающих окнах думать еще рано.

Тут юзабилити достаточно для эффективного выполнения сотрудниками своей работы. А вот без плавающих окон у вас на большом объеме и большом количестве пользователей все ложится будет (как на клиенте, так и на сервере).

Хз как они в этом работают. Если только конечно набрали ангулярщиков и в этом интерфейсе руками ничего не делают.

Нет там никаких ангулярщиков. Видимо у Вас просто недостаточно опыта в сфере бизнес-приложений. Вы еще интерфейса SAP'а не видели. А там с ним работают миллионы пользователей по всему миру. Просто в бизнес-приложениях к GUI и бэкенду другие требования и задачи.

Но у этой шляпы хороший потенциал на 1сный рынок всяких мелких магазинов, складов и прочих шараг, где программист - существо мифологическое.

Мелким организациям нужны простенькие и удобные коробки. Тут как раз это нужно тем, кому нужно много менять программу «под себя».

А еще походу оно у вас течёт (фронт).

Какие ваши доказательства ?

Если бы текло сильно, то несколько тысяч пользователей уже подали бы знак.

У нас инвалидация кэша на клиентах может положить сервис =)

Решение лезть в БД на каждый чих не такое уж плохое. Оно простое и никаких проблем, кроме производительности, не несёт, в отличии от других решений. А так как такого рода приложения предназначаются в основном для внутренних нужд, речь вообще не о производительности. Тем более, что пользовательские телодвижения в любом случае менее производительны, чем запрос в БД. Процессы, требующие производительности, обычно выполняются в виде джобов.

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

Сервак не дергается никак от этого. Мы запускали на крупном клиенте логирование всех запросов и время их выполнения.

Это у вас время выполнения нормальное, а речь про клиента.
http://i.imgur.com/yrToYRQ.png
500мс. Ну такое себе. А интернет может быть довольно паршивый.

Какие ваши доказательства ?

Когда закрываю вкладку она подвисает так минуты на 2. Ну может это всё фокс чудит, конечно.

Если бы текло сильно, то несколько тысяч пользователей уже подали бы знак.

Так это может никому и не мешает.

Мелким организациям нужны простенькие и удобные коробки.

Ну так из этого можно сделать коробку и выгнать 1сников нахер с рынка.

А там с ним работают миллионы пользователей по всему миру.

Ну так это автоматически не делает гуй удобным. Тем более, что тётенькам не припекает от тупой работы, делают и молчат. Они у нас тут в столбик считают на калькуляторе по распечатке. У меня вот припекает от такого, у них нет. У меня от мышевоза припекает и еще от много чего. Там самое страшное, когда формочки меняются, кнопочки и менюшки. Ломается workflow, они говорят, что ничего не понятно, ничего не работает сделайте как было.

У нас инвалидация кэша на клиентах может положить сервис =)

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

Тем более, что пользовательские телодвижения в любом случае менее производительны

Ну, если ui заставляет их мышевозить, то да. И нет рядовому юзеру обычно никакого дела, что у него по секунде каждое поле висит, да и не кто его не спрашивает, сиди и работай. Это у меня только от такого бомбит.

То, что предлагаете вы, несёт в себе неожиданные проблемы в неожиданных местах ради непонятной выгоды.

Вполне ожидаемая проблема в виде инвалидации справочника, которая решается вполне понятными средствами.

по секунде каждое поле висит

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

Вполне ожидаемая проблема в виде инвалидации справочника, которая решается вполне понятными средствами.

Еще до попадания в промышленную эксплуатацию это все обрастет костылями, а начнётся с вопроса «что делать, если инвалидировать кэш клиента не удалось?». И вот то, что звучало так, как звучало, представляет из себя очередь заданий на бэке для инвалидации кэша клиента, редис для пользовательского кэша, поллинг сервера клиентом на случай, если веб-сокеты отвалились и, на всякий случай, специальную кнопку в UI «инвалидировать кэш». Я утрирую, но примерно так все и будет. И все это решаемые проблемы, но они появились из-за нашего желания кэшировать, а реального профита пользователям все это не принесёт.

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