Я бы сказал, что это в принципе проблема смены парадигмы, стейт больше не умирает при завершении запроса и много кода может быть банально не готовым к такому повороту вещей. Надо задумываться о куче вещей сразу, чистить идентити мапы доктрины, всякие временные кэши. Весь код, который работает на статиках или глобалах здесь сразу подвержен уязвимостям, потому что в целом простым решением было бы переинициализировать контейнер (его содержимое), чтобы весь сервисный стек был создан заново. Но со всякими синглтонами такое не проканает. Зная любовь лары к статик колам, не удивлюсь, что проблема, действительно, именно там

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

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

Например приложение на фуллстек симфони позволяет выкинуть практически что угодно. Хочешь свой роутинг — легко. Другой ORM\DBAL? запросто! Технически реально поменять даже имплементацию контейнера. Это потребует ручной загрузки бандлов, т.к. многие из них пользуются тем, что есть стадия компиляции, но это в целом реально.

что в вашем понимании микрофреймворк? для запуска проекта на симфони вам достаточно (в исходниках) иметь три файла — composer, kernel и index.php, каждый на несколько строчек

Полагаю потому, что аннотации так или иначе надо извлекать в рантайме для работы с ними (пусть сейчас это и удобней и является частью синтаксиса\стандартной библиотеки). А аксессоры должны работать, полагаю, на этапе преобразования в байткод (чтобы сформировать правильные методы и уровни доступа).

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

btw, одна из лучших, на мой взгляд, статей для понимания того, зачем вообще нужен фреймворк и как работает симфони — это вот эта серия

symfony.com/doc/current/create_framework/index.html

по факту как раз рассказывает как слепить свой фреймворк на базе симфонёвых компонент

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

Вообще да, но мы же сейчас про конфигурацию роутинга говорим

Вы так говорите, как будто в остальных местах лара проповедует SOLID
laravel.com/docs/8.x/validation#manually-creating-validators
Фасад на фасаде.

Во всех laravel-проектах, с которыми я сталкивался, роутинг конфигурируется через фасады, будь они не ладны

Поэтому для меня laravel — это некоторый yii на стероидах. Да, модные компоненты. Но статика, магия, рантайм конфигурация…

app()-> — ничем не лучше в данном случае ) наличие таких вещей означает, что у вас в памяти где-то есть глобальный или статический объект, который вы получаете вызовом данной функции для доконфигурации. Фактически это синглтон. Чем плох синглтон я надеюсь можно не объяснять.

Я про Router::get. То, что описано как контроллер — технически может быть чем угодно, да. Может быть стат. методом, может быть парой сервис-идентификатор + метод итд. Тут нормально все.

Локаль можно и в симфони выше вынести, там есть импорты ресурсов с префиксом. А вот насчет того, делают ли статик колы «лучше» — можно очень долго холиварить

Если вы про «отрефакторить код фреймворка» — то с 5.2 все изкоробочные конфиги — на php

github.com/symfony/symfony/tree/5.2/src/Symfony/Bundle/SecurityBundle/Resources/config

А если вы про свой код (который под вашим управлением), то вы были вольны держать его в php формате уже несколько лет как. Если вы держали его в ямле — ну, значит, видимо, вы приняли такое решение зачем-то.

symfony.com/doc/2.8/configuration/configuration_organization.html
на вскидку в документации к 2.8 уже были вкладки yaml\xml\php в документации, так что можно было оформлять конфиги в любом удообном вам формате

Аннотации — никто никогда не заставлял пользовать тоже на самом деле. Все можно описывать в тех же конфигах.

Поэтому и говорят, что он мощный. Просто далеко не все осознают что поменять можно почти все.

Одно из немногих изменений в симфони за последнее время, которое встретило реально негативную реацию в моих кругах.

.env активно используется другими тулами, которые не умеют в те же механизмы, что сделали в симфони. Например .env автоматически подхватывается docker-compose и коммитить локальные изменения для докер-композа (например мы тюним работу с xdebug под личные предпочтения и настройки окружения) — это как-то фу.

Слава богу это сугубо опциональный механизм и его можно имплементировать как хочется, в т.ч. старым способом

Существуют всякие оптимизации, позволяющие срезать углы. Например можно подменить ваш коннект к БД и провести весь тест в транзакции, которую потом просто откатить. Это быстро.

Но как и любое срезание углов должно быть пользовано с умом. Например с такими штуками нельзя запускать процессы, мутирующие БД вне процесса тестирования (например симулировать запуск крон команды в шелле или дернуть реальный контейнер с приложением по API).

А так все по классике пирамиды тестирования. Чем больше тест приближен к реальному использованию — тем он сложней и дороже запускается.

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

А можно, пожалуйста, подробней? давно хотел себе ноут на прошку перевести

Ничего не мешает хранить данные в формате «пользователь-ключ=>значение» (три колонки). И альтеры делать не надо и индексы работают и чистить легко и работать удобно. В мемкэше, полагаю, вы данные храните примерно так же, только там можно настроить какой-нибудь expire (который в БД можно реализовать тоже).

> Выдавать доступ к такой базе мы точно не можем, так как помимо тестовых пользователей там хранятся и реальные
Ну, в таком случае, да — надо писать свой интерфейс. При этом как реализовано хранилище опций, кажется, не сильно принципиально.

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

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

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

Если отбросить в сторону то, что база не очень быстрая, то поинт с базой был в том, что там значение одно на всех пользователей. Получается что вполне себе можно хранить на каждого пользователя свое значение и в бд (раз можно в мемкэше). Второй поинт был о том, что нужно следить за доступами. Для этого фактически вы написали свой API, через который и следите за правами. но с тем же успехом, опять же, можно выдавать права на одну конкретную таблицу в БД конкретным людям.

Я не то чтобы набрасываю, идея клевая, на больших масштабах и если вернуть тезис про тормозную БД — очень даже интересная. Просто я о том, что вводные о том, зачем это было сделано выглядят притянутыми за уши. Звучит так: «У нас были вот такие проблемы со старым подходом. Но мы не стали их решать, а написали новую систему, где учли их заранее».

Там есть еще большая светлая идея с rollout (ну типа можно раскатать новую опцию только на 5% пользователей), но реализовано это все настолько топорно, что действительно проще сделать руками.

Плюс тема вообще не раскрыта. ретивер упоминается к статье про A\B тестирование, в которой есть все про пример использование библиотеки и ничего про собственно тестирование. Ни про анализ результатов (нужно же как-то фиксировать изменение каких-то метрик для понимания результатов экспериментов). Ни про анонимных пользователей (sticky session или еще чего).

По факту так и получается, да. Есть библиотека, где "$userId % $numOfVairants" и статья про «смотрите, я написал сервис дефиниш для библиотеки».

P.S. Потом я таки посмотрел кто автор статьи и понял что это автор библиотеки…

Мне больше интересна формулировка

Независимый от фреймворка DI-контейнер

У нас sf/di 4 подключен к, прости господи, второму зенду, и все работает «независимо от фреймворка»

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

Данные об авторе рядом со статьей, теги тоже как часть статьи

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

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

У вас же на ровном месте на старте проекта есть какие-то кроны и обновления, даже если у вас всего 5 записей в БД.