В статье нужно было честно упомянуть закон сохранения энергии он же закон сохранения сложности и т.д. - у прощая в одном месте мы выносим сложность в другое место которое вы не описали - а это инфраструктура микросервисов
Будте ответственными и не дурите голову начинающим )

Я не понял - а зачем?
Нам и тут хорошо )

Во первых у большинства SameSite будет lax - а это crossorigin request
Во вторых SameSite <> SameOrigin https://jub0bs.com/posts/2021-01-29-great-samesite-confusion/

Сайты http://site1.publichoster.com и http://site2.publichoster.com будут признаны как SameSite и куки отлично будут передаваться между сайтами

Плюс не забываем что кроме сайтов запросы могут делать злобные школьники в консоли :)

update : Меня в комментариях резонно тыкнули в то, что уже лет пять проблема как фактически не актуальна, т.к. существует и поддерживается аттрибут SameSite. Резонно. Остаётся лишь вопрос к старым браузерам, где этой поддержки нет. Тут и тут есть описание проблемы и её решения.


Те кто так говорят не знают наверное, что означает samesite .
Те кто хостится на публичных доменах будут сильно удивлены когда будут успешно атакованы при помощи CSRF и при наличии у кук параметра samesite :))

Учитывая что человеку для "вхождение ы контекст" по исследованиям необходимо около 20 минут сколько человек тратит времени впустую в опенофисе когда его постоянно отвлекают вольно или не вольно!

По себе скажу, что я работал и в кабинетах с 3-5ю сотрудниками и в опеспейсах - во 2х продуктивность на уровне 30% максимум

Вообще то такие красивые и загадочные корабли были у нас и назывались они - ладья

А почему не привести ULID к формату UUID?
UUID по размеру во внутреннем представлении будет гораздо компактнее чем текст (16 байт против 26)

Статья по делу - это не микрооптимизация а правильная реализация алгоритма

Представляю при строительстве кирпичного дома рабочий кладет абы как кирпичи и раствор а на замечания прараба говорит : "что вы тут херней занимаетесь и микрооптимизациями - вы лучше следите за архитектурой а кирпичи же не зря придумали - оно как нибудь в конце постройки само оптимизируется" )))))

Про иммутабельность: расскажите это node когда при выполнении высоконагруженного сервиса у вас будет создаваться огромная куча в памяти для вот таких вот брошенных объектов на каждом шаге итерации, которая будет отжирать всю память и GC будет тратить кучу времени на ее очистку

Так и не удалось запустить - постоянно вылетает : cb.apply is not a function
Видно инструмент еще сырой

Полностью поддерживаю автора
Сам давно перешел на Medium и многие другие уходят (вот недавно и Вадим Макеев заявил что ушел с Хабра)

Что отталкивает:
- система диктата толпы причем не известного качества
(из своего опыта могу сказать что к сожалению наше сообщество разработчиков самое токсичное из всех в которых я общаюсь - столько злобы и оскорблений по техническим!!! решениям и предпочтениям я не видел нигде на иностранных площадках)

- никому не нужные ограничения - я понимаю количество звезд как в GitHub но минусы и связанные с ними драконовские ограничения - это архаизм!!!

- и последнее: если меня дискриминируют и позволяют оставлять лишь один комментарий в сутки - кому от этого хорошо?

в начале говорится что злоумышленник может чем-то завладеть, но к концу рассуждений они об этом полностью забывают - у юзера 2 токена - кто мешает их у него упереть ????
и вся стройная теория сразу не нужна!!!
нужна сложная биометрическая идентификация с ИИ для анализа состояния пациента - добровольно ли он снимает или под давлением - это вот будущее решение

спасибо за такой основательный обзор!
мы на пороге времени, когда мы будем отдавать хранение и обслуживание данных ИИ
И соответственно взаимодействие b2b будет сводится к взаимодействию ИИ этих компаний

ИИ в разработке приложений отстает )
традиционные приложение - это тоже уже анахронизм - управление голосом мыслями и визуалами - за этим будущее и тут нужны наработки которые бы были не простыми нейронками а ИИ понимающем смыслы

https://github.com/google/zx/discussions/237

все попытки использовать jsdocs и подобные с треском провалились из-за долгих танцев с бубном по форматированию всего этого описания и необходимости помнить сущности связанные с форматированием этих описаний

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

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

хотел бы сделать 2 возражения

- глупо обвинять javaScript в функциональщине - вообще-то это фукциональный язык и попытка имитировать на нем ООП приводит к оверхеду на инициализацию инстансов и property lookup через цепочки prototypes

- иммутабельность вас раздражает - ее требует от нас сам React!

можно почитать взвешенное давнее обсуждение плюсов и минусов обоих стейт-менеджеров
https://www.reddit.com/r/reactjs/comments/4npzq5/confused_redux_or_mobx/

и тут ссылки на обсуждения и статьи
https://github.com/markerikson/react-redux-links/blob/master/mobx-tutorials.md#mobx-and-redux-comparisons

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

предложу вам статью на подумать без эмоций
https://www.robinwieruch.de/redux-mobx

я бы сказал так - категорично заявлять о то что выбор redux странен в 21м году - очень странно!
думаю начинающих он раздражает в силу не способности его понять и осилить - это проблемы начинающих.

то к чему вы бегите с мобх предыдущие поколения проходили на Backbone - это старые грабли и от них бежали в redux - изучите историю и уроки

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

Если касаться темы статьи, то мне больше понравилась идея обработки бизнес логики в middleware и одно из решений
https://github.com/xnimorz/signal-middleware

Мне очень понравилось. Спасибо!
Обязательно пишите еше!