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

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

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. Разработчик не становится уникальным, снижается зависимость.
Минусы: Нужно будет отдельно заказывать фронтенд.

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


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

А зачем тебе 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".