Приложение масштаба предприятия на Symfony?

Question

[Станислав Шендаков]

Добрый день.
На Хабре нашел ссылку на статью:
Symfony modular, microservice-ready architecture. ...
и
Часть 2
Репозиторий

Интересует мнение о самом подходе автора. Он изменил файловую структуру проекта на Symfony 6, разделил фронтенд( у автора Angular ) от бэкенда( REST API ), на бэкенде определил структуру приложения с разбиением на модули, даже БД разделил по принципу минимально необходимых данных для каждого модуля, даже ценой денормализации данных и.т.д. Каждую свою мысль автор сопровождает теоретическими предпосылками и вроде как, даже логично. Вопрос: насколько данное решение соответствует современным тенденциям при построении приложения уровня предприятия? Нахожусь на распутье. Требуется: переписать ERP уровня небольшого машиностроительного предприятия, WEB-интерфесом которой пользуются все службы предприятия, от отдела кадров и производства, до кладовщиков, работников ОТК и.т.д. Используется самописанная и не слабонервных CMS ( PHP + JavaScript ), MySQL, ~ 150 пользователей одновременно, > 100 таблиц. На фронтенде уже значительно позже начали использовать JQuery, до этого vanilla JS, новый PHP-код писали уже с применением ООП и PSR. Тонны в худшем проявлении китайско-индусского кода, полное пренебрежение всеми правилами и принципами программирования, никаких CSS, все стили прописаны, как style="background-color:red" и.т.д. Собираюсь уже достаточно давно, откладывал по разным причинам, только сейчас, собственно, начал собирать все данные в кучу, поддерживать ЭТО стало слишком муторно, балласт слишком тяжел. Сначала хотел взять Symfony as is, как говорится, с Twig и Doctrine, прикрутить фронтенд с Encore и VueJS, создать Entities, написать нужные сервисы и.т.д. А потом прочел упомянутую статью. Просьба специалистам по Symfony прокомментировать-покритиковать данную статью, посоветовать, что из неё можно взять на вооружение, а что есть не самое удачное решение автора, ну и общее видение предпочтительных решений описанной задачи.
Спасибо.

Answer 1

[Леонид]

гемор создания ERP это сложность реализации самой ERP
какой там язык вопрос десятый

использование такого сложного фреймворка как synfony только осложняет дело

использование javascript фреймворков нафиг не нужных а в таких приложениях это дополнительных гемор

ну написал некто на хабре что он так сделал и что? мало ли кто как делает

Comments

[Дмитрий Свиридов]

использование такого сложного фреймворка как synfony только осложняет дело

Не очень понял. Почему?

[Станислав Шендаков]

+1. Поясните? Там имеются достаточно сложные по UI страницы. По выбору фреймворка мысль только одна, как это все поддерживать. Изобретать свой велосипед и тягаться с Fabien Potencier я точно не стану, а поддерживать имеющийся, с квадратными колесами, написанный идиотом-мизантропом я тоже не хочу. :-D Мой напарник время от времени выкладывает куски кода на https://www.govnokod.ru и получает восторженные отзывы. :-) Начальник набрал людей для постройки новой системы на базе 1С-ERP, но я сильно сомневаюсь, что у них что-то получится в приемлемые сроки и с приемлемым качеством. Они больше года что-то там пилят, но я пока ничего вразумительного не увидел. Только бесконечные совещания, да какие-то "сферические" планы-диаграммы. Symfony был выбран именно потому, что он изначально позиционируется, как фреймворк для крупных приложений, как фреймворк, где наговнокодить тупо сложнее, ну и как фреймворк знание которого позволит отсеять аникейщиков уже на этапе найма.

[Леонид]

symfony фреймворк с достаточно высоком порогом входа - а значит дорогой в поддержке

что касаеться UI ну так это зависит от того как оно спроектировано

не обязательно лепить все на одной странице кк было принято в прогах на делфи 20 лет нахад

особенно с учетом того что нет смысла городить веб приложение ечли не работать с ним с мобильных девайсов
И как вы запихнете туда сложный UI без того чтобы пользак вас потом не материл за неудобство работы если он не может гарантировано попасть пальцем в ундную позиции в накоаной

Но самое сложное при реализации ERP это реаизация самой ERP то есть бзнес логики - никакой фреймворк и никакой UI вам тут не поможет.

У меня есть опенсорс проект - учетгная система уровня малого предприятия - большинство прорблем это не какой там UI а какого хрена при проведении возвратной накладной сумма ен папада в кассу или почему отчет за три месяца не показал все до копейки по тыще документов и складских проводок. Да и UI вы будете делать не какой захотите а "а наша бухгалтер так привыкла за 50 лет работы"

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

вообще с темой какой фреймворк и какой говнокод носятся обычно неопытные разрабы с юношескими понтами, меряющиеся пипискамим у кого круче код. С такими проект уровня предприятия даже начинать не стоит

[Станислав Шендаков]

Леонид, я обязательно учту Ваше мнение при принятии окончательного решения. :-) Когда человек пишет: "что касаеться", то у меня возникают большие сомнения в квалификации такого специалиста. :-) Лично от Вас, ни чего-то полезного, ни даже просто чего-то вразумительного, я не услышал. Я задал конкретный вопрос. В какой части моего вопроса я интересовался кому за что стОит браться, а кому нет?

[DevMan]

Леонид, использование симфони осложнит поддержку только новоделам, выросшим на курсах.
а энтерпрайз кровавый симфони как раз уважает.

[Леонид]

DevMan, ентерпрайз не задает тут вопросов на чем мне написать

и вообще использует для приложений маciтаба предприятия более подходящие стеки типа java или .NET

[DevMan]

Леонид, оуу... заявка на победу: здесь только нищеброды, заслужившие отстой.

[FanatPHP]

Станислав Шендаков, а какая связь между вопросом и этим комментарием?
Система уже есть и уже пишется год на симфони, а вы в поисках серебряной пули, которая превратит нынешний говнокод в конфетку?

Answer 2

[galliard]

Ну, если решитесь на такую архитектуру - тщательно скрывайте от других разработчиков свое место жительства))

Но лучше все-таки использовать стандартную архитектуру симфони, и уже в контроллерах/сервисах/дто можно раскладывать классы в поддиректории.

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

Comments

[Станислав Шендаков]

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

[galliard]

Станислав Шендаков, ну шутка такая есть: "пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте".

Нет, у него не так сделано. У него все запихано в один репозиторий. Какая разница, какой там порт?

[Станислав Шендаков]

Бэкенд запускается как:
symfony server:start --no-tls
и доступен на стандартной для Symfony странице-заглушке, по которой видно, что сервер завелся:
localhost:8000

Клиент запускается как:
npm run start-with-backend
и доступен уже собственно, как приложение на
localhost:4200

Серверы я запускал в разных окнах консоли. Серверы разные и на разных портах. Останавливаешь любой из них и вся система падает. Разве это, по сути, не разные приложения? О каком общем репозитории Вы говорите? Я может в самых основах чего-то недопонимаю?

[galliard]

Станислав Шендаков, разные git-репозитории я имею ввиду.

Answer 3

[Владимир Коротенко]

По моему имху такого плана приложение писать стоит на ларавеле, фронт vue, react, angular. Если же конечно не перейти на другой язык на бэке

Comments

[Дмитрий Гординский]

Любопытно, почему считаете Laravel более подходящим?

[galliard]

Дмитрий Гординский, потому что он знает ларавель и не знает симфони, очевидно же.

[Владимир Коротенко]

galliard, что было бы если бы я посоветовал GO или NET 6 ?
Я просто выбрал наимее "жирный" из mvc фреймворков для php

[galliard]

Владимир Коротенко, тогда бы я подумал, что вы знаете GO или NET 6 и не знаете symfony. Вы же никак не обосновали свое мнение. А "жирный" - понятие очень и очень размытое.

[Владимир Коротенко]

galliard, Видимо, стоит, хотя бы, спрашивать что имел собеседник в виду.
И кстати да я несколько недолюбливаю php движки

[galliard]

Владимир Коротенко, ну вот видите, даже спрашивать не пришлось)))

[DevMan]

Владимир Коротенко, а ничо что симфони как раз менее жирный лары?
и я несколько недолюбливаю дотнет, но разве это делает его плохим?

Answer 4

[Evgenii Borovoi]

Писать надо на том, что лучше знаешь. Если нет опыта в symphony то переделать такое легаси и одновременно учить - будет очень сложно. Сам по себе фреймворк не решает проблемы.
Вообще тут две разных задачи - фронт и бэк.
По бэку - зависит от того, насколько грамотно база данных сделана. Если она правильно нормализована - то без разницы, по большому счету, какой фреймворк. Я бы как в комментах выше предложил laravel все-таки. С непривычки доктрина в симфони тот еще зверь. Лично я в некоторых проектах подключал eloquent из laravel отдельно (библиотека работы с бд).
А про фронт - надо смотреть как запросы сделаны. Если более-менее норм, можно вообще вначале на vuejs сделать как надо (ну или на чем-то другом, просто это самый простой). А потом уже с бэком решать. Встроить vuejs в симфони\ларавел не проблема.

Answer 5

[rorc]

Приложения масштаба предприятия пишутся на Symfony очень легко и удобно, в одиночку примерно за 2-3 месяца.
Но с одним огромным примечанием - опыт работы и знание фреймворка.

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

Какие сложности возникнут:
1 - перенос текущих таблиц и данных, нормальный генератор для доктрины убили несколько версий назад.
2 - готовых пользователей можно сказать нет, есть минимальный функционал, который нужно расширить.
3 - проработка структуры url адресов, прав доступа, преобразования данных.

По стилю кода внутри страницы style="background-color:red", это ни о чём не говорит, если не знать полностью историю, возможно сроки поджимали, фронт разработчика не было или запланировали, а их уволили.

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

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