На чём писать CRM?

Question

[Анатолий]

Привет друзья!
Я изучаю этот вопрос, интересно мнение сообщества.

Предполагается создание модульной системы, набор модулей выбирается под задачи, телефония, почта. В общем-то стандартный набор. Готовые решения изучаем, но наш случай, когда специфика очень большая, в основе логики.

Интересует:

• Уровень вхождения. Специалисты не должны быть на "вес золота".
  
• Десктоп !important (нужен оффлайн), смартфон и web (не обязательно)
  
• Кросплатформенность не обязательна (но приветствуется), ориентируемся на Windows
  
• Десктоп !important, потому что база не должна быть локальной и не зависимой от интернета
  

В общем, нужно на ёлку залезть и не поцарапаться.

Comments

[Adamos]

Десктоп + смартфон + веб = веб

[Анатолий]

Adamos: десктоп важен, остальное желательно и планируется к реализации в будущем

[Adamos]

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

[Анатолий]

Adamos: т.е. написав на каком нибудь шарпе, мы потом затрахаемся? почему?

[yurygolikov]

с++?

[Анатолий]

yurygolikov: вариант хороший, но я в процессе изучения. Провожу анализ.

[Adamos]

Анатолий: превращение исключительно десктопного приложения в олнайн-сервис будет головной болью в любом случае. Если оно будет гвоздями прибито к Виндам - острой болью.
Превращать любые приложения для совместной работы в онлайн-сервисы - это настолько очевидный и повсеместный тренд, что в этом веке даже до лютых ретроградов вроде 1С дошло, что пора бы.

[Анатолий]

Adamos: спасибо! Вы подтолкнули на очень интересную мысль! Соглашусь с вами полностью. Хотя, десктоп все равно нужен ))

Answer 1

[Максим Кудрявцев]

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

Уровень вхождения. Специалисты не должны быть на "вес золота".

Открываем hh.ru по Вашему региону и ищем резюме с ключевыми словами C#, Java, PHP и т.д. Исходя из количества потенциальных кандидатов и их запросов понимаем будут ли они на "вес золота" или нет.

Десктоп!important, \(смартфон, web)?\

Не понимаю в чем проблема сделать приложение в браузере, т.е. чтобы Ваша CRM открывалась через любой бразуер. По этому принципу работает Мегаплан, Амо и т.д. Да почти любая соверменная CRM. Возьмите на основу этот же путь, как вариант.

UPDATE 16.12.2016
Анатолий ниже в комментах к моему ответу Вы пишите, что большенство людей советуют Вам использовать именно облачную реализацию. Позвольте поделиться своими мыслями по этому вопросу.

Разрабатывая любое десктопное приложение рано или поздно Вы столкнетесь с проблемой его корректной работы на разных машинах. К примеру, создали Вы програмку под Windows. На одной машине с Win 7 она работает прекрасно, а на Win 7 SP 1 уже выдает какую-то ошибку. Еще пример, на 5 машинах стоит одинаковая ОС. На 4-х из них Ваша программа работает прекрасно, а на 5-й какое-то там окно не отображается... Почему так? Надо садиться и разбираться, копаясь конкретно в настройках этой машины, выесняя что там не так, чего там не стои или стоит лишнего....

Всем этим я хочу привести Вас к одной единственной идеи: есть очень большая разница, между приложением, которое должно работать на одной машине и, приложением, которое должно выполняться на десятках/сотнях/тысячах рабочих станций.

Писать и поддерживать приложение по второму варианту гораздо сложнее и более затратно как по времени, так и по деньгам. Решением здесь как раз является облако, причем совсем не обязательно Вам где-то покупать сервер в дата-центре и т.д. В локальной сети своей организации ставите самый обычный системный блок, на котором будет стоять Debian + Apache + MySQL. Все, для CRM до 50 человек, Вам такой кофигурации будет более чем достаточно. Любая Ваша CRM, будь она самописной или купленной, теперь должна работать только на одной машине, а все остальные - тонкие клиенты, которые взаимодействуют с ней используя лишь браузер. Такую конфигурацию легче и дешевле поддерживать со всех известных мне точек зрения.

Comments

[Анатолий]

нужна работа с локальной базой из коробки. Офис получил файл, и начал работать, даже если нет доступа к интернету.

[Анатолий]

Я сейчас и ищу эти ключевые слова: C#, Java, PHP

[Максим Кудрявцев]

Анатолий: Ваше "нет доступа к интернету" меня вгоняет в ступор. У Вас в офисе нет локальной сети? Каждая машина сама по себе автономна? Я не вижу проблемы развернуть в локалке компании свой веб-сервер, на котором и держать купленную/разрабатываемую CRM.
Есть у Вас там выход к интернету или нет, главное чтобы локальный сервер был доступен.

[Adamos]

Собственно, дамп базы для переноса (или конкретных данных из нее) в случае веб-сервера вполне можно сделать штатными средствами CRM.

[Анатолий]

Максим Кудрявцев: да, есть сеть, есть доступ к интернету. Большинство советует облачную реализацию, а у меня задача изучить десктопное приложение, приходится выкручиваться. Конечно! можно и так.

[Анатолий]

Adamos: можно. Меня интересует именно десктоп вариант, но тот факт, что большинство советует именно облако, наводит на определенные мысли.

[Adamos]

Анатолий: я, если что, ни разу облако не советовал.
Облако - это для тех, кто перерос один сервер.
Или для тех, кто наслушался рекламы и сам не знает, что ему нужно.

[Анатолий]

Adamos: я имел в виду не ОБЛАКО, а маленькое локальное облачко. Т.е. реализацию через web сервер.

[Adamos]

Анатолий: вот я и уточнил, что, имея в виду одно, вы сказали другое.
Вдруг вы при написании ТЗ тоже будете иметь в виду не то, что говорите...

[Анатолий]

Adamos: именно так и произойдет, тогда я вспомню наш разговор и скорректирую поток своих мыслей ))

Answer 2

[Вячеслав Плиско]

Я бы советовал строить CRM на базе существующих решений. Например, в мире PHP есть OroCRM, открытый исходный код, вменяемая архитектура, строится на базе symfony, тем самым упрощается поиск разработчиков.

Comments

[Анатолий]

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

[Вячеслав Плиско]

Анатолий: с внешней базой данных проблем нет, все решения предполагают что они будут на разных серверах. Можно использовать vpn или ssh тунель с сертификатами, в интернете можно найти готовые скрипты для их поднятия.

[Анатолий]

Вячеслав Плиско: я не видел пока лаконичных решений. SSH настраивал, но только от локалки к серверу, делал тоннель. VPN, пока кажется громоздким решением. В этих случаях нужны настройки с которыми не каждый справится. Хотя, можно создать скрипт, который в интерактивном режиме все это сделает.
Вот, до вашего ответа юзал поиск на эту тему.

[Вячеслав Плиско]

Анатолий: я vpn на DO поднял одним готовым скриптом, на хабре где-то валяется в статьях. А сейчас и вовсе можно поискать докер образ с базой и впн, я не вчитывался то или нет, но вот первая же ссылка в гугле https://www.8host.com/blog/zapusk-openvpn-v-kontej... Если не то, то можете сами погуглить "docker vpm mysql"

[Анатолий]

Вячеслав Плиско: спасибо! пару контейнеров на сервере крутятся. Видимо VPN выход из ситуации. Если коллеги одобрят, все мои за и против — будем делать на вэбе.

[Stepan Yudin]

Я тоже за Оро, шикарная платформа

Answer 3

[Виктор]

Смотря какие требования будут. Если это web-вариант, то чем плох PHP в связке с БД?

Comments

[Анатолий]

десктоп нужен, веб это уже следствие.

[Виктор]

Анатолий: Анатолий, на десктопе будет браузер. Опыт говорит, что все равно затем придете к онлайновой работе с ЦРМ-кой. И тогда веб - оптимальный вариант.

[Анатолий]

Виктор: да, нужен офлайн.

[Adamos]

Анатолий: Вы, упираясь в этот "нужен офлайн" и "все равно данные разных пользователей сводить надо", наваляете на виндах лютый энтерпрайз, под который придется покупать и раскочегаривать винсервер, не говоря про лицензии на каждое подключение.
Сделайте то же самое изначально в веб-варианте - и для работы внутри офиса сгодится любая старая галоша, на которую можно будет поставить LAMP. Бесплатно.

[Анатолий]

Артём Петренков: вы имеете в виду установку: apache, php, DB, в локальной сети? Можно собрать пакет со всей этой кучей и запускать с одного места. На самом деле, это хороший вариант. Я изучаю этот вопрос. Пока больше людей склоняются к облачной реализации.

[Анатолий]

Артём Петренков: прошу прощения за оговорку, под облаком я подразумеваю реализацию через web сервер, пусть и локальный. Если не обязательно PHP, то что? я бы хотел понять, какая технология наиболее оптимальна. JavaScript, включая React, Angular и т.п., Python, может есть что-то еще...

[Анатолий]

Adamos: хорошо. PHP, JavaScript, Python, что-то еще?

[Adamos]

Артём Петренков: ну, так сейчас PHP + Javascript уже стало классической технологией. Для написания прототипа, а если особенно звездных требований нет - то и рабочей системы.
И людей на этот стек найти не проблема, и пробовать можно начать довольно быстро, и изменения недороги.
А уж если оно взлетит настолько, что будет иметь смысл говорить о нагрузках и кластеризации... впрочем, к тому времени, скорее всего, его все равно захочется выкинуть и написать заново.

[Анатолий]

Артём Петренков: ТЗ на таком этапе, что нужно определить оптимальный путь при выборе технологии разработки.

[Анатолий]

Adamos: т.е. это нормальная практика?

[Adamos]

Анатолий: В IT нормальных практик - анусом жуй.
Вопрос, какие преимущества и недостатки у применения конкретной практики в конкретном случае.

[Анатолий]

Adamos: это очевидный факт. Собственно для конкретизации и создан сей вопрос.

[Adamos]

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

[Анатолий]

Adamos: Согласен. По этому, меня интересует не "франшиза", а общие сведения. Предположим, я посмотрел на C#, нашел по нему необходимые сведения, в принципе "наш клиент". Думаю в случае с CRM можно оперировать обобщенными данными. Я изучу все предложенные варианты и замечания.
Спасибо! конкретику сделаю, это на самом деле необходимо.

Answer 4

[Константин Нагибович]

1C

Comments

[Анатолий]

: С

[Константин Нагибович]

Анатолий: а почему нет?

[Анатолий]

Константин Нагибович: допил 1С будет очень накладным, т.к. слишком большая специфика бизнес логики.

[Константин Нагибович]

Анатолий: как бизнес-логика связана с платформой для разработки?

[Анатолий]

Константин Нагибович: вы предлагаете писать на языке 1С или допиливать 1С под свои нужды? Я просто не знаю, можно ли поставить себе на сервер компилятор и писать на 1С. Я про допил продукта

[Константин Нагибович]

Анатолий: предлагаю писать на 1С.

Answer 5

[sim3x]

Надо начинать делать на том, что есть под рукой, то что нужно вот прямо сейчас
Отказаться от жесткого требования оффлайна

Офис без инета - прекрасно, но там также не будет телефонии, что в современных реалих = нет работы и все по домам

Если офису ок без телефонии (sic), то пусть будет интранет, а в нем сайт на LinNginxPostgresPHP

Comments

[Анатолий]

база не должна зависеть от интернета.

[Анатолий]

Вы не правильно отредактировали вопрос. /(смартфон, web)?/ - означает как в регулярке, не обязательно, но вы правы, я как раз собирался внести ясность.

[sim3x]

Анатолий: а как ее потом синхронизировать между десятком работников?

[Анатолий]

Это хорошее замечание! Нужно будет реализовать сервер и клиентов.

[sim3x]

Анатолий: наличие сервера и клиентов не отменяет проблемы с синхронизацией

[Анатолий]

Артём Петренков: тоже верно. Отмечу у себя этот момент, однозначно!

[Анатолий]

sim3x: есть такая проблему, буду благодарен за наводки по теме.

[sim3x]

Анатолий: там нет общего решения - любое решение боль
Просто возьмите и смерджите одновременно 5 веток в гите. А потом подумайте насколько сложно сделать такое автоматически

Answer 6

[xmoonlight]

Lazarus only!

Comments

[Анатолий]

Спасибо! посмотрю, что там за кроссплатформенное чудо!

Answer 7

[Andrzej Wielski]

Пишите под веб, если хотите дешево - PHP.

Посоветую фреймворк Laravel.
В нем при надобности можно совмещать локальный и серверный драйвер БД. После каждого действия ставить в базе "галочку", после чего приложение будет подсасывать из серверной БД данные в локальную.

Потерялась сеть? Не беда, делаем изменения в локальной. Появилась? Сравнение, внесение изменений.
Хоть данная функция довольно сложна, но в любом случае с этой трудностью вы столкнетесь не только в PHP/Laravel. Синхронизация между пользователями (локалью / сервером) нужна, от нее никуда не деться.

Comments

[Анатолий]

Спасибо! Laravel, очень красив. Был бы вам благодарен, за ссылочку по теме!

[ev09]

Как вы вопрос решаете, если у 1 потерялась сеть, а у второго нет. первый добавляет что-то например пользователя и второй. По сути локально нужно записывать команды SQL , а вот потом будет или нет конфликт, тут большой вопрос. Не совсем понял как Laravel будет работать локально? через сервер на компе? ну это так себе вариант. это нужно запускать php сервер + базу локально. это не решение кликнул и работай.

[Andrzej Wielski]

ev09, ну вы, конечно, откопали тред 8 летней давности. Даже пришлось вспоминать свой пароль, чтобы ответить :)

Что касается одновременного редактирования данных - тут можно применить Event-Driven архитектуру, и разделить приложение на несколько микросервисов.
Представим, что в части бэкенда у нас есть 3 части каких-то сервисов:

1. DatabaseEmitter - записывает и возвращает финальные данные из БД на основе отправленных в него эвентов
2. OnlineEventEmitter - принимает эвент на редактирование данных, записывает его, и формирует эвент для отправки в DatabaseEmitter
3. OfflineEventEmitter - принимает набор эвентов на редактирование данных, формирует эвенты для отправки в DatabaseEmitter

Если с OnlineEventEmitter всё ясно - он, по сути, выступает посредником между клиентом и базой, то в OfflineEventEmitter кроется вся магия:

Как только клиентское приложение вышло в сеть, оно отправляет заранее записанную пачку эвентов на бэк, и OfflineEventEmitter берёт их в работу. Он запрашивает слепок всех записанных ранее эвентов, которые бережно отложил OnlineEventEmitter, сравнивает их с запрошенными изменениями, и формирует итоговую пачку эвентов на запись в БД и на запись в хранилище эвентов.

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

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

А что касается второго вопроса - во первых, спустя целых 8 лет я бы порекомендовал взять совершенно другой стек (Golang / Rust + TypeScript / React для фронта), а во вторых, оффлайн веб-приложения уже давно поддерживаются всеми браузерами, с появлением веб-воркеров. Просто разделяйте бэк и фронт, и будет вам счастье. Даже если брать Laravel, то и там из коробки есть поддержка всех популярных js фреймворков.

Answer 8

[ev09]

Если CRM будет использовать 1 человек, то можно смотреть в сторону electron, если больше, то нужен сервер. Опять же desktop будет привязан к компьютеру. Облако можно грузить с чего угодно. Но там должна быть защита данных.