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

Сервер, в общих чертах, умеет:

1. Сам стучаться на облачный сервер и запрашивать и передавать необходимые данные
2. У себя в базёнке хранить текущие данные. Грубо - сутки.
3. Пользователи через веб-интерфейс (то есть придется писать еще фронтенд) считывают и вносят какую-то информацию. Веб-интерфейс должен быть в высокой степени удобным и быстрым. Но функциональность планируется не сложная и не богатая
4. Предоставлять API для офф-лайн мобильного приложения
5. По неким простым алгоритмам обрабатывать текущую внесенную информацию, фиксировать её у себя
6. Сам может "складывать" необходимые файлики на локальный файл-сервер и считывать их оттуда же
7. Количество одновременных пользователей каждого сервачка: 2-3 + одно офф-лайн мобильное приложение
8. Планируется, что тираж этих сервачков составит 200 и более экземпляров (в зависимости от успешности реализации)
9. Объем информации небольшой


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

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

Вот тут и возникает вопрос - на чем эффективнее писать подобную забубулину?


Вижу варианты:

1. Метнуться в сторону Metadata.js. Есть у кого реальный опыт?
Плюсы: CouchDB сама очень хорошо умеет в репликацию (не придется писать сервисы), обмен с 1С (основная учетная система) вроде бы есть из коробки.
Минусы: Кому-то придется изучать этот фреймворк. И не факт что он пригодится в будущем. Хотя, имея такой тиражируемый продукт, вроде бы разработчику вполне себе кусок хлеба с икрой (красной) вроде бы обеспечен...
Самый тяжелый минус: мало проектов на этом фреймворке, вообще непонятны трудозатраты. Причем никто не сможет это оценить, пока не начнется разработка. А время - деньги, как говорится. Ну и, естественно, происходит сильная привязка проекта к разработчику. Потом найти замену в случае чего будет ой как непросто.

2. Нанять двух-трех "студентов" на PHP и быстро прототипировать и смотреть что получается.
Плюсы: порог вхождения в PHP вроде бы пониже чем на остальных языках, значит, первые версии программы должны выйти подешевле. Это для меня самый жирный плюс. Плюс не придется использовать такой радикально-специфический продукт как Metadata. Разработчик не становится уникальным, снижается зависимость.
Минусы: Нужно будет отдельно заказывать фронтенд.

В общем, задача интересная. Но мало знаний.


Камрады, покритикуйте, предлагая. Кто как решал бы подобную задачу?

Я за php. Никаких проблем нарисовать примитивный(да и не примитивный) фронт с использованием только html и css не вижу.

(1)
А бэкенд с озвученными требованиями вообще удобно будет писать? Ну там регламентные задания например...
Может есть какой фреймворк подходящий?

имхо, но...
"Беда, коль пироги начнет печи сапожник,
А сапоги тачать пирожник."

(3)
Обоснуйте

(4) А чем серверный вариант 1С дорого? Я так понял в вашем случае подойдет версия на пять пользователей, она там чета типа 15т.р. стоит всего.

+(5) А если брать на 200 серверов, то думаю можно договориться на нехилую скидку, процентов так в 25. :)

высокая стоимость серверного варианта, стоимость лицензий
Это сколько дорого?А разработка своего велика не дороже будет?

А поддержка и допилы сколько буду стоить.Что-то тут не понятно

А я так вообще не понял зачем нужен "мини-сервер" и почему не файловый вариант РИБ?

(5)
15 тыр на сервер
+ 4 тыщи на каждый сеанс
в итоге при 2х активных пользователях получаем 23 тыщи на каждую точку - и это только за лицензии. 23000 * 200 = 4 с половиной лимона. Лучше б на разработку и премии эту сумму потратить.
Плюс тяжеловесность самой 1С, скорость интерфейса, удобность интерфейса. Как ни крути, веб-интерфейс можно гораздо тоньше напилить, чем формы 1С.
Ну и плюс в (0) не указал - на точках железо не очень хорошее.

(9)
ненадежность файловой 1С, опять же лицензии. (8 тыщи минимум на точку = полтора лимона). Может быть, нам дадут скидку как в (6), пусть будет лимон. Это тоже не мало.

Ах, да, конечно же эта преславутая "ненадежность файловой базы"(0). Мда... слухи о "ненадёжности" файлового варианта несколько преувеличены. Только не надо мне доказывать, что я не прав - семь лет практики РИБ с файловыми вариантами подчинённых узлов как бы доказывают что вполне можно работать.

Я не настаиваю (ваше право, хозяин-барин), просто удивляюсь.

(10) Еще большой минус 1С - гемор с программными лицензиями, которые надо будет переустанавливать при изменении железа.
С другой стороны, постоянная поддержка велосипеда "не на 1С" может обойтись еще дороже - надо считать.

(11) У ТС явно мелкие точки, где может и уборщица шнур выдернуть.

Я бы написал на https://github.com/gobuffalo/buffalo

1. Планировщик заданий там есть, стучаться во внешние сервисы - не проблема
2. Базёнка подключается любая, в зависимости от количества данных - от sqlite до postgresql
3. CRUD интерфейс по структуре базы создаётся автоматически, на него сразу натягивается bootstrap. То что надо для "простого и удобного" интерфейса. Немного логику допилить и всё
4. Создать json/xml api легче лёгкого. Главное описать структуру данных
5. Тоже не проблема
6. Ищем библиотеку go для работы с smb/ftp/nfs/что-там-у-вас, подключаем
7. Пфф
8. И?
9. Точно sqlite

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

Язык Go сам по себе достаточно простой и производительный.

(11)
Даже если мы с Вами не будет говорить про надежность файлового варианта, то стоимость лицензий всё равно остается важнейшим фактором...

(12) Да, это еще один гвоздь.
(13) Верно.

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

(17) Не знаю,что решите,но можно тестовых сделать два варианта и погонять.Опять же если так важно решение то и денег не пожалеют.

(15) Ещё раз: я не спорю и не оспариваю ваш выбор. Просто "Я мзду не беру, мне за державу обидно"(с). С одной стороны, 28 тысяч за USB-ключ на 5 рабочих мест - небольшая цена, но если их потребуется 200 штук... наверное я бы тоже стал искать альтернативу :)

(14)
Круто! Спасибо, покурю!

(0) тут важно понять что срок реализации такого проекта, минимум полгода. а учитывая ценники программеров на PHP и т.п.  раздуют бюджет мероприятия огого

и  полгода это очень оптимистично

(22)
Неужели на PHP это настолько трудозатратно? А если опустить веб-интерфейс?
У меня такое ощущение, что ожидаемый функционал не такой уж прямо богатый и тяжелый. Ну, по крайней мере, для 1С...

nodejs + vuejs

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

брать студентов - это моментально нарватся на то, на что я например нарвался и тут на форуме проскакивало. стучатся в базу через фреймворк-ORM, который как "оказывается" на сколько нибудь серьезных нагрузках и объемах начинает просто невообразимо тормозить...и таких подводных камней всплывет огромное количество
а если это 200серверов надо синхронизировать то это еще веселее

ну или laravel + опционально vue (если хочется spa а не сайт)

(24)
По трудозатратам какая вилка получается?

(25)
"отдельный человек на мобильное приложение"
Мобилку в расчет вообще не берем - она уже есть, её успешно сейчас тиражируем (с облачным сервером), это не суть. Я упоминал про мобилку в контексте нагрузки.

"200серверов надо синхронизировать"
облачную часть тоже в расчет не берем, там отдельная песня.

(27) если отбросить обучение? пару недель на прототип

и до бесконечности

(0) вместо 3х пхпшников - наймите 1 сеньора jsника

Написать свою НОРМАЛЬНУЮ систему синхронизации силами джуниоров/мидлов не получится

если нет потребности синхронизации с 1с можно метадату не брать, а просто кауч-пауч юзать

Интересно, что будете делать с 200 точками, если логику работы приложения придется изменить?
Я бы наверно все таки в сторону решений типа метадаты смотрел.

(32) +1 но бабла и времени уйдёт адовое количество на попытки "да все получится!!"

(34) так вебинтерфейс же планируется в любом случае

(36) Ну и чего? Я так полагаю логика и база хранятся локально на каждой точке в случае базы + php.

(37) ты вообще не понимаешь что такое веб приложение?

(37)
Да, логика и база хранятся локально на каждой точке.
На каждой точке поднят какой-нибудь апач или иис.

(34)
Да, это вопрос серьезный, но его решение вроде не сильно отличается от одинэсного - по сути всё сводится к регламентной операции, которая будет в определенное время запрашивать файл обновлений из облака и устанавливать его локально (исполняемые файлы там, библиотеки, страницы и т.п.)

А зачем тебе 200 серверов? делай SaaS

Нанимать знающего человека, либо аутсорс компанию на этот проект. На студентов, которые на php напишут что-то толковое, я бы не рассчитывал, они могут только типовые задачи делать. Python или ASP.Net напрашивается под эти задачи.

(41)
Подробнее плиз....
У меня на точках канала толком может не быть. Но приложение работать в это время ДОЛЖНО.

(41) не все готовы свои данные отдавать кому-то

(0) >>удаленных точках, связь с которыми очень нестабильна
Улучшать качество связи не планируется? Это будет сильно дороже 200 мини серверов или разработки чего-то своего?

(40) ага, только в теории все просто
а потом начнется интересное. поменяли структуру базы например и надо её  на 200 серверов реплицировать... а потом оп и ошибка и все 200 упали...поднимать вручную? бекап?

(0) Вы же там не ERP будет ставить, а как понимаю самописную конфу, интерфейс будет летать, если правильно сделаете.

или половина обновилась, половина нет, приложение с одним апи, некоторые сервера со старым...надо их поддерживать паралельно

(42)
У нас в команде есть чувак который был аналитиком в одном крупном уникальном и очень успешном проекте на питоне.
Он озвучил минусы питонцев:
1. Дорого
2. Внеконтекстное выполнение. "Не вникают в то что делают". Нужен высокий уровень формализации задания.
3. Дефицитно

Он больше топит за PHP на эту задачу в угоду доступности специалистов.

(45)
К сожалению, не везде это возможно. Поэтому думаем о локальном сервере "сам с усам".
Мы сейчас используем (упоминал выше) мобильное приложение на всех этих точках, так что все проблемы со связью мы уже собрали и проблему знаем очень хорошо и прямо в лицо, а не сбоку.

(49) На волне хайпа нейронных сетей и машинного обучения питон сейчас стал очень популярным языком. Может конечно от города зависит. Но мне показалось средний уровень разработчика на php очень низкий, сделать что-то без использования CMS нереальная проблема для большинства. Хотя вам проще самим проверить, пообщавшись с потенциальными исполнителями.

(49) в PHP доступность не специалистов, а джунов которые код пишут внутри html как "по старинке"

а "Внеконтекстное выполнение. "Не вникают в то что делают" -- так и должно быть на самом деле
другой подход это получится мешанина из самодеятельности и костылей которую невозможно будет поддерживать

(46) (48)
Риски, согласен.
Есть какая-то альтернатива?

(52)
"другой подход это получится мешанина из самодеятельности и костылей которую невозможно будет поддерживать"
То есть так, как это происходит у нас в 1С?)

(54) именно, в 1С как раз подход "сам себе архитектор, программер и РП" потому что "денег нет"

кстати есть минисерверы 1с на 5 пользователей. вполне по деньгам наверно

в вашем случае лучше писать на 1с, ибо не на 1с вы запорете обязательно

(53) дело не в альтернативе, а в том что это сложнее чем кажется, не "бац бац и работает"

php вполне потянет в связке с MySql,это как раз для него задача,ну и запуск обменов по таймеру,и,самое главное,что можно убунту на миникомп вкострячить и будет работать.

Если есть программисты java,то можно нарисовать приложение

(56) Какое оно имеет отношение к задаче в (0)?

(60) там 1 из пунктов было - что сервер 1с - это дорого

(61) Вы еще кассовый сервер предложите. Ну а че? Слово же сервер есть. И не дорого ))))

(58)если описать через обьекты интерфейс к базе,то при изменении структуры мы только меняем описание обьекта.

php вещь замечательная,параллельные потоки,сокеты на низком уровне и т.п.интересные вещи,а главное,что все просто и работает.

(62) а что такого то? ведь предполагаетсяф всего 2-3 пользователя

(64)
Что из этого
"1. Сам стучаться на облачный сервер и запрашивать и передавать необходимые данные
2. У себя в базёнке хранить текущие данные. Грубо - сутки.
3. Пользователи через веб-интерфейс (то есть придется писать еще фронтенд) считывают и вносят какую-то информацию. Веб-интерфейс должен быть в высокой степени удобным и быстрым. Но функциональность планируется не сложная и не богатая
4. Предоставлять API для офф-лайн мобильного приложения
"
умеет сервер 1с?

(33) Я тоже за такой подход. Не обязательно всю метадату тащить. Можно коуч базу + апи к ней.

(65) абсолютно все это умеет. плюс быстрая разработка и спецы уже есть

(0)

ты: ЛПР, дай бабла
ЛПР: зачем?
ты: сервер купить
ЛПР: зачем?
ты: ну чтобы нормально было
ЛПР: дак итак все работает

тут голова болит у тебя, и это твои проблемы.

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

(67) Сервер 1С это всего лишь прокладка между сервером БД и тонким клиентом. Все.
Нифига он не умеет
"стучаться на облачный сервер" - это клиент
"в базёнке хранить текущие данные" - это сервер БД
"Пользователи ... считывают и вносят какую-то информацию" - это клиент
"Предоставлять API для офф-лайн мобильного приложения" - это клиент.
Ничего из этого не умеет минисервер. Да и "взрослый" сервер приложений 1с тоже.
Понятно, что все выше сказанное относится к экосистеме 1С.

(57)
А почему ты считаешь что не на 1С мы запорем обязательно?)

(69) "единственный возникающий вопрос-зачем"
ИМХО - от неумения нарисовать HTML форму и обработать запрос от фронта.

(56)
Я писал математику в (10)

(71) у вас нет опыта таких проектов. в таком масштабном проекте куча подводных камней будет

(73) что-это за точка что 23 тыщи - это дорого? Что это за холдниг такой, что степлеры в лизинг берет

вы 2 млн на разработку съедите легко и не подпавитесь и ничего не сделаете

(33) (66)
а логику на чем?
Вариант интересный, тоже думал об этом. Но это решит вопрос репликации и хранения, но останеся вопрос логики.

(77) логику на клиенте всю делать: типа реакт-вью или какие спецы есть

(0) Уже давно проходили: Краилово ведет к попадалову, т.к не взлетит.

(75) обычный провинциальный колхоз с соотв мышлением бизнеса и ИТ

самая проблема что с вашей стороны нет того кто бы смог оценить качество не 1сного продукта

(81) какого продукта, тут требования внятно тс сформулировать не может

(82) тот, который им напишет приглашенный пхпшник или другой кто

(78)
Не эффективнее будет написать прокладку, организующую объектную логику и предоставляющую API?
Чем писать логику сначала на веб-клиенте, потом то же самое на мобилке, потом то же самое на роботах интеграции?

(84) на мобилке тоже можно веб юзать

(86) Это уже совершенно другой вопрос

(0) Используй классику - "php + mysql + ngnix(apache) + cron" и будет тебе счастье.

Бесплатный софт плюс бац бац и в продакшн

Кстати, а не дешевле выйдет более устойчивую связь наладить в точках? И работать с центром?

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

(0) Не зная точных требований невозможно выбрать на чем реализовывать этот "сервер".

Стоимость/распространенность специалистов по разработке это одно из при выборе.
Выбор из php/C#/java/js/python и т.д. как и какую бд использовать и прочее.

Если у вас уже есть сильная команда 1С-ников то не парьтесь и берите http://oscript.io/docs/page/http
Еще допом наймите С# спеца на постоянку или фри чтобы http://oscript.io/docs/page/libraries дописал требуемые если что.

(89)  
см. (50)
Пока - изучаем вопрос о софте.

(90)
кстати может быть и да

(90) В продакшен этот CouchDB имеет огромную кучу проблем и основная что оно NoSQL и хреново ложится на обычные реляционные (табличные) данные.

(91)
что скажешь про (14)?

(0) Посмотри на https://firebase.google.com/
Если данных действительно немного, может хватить бесплатного плана.
Простенького веб-клиента с аутентификацией и плюшками можно написать за пару часов на vue или react.

(95) Ничего не скажу ибо не знаю Go и эту штуку.

(91)+ В качестве БД можно взять классику в виде Postgres, есть готовые решения по репликации между серверами.

(96) Каким образом оно поможет если ТС требуются распределенные локальные сервера, которые выступают промежуточными "узлами РИБ" между мобильным приложением, веб-клиентами и центральной БД.

У них центральная БД не проблема и засовывать ее в облако нет никакого смысла.

(99) Вот так https://firebase.google.com/docs/firestore/manage-data/enable-offline

(100) "Note: Offline persistence is supported only in Android, iOS, and web apps."

Особенно смешно с "For the web, offline persistence is an experimental feature that is supported only by the Chrome, Safari, and Firefox web browsers."

(0) Дойдёт до фактической реализации - готов участвовать в реализации на php - веб клиент, серверная часть, api для 1с и мобилок

(0) С  метадатой одна большая проблема - нет актуальной и полной документации. Поэтому раскуривать придется долго...

(101) Чего смешного? Веб и мобайл. Все ьраузеры поддерживаются.

(98)+ Как вариант берем Postgres к нему добавляем http://postgrest.org/en/v5.0/tutorials/tut0.html и пишем еще фронт на HTML5/CSS/JS.

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

(104) Объясни каким местом и откуда мобильное приложение их будет получать и куда отправлять данные, если связь того?

В какой браузер?

(106) Там все написано в примерах.

файрбейз вроде умеет оффлайн работать

(107) У Firebase есть один минус, который перекрывает все плюсы.

Он не в РФ хостится.

Любая разработка будет дороже чем локальная базка на 1с.
Студентов 2 взять??? они тебе за год ее напишут, с той зп которую ты планируешь им платить..
Если без 1с, то разработал бы без облак всяких кошерных. просто на fpc программулину exe

(109)+ Даже не могу представить заграничные VPN по падающим каналам связи ))

(111) Канал - он стсуко штука двусторонняя. И падать вполне может на твоей стороне. Не обязательно на стороне заграничного VPS. Но эффект будет тот же.

(96) (100)
Штука крутая, но оффлайн должно работать не просто одно устройство.
На устройствах внутри точки связь должна быть всегда (там wi-fi). Если что-то изменилось в мобилке, то на веб-клиенте это должно тоже измениться, не важно - интернет есть или нет.
На Firebase я не увидел этого.

(110) Поэтому 1С и популярен. Все готовенькое и дешево.


>>Плюсы: порог вхождения в PHP вроде бы пониже чем на остальных языках, значит, первые версии программы должны выйти подешевле.

Такой софт сейчас задаром раздают :-)  Всяких eCommerce с BI - вагон и три тележки.

(114)
"Такой софт сейчас задаром раздают"
какой такой софт?

(112) Скорее он будет падать ровно посередине по вине провайдера по приказу от РКН ))

(91)
Я, признаюсь, тоже подумывал в сторону oscript но чет не ожидал что кто-то его прямо порекомендует)

(117) OneScript пока еще в процессе роста из пеленок, маловато библиотек на все случаи жизни.
Но это компенсируется тем что оно легко расширяемо на отличном, популярном C#/.Net.

(118)+ Имхо фирме 1С надо было давным-давно выпустить свой интерпретатор языка 1С для командной строки.

(119) Зачем?

(120) Для начального обучения в школах/вузах, чтобы алгоритмы на языке 1С проходили а не "школьном алгоритмическом"

(121) в школах 1С? да кому нужен этот 1с? все хотят жаву и свалить отсюда

ИМХО Клюшки + УРБД, а дальше экспортируйте в свой снеговик.

(123)
Потому что восьмерка еще сырая?))

(113) Тогда можно подождать чуток. Монга зарелизит мобильную версию, которая будет "сама" с большой монгой снюхиваться. Или записаться на закрытую бету.

Ужасное слово "базёнка", подавился и не смог дочитать.

(0) Для начала я бы посоветовал не гнаться за дешевизной, это путь в ад. А так PHP+Apache+Mysql (+javascript, если нужно) вполне себе вариант.

Чел тоже начал с 10 посещений в день. Чем кончилась вся музыка можно полюбопытствовать тут:
https://habr.com/post/421765/

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

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

(127) +1
Наиболее доступный и понятный многим стек

на самом деле если есть уровня "архитектор" ребята на 1с, сделать вменяемое API на php (например laravel) им будет не сложно (и интересно ;)).

(128)
Великолепная статья!

(0) Node.js + redis

(128) ТС скорее как раз вот-это нужно  : https://habr.com/post/422151/


Ему просто "разруливать очередь сообщений" нужно.

http://catalog.mista.ru/public/883068/

(134) Боюсь это совсем про другое...

(134) Вообще не понял смысл тестировать webpack для 1С.

(133) там о том,как изобретать велосипеды,т.к.у Frontol есть встроенный сервер синхронизации,позволяющий синхронизировать несколько баз.
Кроме того,внезапно,в базе FireBird есть события,то есть из триггера можно отправить событие и не лезть в javascript вообще.
То,что прикрутили очередь событий,это понятно,просто,они забыли о том,что в 1с чеки с кассы никакой полезной нагрузки не несут,а все движения делает отчет о розничных продажах.

(0) С пяток решений тебе накидали.
Теперь тебе надо найти исполнителей ( желательно с опытом )
и делать на том что лучше всего знают исполнители.

(138) Он отдельных денег стоит. Основной на SQLite и сильно локальный. Чеки нагрузку несут оборотную, например "какого  не прокружен выставленный товар на POS".