🖼️ Node v20.17.0 (LTS) Iron

1. module: support require()ing synchronous ESM graphs
2. path: add matchesGlob method
3. stream: expose DuplexPair API
And more...

https://nodejs.org/en/blog/release/v20.17.0

✔️ Как в JavaScript/TypeScript реализуется SoC (separation of concerns) и для чего он нам?

Вы наверняка видели код, в котором на событиях или на роутах висит обработчик, который содержит и часть бизнес-логики и обращение к базе и работу с сетью. Такой портянка-код характерен для чат-ботов и серверов. Как это можно написать иначе и как в этом помогают паттерны?

Нам нужно отделить три составляющих кода (грубо говоря, совсем упрощая): транспорт, бизнес-логику, базу. Но обеспечить между ними зацепление, минимальное необходимое. Лучше всего разнести их в три разные модуля (на это не обязательно), можно разнести в три разные программные компонента или в три разные абстракции. Одна обеспечивает работу с базой и ничего не знает о транспорте, а вторая - работу с транспортом и ничего не знает о базе. Дальше их должна сшивать общая абстракция (по принципу композиции, можно и агрегации). Какие паттерны тут помогут?

🧩 Mediator - снижает зацепление и подойдет нам для изоляции базы от транспорта.
🧩 Strategy - реализация стратегии для JavaScript это Map<PropertyKey, Implementation> что позволяет абстрагироваться от Implementation, находя его по ключу и работая по обобщенному интерфейсу.
🧩 Bridge - позволяет разделять абстракции и снижать зацепление, но не характерен для JavaScriot.
🧩 Abstract factory - для JavaScript абстрактная фабрика сводится к стратегии инстанциирования: Map<PropertyKey, Creator> и применяется как и стратегия, но в том месте, где нам нужно создавать инстансы (тут Creator это любой порождающий паттерн).

Признаки проблемы:
• Если вы не можете модифицировать работу с базой не трогая транспорт или бизнес-логику, не задевая базу, то нужно начинать внедрять разделение ответственности (separation of concerns).
• Если сложно написать юниттесты, а что-то протестировать можно только все целиком - ну вот оно, вы нашли проблему.
• Если код невозможно переиспользовать и вы чувствуете, что одно и то же пишете уже много раз.

Примеры на курсе по паттернам 👉 https://nodeua.com/Patterns-2024-buy.html

⚠️ Вот вам еще несколько идей:
▫️ Отделяете ли исключения (ошибки в коде)?
▫️ Отделяете ли soft ошибки (без исключений)?
▫️ Отделяете ли операционные ошибки (net, i/o, db...)?
▫️ Делаете автоматический retry?
▫️ Делаете serialize для передачи ошибок по сети?
▫️ Создаете ли классы для кастомных ошибок?
▫️ Используете ли коды ошибок вместо классов?
▫️ Делаете цепочки ошибок error.cause?
▫️ Используете AggregateError?
▫️ Практикуете return early и fail-fast?
▫️ Практикуете guards?
▫️ Применяете Either?
▫️ Реализуете graceful shutdown?
▫️ Перезапускаете процесс на любой ошибке?
▫️ Перезапускаете на операционных ошибках?
▫️ Перезапускаете процесс на доменных ошибках?
▫️ Имеете стратегию восстановления после ошибок?
▫️ Что используете для сбора логов?
▫️ Что для агрегации и консолидации логов?
▫️ Замеряете потерю производительности от ошибок?
▫️ Используете критические секции и web locks?
▫️ Используете promise.finally()?
▫️ Как трекаете и логируете контекст исполнения?
▫️ Генерируете UUID для трекинга контекстов?
▫️ Создаете ли точки восстановления состояния?
▫️ Используете AI для анализа стек-трейсов?
▫️ Применяете практику circuit breaker?
▫️ Очищаете stack trace от критических данных?
▫️ Практикуете blue-green deployments?
▫️ Практикуете feature toggles?
▫️ Практикуете canary release?
▫️ Практикуете shadow deployments?
▫️ Практикуете progressive delivery?
▫️ Практикуете rolling deployments?
▫️ Практикуете hotfix deployment?
▫️ Практикуете hot reload (без перезапуска)?
▫️ Имеете fallback при возникновении ошибок?