SK
Насколько большое?
Для чего полегче делать?
Для чего полегче делать?
у меня нет точных данных, но по тем что есть несколько миллионов запросов в сутки
Size: a a a
2021 March 05
SK
в админке разные типы пользователей, файрвол, гарды и прочее. в ядре только один ендпойнт без авторизаций и прочего. Поэтому подумалось, что для ядра будет много лишнего инициализироваться
SK
в целом спасибо за мнения! с вашей помощью я понял, что пошел по неправильному пути. буду переделывать архитектуру так, что ядро будет использовать свою базу, где будет только нужная для ядра инфа в денормализованном виде. Нужные для работы ядра данные, будут публиковаться в базу ядра по сигналу из админки
BT
в админке разные типы пользователей, файрвол, гарды и прочее. в ядре только один ендпойнт без авторизаций и прочего. Поэтому подумалось, что для ядра будет много лишнего инициализироваться
сделай разные точки входа, если слишком хочется
BT
в целом спасибо за мнения! с вашей помощью я понял, что пошел по неправильному пути. буду переделывать архитектуру так, что ядро будет использовать свою базу, где будет только нужная для ядра инфа в денормализованном виде. Нужные для работы ядра данные, будут публиковаться в базу ядра по сигналу из админки
это уже лучше, да
SK
сделай разные точки входа, если слишком хочется
что имеется в виду?
JK
в целом спасибо за мнения! с вашей помощью я понял, что пошел по неправильному пути. буду переделывать архитектуру так, что ядро будет использовать свою базу, где будет только нужная для ядра инфа в денормализованном виде. Нужные для работы ядра данные, будут публиковаться в базу ядра по сигналу из админки
Я бы сливал всё в один проект.
Гарды и тд. можно инициализировать только в нужных endpoint-ах. Для админки /admin для ядра своё.
Ну немного контейнер распухнет, но врядли это будет узким горлышком под нагрузками.
Гарды и тд. можно инициализировать только в нужных endpoint-ах. Для админки /admin для ядра своё.
Ну немного контейнер распухнет, но врядли это будет узким горлышком под нагрузками.
JK
Кроч ранняя оптимизация это зло )))
SK
Кроч ранняя оптимизация это зло )))
ха-ха, точно )
BT
что имеется в виду?
несколько index.php и каждый подстраивать
но да, тот вариант, к которому ты пришел - наиболее правильный
но да, тот вариант, к которому ты пришел - наиболее правильный
SK
спасибо!
,
Дратути, народ, хелп. Есть приложение на SF 4.4, появилась необходимость запустить "почти такое же" в другом месте. Грубо говоря был APP_ENV = prod, стал APP_ENV = prodA, prodB, они отличаются реализацией некоторых сервисов.
Можно загружать разные services.yml
prodA:
app.foo_service:
class: Services\A\FooService
prodB:
app.foo_service:
class: Services\B\FooService
Так типа работает, но приходится лазить в контейнер за app.foo_service.
Можно загружать разные services.yml
prodA:
app.foo_service:
class: Services\A\FooService
prodB:
app.foo_service:
class: Services\B\FooService
Так типа работает, но приходится лазить в контейнер за app.foo_service.
,
А вот куда копать, если я хочу использовать аннотации? Например чтобы следующий код
__construct(FooService $foo) {...}
понимал какую реализацию FooService использовать в том или ином APP_ENV?
__construct(FooService $foo) {...}
понимал какую реализацию FooService использовать в том или ином APP_ENV?
JK
МФ
Дратути, народ, хелп. Есть приложение на SF 4.4, появилась необходимость запустить "почти такое же" в другом месте. Грубо говоря был APP_ENV = prod, стал APP_ENV = prodA, prodB, они отличаются реализацией некоторых сервисов.
Можно загружать разные services.yml
prodA:
app.foo_service:
class: Services\A\FooService
prodB:
app.foo_service:
class: Services\B\FooService
Так типа работает, но приходится лазить в контейнер за app.foo_service.
Можно загружать разные services.yml
prodA:
app.foo_service:
class: Services\A\FooService
prodB:
app.foo_service:
class: Services\B\FooService
Так типа работает, но приходится лазить в контейнер за app.foo_service.
зачем лазать за app.foo_service?
если аргументом в нужные сервисы вы передаете app.foo_service
если аргументом в нужные сервисы вы передаете app.foo_service
МФ
YouGeneralService:
arguments: ['@app.foo_service']
соответственно в youGeneralService в конструктор придет разный в зависимости от окружения
arguments: ['@app.foo_service']
соответственно в youGeneralService в конструктор придет разный в зависимости от окружения
ПГ
Дратути, народ, хелп. Есть приложение на SF 4.4, появилась необходимость запустить "почти такое же" в другом месте. Грубо говоря был APP_ENV = prod, стал APP_ENV = prodA, prodB, они отличаются реализацией некоторых сервисов.
Можно загружать разные services.yml
prodA:
app.foo_service:
class: Services\A\FooService
prodB:
app.foo_service:
class: Services\B\FooService
Так типа работает, но приходится лазить в контейнер за app.foo_service.
Можно загружать разные services.yml
prodA:
app.foo_service:
class: Services\A\FooService
prodB:
app.foo_service:
class: Services\B\FooService
Так типа работает, но приходится лазить в контейнер за app.foo_service.
Services\FooService (Или интерфейс):
class: Services\B\FooService
class: Services\B\FooService
,
зачем лазать за app.foo_service?
если аргументом в нужные сервисы вы передаете app.foo_service
если аргументом в нужные сервисы вы передаете app.foo_service
Там всё сложно, легаси-приложение, в "старую" часть которого проброшен контейнер Symfony, из которого оно достаёт сервисы из "новой" части
МФ
Там всё сложно, легаси-приложение, в "старую" часть которого проброшен контейнер Symfony, из которого оно достаёт сервисы из "новой" части
ну ок, что тогда значит "лазать"? если уже лазает
,
Ну хотелось бы в новой не лазить :)