Всем привет!
Специально зарегился на ресурсе, чтобы написать ответ на топик. 
Я профессионально занимаюсь проектами внедрения и доработки SuiteCRM уже более 5 лет. Участвовал в десятках проектов с разными заказчиками и совершенно разными требованиями. Знаю многие подводные камни системы и различные пути их обхода. Пробовал контрибутить исправления и доработки в mainstream системы.
Хотел высказаться именно относительно новшеств 8-ки. Дело в том, что переход на новый интерфейс назревал уже давно, заказчики постоянно требуют какого-то “интерактива”, который крайне топорно (с точки зрения архитектуры и сопровождения) реализуется сейчас . Существующий внешний вид и архитектура frontend безвозвратна отстала от современных стандартов лет на 20. ;( Большинство известных мне профессиональных команд, которые занимаются доработками для реальных заказчиков, уже давно предпочитают вносить минимальные изменения в “основную систему”, а строить свои доработки “как-бы вокруг” дистрибутива системы…
Поэтому решение “разделить” систему на две части frontend и backend назрело и реализовывалось в той или иной мере в доработках уже давно. Другое дело “как разделить”, “какие архитектурные приемы применить”, “где и как провести контур безопасности”, “что выбрать для реализации интерфейса”.
Вот в ответах на эти вопросы с существующей командой SuiteCRM я несогласен!
-
Во первых, я считаю, что все вопросы безопасности (доступ к данным) должны полностью решаться на backend. Со стороны frontend может быть все, что угодно, и доверия к этому никакого быть не должно. Поэтому все запросы данных (я имею введу примененный в 8-ке grapthql) должны обязательно проходить через “призму безопасности” на backend. Если учесть требования по реализации доступа к данным в реальных проектах, то это очень непростая задача…
-
Все валидации и взаимовалидации данных должны в обязательном порядке продублированы на backend, Не секрет, что в существующем дистрибутиве нет разграничения доступа по полям, но в реальных проектах он обычно требуется. Элементарный пример, при выборе в сделке состояния Отказ, поле Комментарий становится обязательным к заполнению. Это нужно реализовать на frontend, но потом обязательно проверить и на backend,
-
Все “серьезные” бизнес-процессы должны выполняться и контролироваться на backend. При этом на frontend желательно иметь возможность их настраивать и видеть текущее состояние.
-
Ну, и наконец, это выбор framework для реализации backend. Ребята выбрали Angular, спорить об их выборе дело неблагодарное, т.к. выбор в пользу angulag, react или vuejs источник частых holywars… От себя замечу, что angular неплохой выбор для систем класса enterprise, но порог вхождения в него достаточно высок, а разработка требует, в первую очередь, серьезных “архитектурных изысканий”… Для текущего класса системы, я бы выбирал между react и vuejs. Мы для себя выбрали vuejs.
Поэтому продолжаем развитие на базе 7-ки, как backend, и разрабатываем свой frontend.
Что же касается сравнения SuiteCRM с SalesForce, то это весьма непростое дело… Согласен, что у SalesForce есть готовый набор уже разработанных и хорошо отлаженных best practics и различных механизмов типа отчетов, но процесс доработки всего этого, крайне сложен и дорог… С другой стороны, разработанные и “применяемые на западе” best practics далеко не всегда (вернее, очень часто!) не подходят под наши современные реалии… Гораздо правильнее (IMHO) подсмотреть какие-то killer fitches в SalesForce и добавлять их постепенно в SuiteCRM.
Пост получился длинный, прошу прощения, но очень хотелось высказаться.