Ну это просто подача такая. Есть ещё, например, Бугаенко. Он в том же стиле пишет и тоже нельзя верить на слово (как впрочем и тем, кто пишет в менее уверенном стиле).
Про ORM не согласен. Да, запросы вида SELECT id; SELECT * WHERE id IN (1,2,3) — они не самые оптимальные, но, как правило, далеко не критично влияют на производительность. При этом такое поведение ORM даёт то, что можно выбирать ID из одной базы, а данные из другой:
Иногда это сильно упрощает жизнь при разрезании монолита на несколько частей по-честному (то есть без общей базы). У меня такое было.
Это позволяет выбирать ID из одной базы, а данные из другой. Например, ID из ElasticSearch, а данные из основной базы. У меня сейчас так работает на нескольких проектах.
Мы его сравниваем с хранением payload в Redis и походом в него. То есть гоняем только ID-шник сессии, например, в httpOnly cookie и всё. Например, так умеют стандартные сессии в том же PHP.
Ответ: конечно можно, но количество таких токенов будет существенно больше. Это увеличит объем потребляемой памяти, и замедлит запросы к БД. больше данных => медленнее поиск в БД.
В Redis поиск по ключу — это алгоритм сложности O(1). То есть не зависит от количества ключей и не замедлит запросы к БД.
Также Redis хранит данные довольно компактно и лимит по ключам на одном инстансе даже со скромным количеством памяти — десятки миллионов. Учитывая expiration, упереться в это вряд-ли получится для большинства сервисов.
Отсюда ещё раз вопрос: а так ли нужен JWT если инвалидировать токены нужно?
Армения облагает резидентов на их мировой доход, тогда как нерезиденты облагаются налогом на прибыль только с доходов, полученных из армянских источников.
Занятная реализация, но идея, к сожалению, вредная. Вы поощряете так охранительное поведение, которое подкрепляет важность тревоги. При этом экспозицией и вариациями КПТ с огромной вероятностью (под 70%) можно тревогу снизить почти в ноль.
В продакшне можно использовать пакеты, которые уже в релизе. Нет какой-то общей "стабильной версии". "Финал" будет выглядеть как пара шаблонов приложений со всеми стабильными пакетами и актуальным полным руководством.
Ну это просто подача такая. Есть ещё, например, Бугаенко. Он в том же стиле пишет и тоже нельзя верить на слово (как впрочем и тем, кто пишет в менее уверенном стиле).
Книги неплохие. Они заставляют подумать. Проблема не в книгах, а в фанатиках, которые бездумно воспринимают информацию и не проверяя верят ей.
@AmneziaAdept а можете списки IP/доменов/подсетей выложить у себя на GitHub чтобы проще было split tunnel настроить у себе через ваш клиент?
Так уже хуже, конечно.
Про ORM не согласен. Да, запросы вида
SELECT id; SELECT * WHERE id IN (1,2,3)— они не самые оптимальные, но, как правило, далеко не критично влияют на производительность. При этом такое поведение ORM даёт то, что можно выбирать ID из одной базы, а данные из другой:Иногда это сильно упрощает жизнь при разрезании монолита на несколько частей по-честному (то есть без общей базы). У меня такое было.
Это позволяет выбирать ID из одной базы, а данные из другой. Например, ID из ElasticSearch, а данные из основной базы. У меня сейчас так работает на нескольких проектах.
Да, в качестве эксперимента не подходит. Верно.
В моём случае профгигиена + плазмолифтинг + уход дали хороший результат.
В том и дело что попробовал. Сработало.
Что насчёт плазмолифтинга?
Мы его сравниваем с хранением payload в Redis и походом в него. То есть гоняем только ID-шник сессии, например, в httpOnly cookie и всё. Например, так умеют стандартные сессии в том же PHP.
В 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