Ответ: конечно можно, но количество таких токенов будет существенно больше. Это увеличит объем потребляемой памяти, и замедлит запросы к БД. больше данных => медленнее поиск в БД.
В Redis поиск по ключу — это алгоритм сложности O(1). То есть не зависит от количества ключей и не замедлит запросы к БД.
Также Redis хранит данные довольно компактно и лимит по ключам на одном инстансе даже со скромным количеством памяти — десятки миллионов. Учитывая expiration, упереться в это вряд-ли получится для большинства сервисов.
Отсюда ещё раз вопрос: а так ли нужен JWT если инвалидировать токены нужно?
Армения облагает резидентов на их мировой доход, тогда как нерезиденты облагаются налогом на прибыль только с доходов, полученных из армянских источников.
Занятная реализация, но идея, к сожалению, вредная. Вы поощряете так охранительное поведение, которое подкрепляет важность тревоги. При этом экспозицией и вариациями КПТ с огромной вероятностью (под 70%) можно тревогу снизить почти в ноль.
В продакшне можно использовать пакеты, которые уже в релизе. Нет какой-то общей "стабильной версии". "Финал" будет выглядеть как пара шаблонов приложений со всеми стабильными пакетами и актуальным полным руководством.
Смотря какие требования у проекта. Большая часть пакетов Yii3 уже стабильна, но некоторые ещё нет. Если у вас наберётся много тех, что нет, то у вас два выхода:
Ждать. Так делает большинство.
Использовать для них dev-master или фиксануться на определённой версии и иногда чинить. Так многие делают в нашем чатике в телеграме.
Необоснованно я никогда ни на кого не набрасывался. Минусы того же Laravel подсвечивал, плюсы тоже подсвечивал и каждый раз обосновывал и показывал примеры. Фрейворка-идеала нет и не будет — что Laravel, что Symfony, что Yii — все разные и у всех есть и сильные и слабые стороны.
Я так понял, посыл в том, чтобы не выдумывать своё, а всем сделать открытых штук типа https://imgproxy.net/ или https://www.yiiframework.com/ вложившись туда вскладчину и тем самым повысив и стабильность платформы, на которой выстроено несколько компаний и ещё и сэкономить прилично.
В Redis поиск по ключу — это алгоритм сложности
O(1). То есть не зависит от количества ключей и не замедлит запросы к БД.Также Redis хранит данные довольно компактно и лимит по ключам на одном инстансе даже со скромным количеством памяти — десятки миллионов. Учитывая expiration, упереться в это вряд-ли получится для большинства сервисов.
Отсюда ещё раз вопрос: а так ли нужен JWT если инвалидировать токены нужно?
businessDaysBetween(a, b)?Резидентство определяется не как в РФ, если что.
Всё так. В принципе, это очень логично для создателей фреймворка.
Symfony в последних версиях предпочитают PHP: https://tomasvotruba.com/blog/2020/07/16/10-cool-features-you-get-after-switching-from-yaml-to-php-configs/
Нет. У трейтов в PHP состояния как у миксинов в руби нет.
Занятная реализация, но идея, к сожалению, вредная. Вы поощряете так охранительное поведение, которое подкрепляет важность тревоги. При этом экспозицией и вариациями КПТ с огромной вероятностью (под 70%) можно тревогу снизить почти в ноль.
В продакшне можно использовать пакеты, которые уже в релизе. Нет какой-то общей "стабильной версии". "Финал" будет выглядеть как пара шаблонов приложений со всеми стабильными пакетами и актуальным полным руководством.
Bootstrap вот: https://github.com/yiisoft/yii-bootstrap5. Для react и других фрейморков: https://github.com/yiisoft/assets
Спасибо.
Переводы атрибутов тоже есть?
У меня обратный опыт. Сначала валидируется фронт чтобы бэк не грузить. Потом бэк. А что за бандлы? Очень интересно глянуть, как это решено.
https://github.com/yiisoft/validator/blob/master/docs/guide/en/result.md#errors
Посмотрел. Да, хороший компонент. По фичам почти сходные.
Отличия валидатора Yii от Symfony Validator:
Есть контекст у валидатора поля. То есть можно легко валидировать, например, "повторить пароль" или валидировать город по указанной стране.
Перевод сообщений из коробки, в том числе имён атрибутов.
Экспорт правил в виде массивов для frontend / CMF.
Удобные способы получать сообщения об ошибках в разных форматах.
Стиль именования.
Код несколько проще.
Не понял, как у Symfony validator посмотреть покрытие тестами. Но вроде их там не мало. У нас 100% + 100% MSI.
Чего нет:
Возможности задать уровень ошибки, https://symfony.com/doc/current/validation/severity.html
Специфичных конкретных правил валидации (но это добавить проще некуда, к тому же https://github.com/yiisoft/validator/blob/master/docs/guide/en/extensions.md#wrapper-for-symfony-rules).
Надо посмотреть, что там в Symfony Validator чтобы нормально сравнить...
Смотря какие требования у проекта. Большая часть пакетов Yii3 уже стабильна, но некоторые ещё нет. Если у вас наберётся много тех, что нет, то у вас два выхода:
Ждать. Так делает большинство.
Использовать для них dev-master или фиксануться на определённой версии и иногда чинить. Так многие делают в нашем чатике в телеграме.
Поправил.
Да ну?
Необоснованно я никогда ни на кого не набрасывался. Минусы того же Laravel подсвечивал, плюсы тоже подсвечивал и каждый раз обосновывал и показывал примеры. Фрейворка-идеала нет и не будет — что Laravel, что Symfony, что Yii — все разные и у всех есть и сильные и слабые стороны.
Не позволяет :(
Есть альтернативы?
Я думал что только @roxblnfk такое по нраву. Мы рассматривали это для Yii3, но всё-же решили что пойдём по классике с
require.Я так понял, посыл в том, чтобы не выдумывать своё, а всем сделать открытых штук типа https://imgproxy.net/ или https://www.yiiframework.com/ вложившись туда вскладчину и тем самым повысив и стабильность платформы, на которой выстроено несколько компаний и ещё и сэкономить прилично.