Konstantin
по одной время будет сопоставимо с ручным описанием
Konstantin
а качество - нет :)
Evgeniy
Всем привет! Есть ли альтернатива CollectionType? Типа как ArrayField в EasyAdmin?
Evgeniy
Или другой вопрос. Можно ли наследоваться от CollectionType и переписать метод, который отображает форму? Потому что найден баг. Вот ишу https://github.com/EasyCorp/EasyAdminBundle/issues/5207
Ivan
Всем привет!
Подскажите пожалуйста, как вы работаете с symfony и docker-compose, когда у вас приложение например делится на frontend, backend(админка), и api, и они как бы через host разделены.
Например: example.com, backend.example.com, api.example.com.
Настройки доменов вынесены в .env и применяются в конфигурации нэймспейсов контроллеров:
FRONTEND_HOST=http://example.com
BACKEND_HOST=http://backend.example.com
API_HOST=http://api.example.com
При настройке пробовал использовать разные порты под разные хосты, но это не работает. Symfony не учитывает порт в хосте.
Нормально получается если пойти и прописать у себя в /etc/hosts тестовые домены и использовать их при разработке:
127.0.0.1 example.com backend.example.com api.example.com
Кажется решение каким-то не очень правильным.
Как альтернативу вижу еще возможность вынести prefix из конфигурации неймспейсов так же в .env,
FRONTEND_PREFIX=
BACKEND_PREFIX=/backend
API_PREFIX=/api
Тогда в теории должно работать так:
http://127.0.0.1/ для frontend
http://127.0.0.1/backend/ для backend
http://127.0.0.1/api/ для api
Если в конфигурации не указать хосты, а указать только префиксы, то должно работать. Но получается достаточно далеко от реализации на проде, что тоже плохо.
Подскажите, какие практики используете вы сами и как лучше поступать?
Dmitry
Ivan
Получается, что localhost не только сам, но и любые поддомены к нему так же ссылаются на машину?
Честно говоря не знал, спасибо. Так обычно используют?
Обратил внимание, что у меня localhost ссылается на 127.0.0.1, а поддомены к нему уже на ip6-localhost (::1), нюанс, но всё же.
Алексей
форнт, бэк, апи это разные контейнеры и у них разные ip?
Ivan
Один контейнер
Ivan
с php-fpm внутри
Алексей
В первом проекте делал фронт и бэк на одном симфони проекте и роуты разделял по домену * host="{domain}", * defaults={"domain"="admin.%app.domain%"},
В след проекте делаю разные симфони проекты для админки, апи и витрины
Ivan
В первом проекте делал фронт и бэк на одном симфони проекте и роуты разделял по домену * host="{domain}", * defaults={"domain"="admin.%app.domain%"},
В след проекте делаю разные симфони проекты для админки, апи и витрины
Ну по сути я иду по первому варианту, просто хосты указаны сразу на неймспейсы и не требуется прописывать их в каждом роуте отдельно.
Ivan
По поводу разных проектов мне не очень понятно как оно должно работать. Кодовая база одна, и будет дублироваться на каждом их симфони проекте?
Ivan
Или они все будут работать на АПИ?
Ivan
В данный момент планирую начать новый проект, где будет разделение даже на 5 частей, и вижу это так:
/src/Common/ - всё ядро системы
/src/Web/ - Frontend часть (example.com)
/src/Api/ - API часть (api.example.com)
/src/Studio/ - Studio часть (studio.example.com)
/src/Moderation/ - Moderation часть (moderation.example.com)
/src/Backend/ - Backend часть (backend.example.com)
Где весь основной код будет в Common, а в остальных папках большей части контроллеры и формы.
Покритикуйте пожалуйста мой вариант))
Ivan
Предложение заманчивое. А дальше ей работать через API часть или подключаться к БД за информацией? Кроме отображения контента, там планируется так же управление профилем с авторизацией и регистрацией.
Konstantin
чем меньше репозиториев, тем лучше. любая дополнительная связь - это проблемы и потраченное время. обновление у разрабов ("все фронтаны срочно обновите бэкенд, мы там выкатили новую авторизацию"), синхронные выкаты фич (фронт + бэк), багфикс - все это будет сжирать время и нервы разработчиков
Konstantin
делать микросервисы ради микросервисов (здесь примерно похожее предложение) точно не нужно
Konstantin
пока можете жить в одном репе организационно - лучше их не плодить
Andrei
Поддерживаю. Считаю что выделять что-то в микросервис стоит лишь когда это что-то нужно будет горизонтально масштабировать, или оно требует другого стека
Andrei
А так - лишние накладные расходы
Ivan
Спасибо за обратную связь!)
Konstantin
особенно бедным фронтендерам, им и так сложно живется в мире программистов, так тут еще заставляют деплоить бэкенд себе локально
Andrei
Ну насчет фронта - может и стоит в отдельную репу. это не микросервис. Но мы почему-то в свое время от этого отказались, я правда уже не помню почему.
Andrei
Какой то был затык важный
Konstantin
касаемо вопроса выше как фичи разделить: вынесите в параметры app.domain.frontend, app.domain.admin, app.domain.whatever и соответствующей группе контроллеров пропишите host в роуте. все, каждый контроллер работает на своем поддомене. причем в локальной копии они не обязательно различаются, могут все на одном локалхосте висеть
Konstantin
в продакшне/стейдже админы сами нарезали поддоменов по своим усмотрениям и со своими именами, в локале все висит на одном домене с одной записью в hosts. да, записи в hosts добавлять нормально
Ivan
Спасибо
Konstantin
если мысль про префиксы не покидает. не надо так делать, это неудобно будет админам. если они захотят какие-то acl на админку повесить, mtls auth, отправить админку на другую группу бэкендов итд итп, им это будет довольно неудобно. все вебсерверы больше любят правила основанные на домене, а не куске урла
Dmitriy
чтобы с cors не воевать можно вообще все на одном домене сделать
Dmitriy
/ - фронт, /api, /admin
Dmitriy
и монорепа
Konstantin
ну это сильно выебет голову эксплуатации, я вам точно говорю
Konstantin
префиксы эти
Dmitriy
как скажешь
Konstantin
разумеется, есть варианты с этим жить, но это ведет к неудобной конфигурации ингрес-сервера. придет в итоге к тому что в мейл.ру или яндексе - конфигу нжинкса на 20к строк (не метафора)
Konstantin
проще корс настроить, я вас уверяю, чем бороться с этими проблемами. банально раскидать по разным серверам/ип-адресам префиксы будет невозможно. а поддомены - тривиально
Konstantin
я бы послушал, конечно, с большим удовольствием очередного иксперта, но ей богу не очень сейчас удобно
Konstantin
особенно пункт про "раскидать разные префиксы по разным ip-адресам"
Konstantin
бля :) так как это сделать? можно мне пример?
Ivan
ну тут видимо nginx прокси должен стоять, и разными локейшена на разные апстримы
Konstantin
вы просто говорите с человеком, который руководит разработкой в компании, ежемесячный трафик который улетает за полпетабайта, поверьте, уж что-что, а нжинкс готовить мы умеем. и примерно понимаем как это делать так, чтобы не было больно в сопровождении
Ivan
но лучже же через днс разруливать такое
Konstantin
ну тут видимо nginx прокси должен стоять, и разными локейшена на разные апстримы
нет, речь о том, чтобы админку повесить на 10.1.2.3 - чтобы она была доступна только из впна, сайт закрыть клаудфлейром, а апи вынести на отдельный фронтенд-сервер и закрыть от трафика из зимбабве. примеры выдуманные, но вполне встречаются
Konstantin
если мы поставим один фронтенд перед своими сайтами, сделав там три блока location с рерайтами внутри, весь трафик будет приходить в один сервер, а дальше рулиться. плюс будет лапша правил внутри каждого локейшна
Konstantin
зато три блока server каждые со своими listen и тривиальным location / { proxy_pass http://upstream; } с другой стороны
Konstantin
нет, я ж говорю: разные правила обработки (обрабатывать /admin только для клиентов из приватной сети корпоративного впна)
Konstantin
и при любой ошибке в ацле та же админка не будет физически изолирована от публичных сайтов
Konstantin
я настаиваю что избыточно плодить лапшу из рерайтов потому что не смогли префлайт для корса настроить
Konstantin
так домен это виртуальная сущность, просто поле для роутера
Konstantin
оно ничем для #[Route] не отличается от path, scheme etc
Konstantin
никто не заставляет сразу на три сервера деплоить, обслуживайте в начале одним блоком server. просто когда потом понадобится, руки будут развязаны. хоть на разные поддомены разноси, хоть на разные группы серверов, хоть на разные репозитории
Konstantin
тут речь вообще больше за эксплуатацию этого добра
Юра
Главное не переборщить и не дойти до микрофонтендов
Konstantin
а шарить код (модели, конфиги, сервисы) между сайтом, админкой, партнеркой, что там еще бывает - утомительно. грубо говоря, одну таблицу в базе надо в трех местах описать. а потом еще синхронно обновить так чтобы везде новое поле вместе приехало. это гемор на ровном месте, граница микросервиса - это его база. если три независимых сервиса ходят в одну базу - ура, вы дурак
Konstantin
а вы чот типа того и предлагаете. я еще понимаю фронтенд (жс-цсс) там оторвать от серверного кода, иногда это оправдано. но админку условного блога от него самого - треш
Konstantin
ну вот блог есть. сайт показывает посты, тэги там. админка их редактирует, добавляет там, удаляет. это одна база
Konstantin
я не знаю как от интернет-магазина оторвать админку в другую базу кроме содомии всякой
Юра
Просто надо делать SPA и не будет таких проблем
Konstantin
ну либо мы о разном, но я пять раз ваши предложения перечитал и другого вывода не могу сделать
Konstantin
Просто надо делать SPA и не будет таких проблем
так админку от апи он тоже оторвать предлагает, а это тоже одна база
Юра
Видимо фронт админки
Юра
Типо симфа это рест апи, а админка это фронт
Юра
Ну у меня так
Dmitriy
вы просто говорите с человеком, который руководит разработкой в компании, ежемесячный трафик который улетает за полпетабайта, поверьте, уж что-что, а нжинкс готовить мы умеем. и примерно понимаем как это делать так, чтобы не было больно в сопровождении
я вам советую свой кейс не натягивать везде и всегда, проекты бывают разные
Konstantin
да я этих кейсов многовато уже повидал. я ж не настаиваю, просто озвучил проблемы о которых мало кто думает, тк мало кто админит свои проекты и не осознает всю проблематику
Konstantin
есть проблемы роста, которые можно сгладить сейчас, изначально не расставляя себе грабли
Dmitriy
да с этими проблемами про которые вы так яро вещаете, столкнется далеко не каждый проект
Konstantin
актуально ли это конкретно вам - решать вам
Dmitriy
станет больно в проекте - переделается, не вижу никаких проблем
Dmitriy
а закладывать сразу типа на будущее - это еще хуже
Konstantin
не всегда это возможно/дешево. например, на ваши урлы завязано пять миллионов инсталлов мобильного аппа, что забывают обновлять. или партнеры какие из фин-сектора, которым пять строчек чтобы поменять, нужно год согласования получать
Юра
Такой хайлоад мне совесть не позволит делать на симфе )
Konstantin
так-то понятно что большинство клепает сайты-визитки или типа того, так там и ооп не нужно, и базу можно проектировать как бог на душу положит, и выложить это все так же. но мы тут вроде серьезные люди, говорим о том как правильно делать, а не "да пох я фрилансер, че мне париться"
Юра
Too much CPU utilisation
Konstantin
бэкенд может поменяться, а урлы - нет :)
Юра
Я видел как бек писали модулями для нгинкса на С
Юра
Вот это было хардкор
Dmitriy
так-то понятно что большинство клепает сайты-визитки или типа того, так там и ооп не нужно, и базу можно проектировать как бог на душу положит, и выложить это все так же. но мы тут вроде серьезные люди, говорим о том как правильно делать, а не "да пох я фрилансер, че мне париться"
вас бросает из стороны в сторону.. с одной сайты визитки, с другой дикий хайлоад в петабайт
Dmitriy
а посередине ничего нет да?