Библия systemd — как управлять системой

Systemd — пожалуй, самая важная подсистема в Linux, без которой редко обходится развёртывание приложений на Linux-серверах.

Даже, если вы используете только контейнеризованные сервисы в docker, вам может пригодиться systemd для настройки автоматического перезапуска контейнеров после перезагрзузки.

Пару дней назад, на хабре вышла объёмная статья, в которой вся работа systemd раскрывается во всех подробностях. Мои знания по работе с systemd ограничивались способностью написать простенький сервис, например такой:

[Unit]
Description=Echo server
After=multi-user.target
[email protected]

[Service]
Type=simple
ExecStart=/usr/bin/python3 -m flask -A main.py run --host 0.0.0.0 --port 80
WorkingDirectory=/var/www/apps
Restart=always
User=root
Group=root

[Install]
WantedBy=multi-user.target

И не могу сказать, что вам нужно знать сильно больше. Но отмечу, что статья помогла мне расставить точки над ё во многих моментах. Рекомендую.

https://habr.com/ru/articles/817701/

Комментарии в коде

#дискуссия

На днях, автор канала Cross Join опубликовал пост с рассуждениями на тему того, насколько в коде нужны комментарии.

Основной проблемой он считает то, что комментарии будут терять свою актуальность по мере внесения изменений в код.

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

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

Существуют разные точки зрения на комментирование кода. Автор книги "Чистый код", к примеру, призывает писать код без комментариев, объясняя это тем, что каждый оставленный комментарий - это неудача и комментировать код стоит только в крайнем случае.

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

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

А как вы подходите к написанию комментариев в коде?

Что я прочитал: "какие привычки освоить it-шнику, чтобы стать продуктивнее (или здоровее)?"

#чтояпрочитал #продуктивность

Ссылка на оригинал: https://habr.com/ru/articles/818923/

Кратко (полностью скопировано из самой статьи)

Общий список привычек на ежедневную основу

- Пространственные упражнения: особые упражнения для формирования настроя на день.
- Принятие холодного душа: холодный душ / обтирания / умывания для поднятия общего тонуса и настроя на день.
- Планирование следующего дня: планирование задач на следующий день в конце текущего.
- Чтение: чтение художественной / профессиональной литературы.
- Стакан воды с утра: выпивание стакана воды после пробуждения для увлажнения организма и стимуляции обмена веществ.
- Ходьба / Бег: регулярные прогулки или бег для поддержания физической формы и энергии.
- Сон по расписанию: соблюдение определенного режима сна, с учетом жизненных циклов организма и мира.
- Медитация: медитирование для улучшения концентрации, снятия стресса и общего благополучия.

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

На мой взгляд, точно будет работать:

- планирование следующего дня: я, к примеру, планирую все свои дела раз в неделю, а в конце дня просто сверяюсь с планом;
- чтение: меня пока что хватает только на ежедневное чтение разных статей и постов в тг, до книжек руки не доходят;
- стакан воды с утра: от воды в любом случае хуже не будет, а с утра действительно может помочь лучше проснуться;
- ходьба: именно ходьба, а не бег, потому что бег травмоопасен, а гулять на свежем воздухе — очень полезно;
- сон по расписанию: в ноябре прошлого года я уже писал про режим, рад поделиться тем, что уже более 3 недель удерживаю прекрасный режим без особых трудностей и делаю это довольно аккуратно. Мне помогают два будильника с интервалом 1.5 часа друг от друга. Первый за 1.5 часа до момента, когда мне надо проснуться, а второй ровно в то время, когда надо проснуться. Плюсом к этому, я включил сценарий светового будильника и когда я просыпаюсь с утра, чтобы выключить второй будильник, — в комнате уже светло, помогает легко встать.

Дополнительный пункт от меня: баланс между работой и жизнью (aka "work/life balance"). Я поставил себе чёткие рамки начала и окончания рабочего дня и это действительно помогает удерживаться от переработок и уменьшает энтропию.

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

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

Медитацию я не пробовал и пока не горю желанием. Жду кризиса среднего возраста. Некоторые мейнстримные привычки, типа той же медитации, меня немного отталкивают как раз-таки своей мейнстримностью.

Скрепка в vscode. Мнения?

Небольшой оффтоп по теме быта, ищу рекомендаций

Подумываю о покупке ультракороткофокусного проектора для домашнего просмотра фильмов и прочего видеоконтента. Знаю, что надо уделить внимание такому параметру, как яркость, чтобы можно было смотреть и не зашторивая комнату полностью. Примерно понимаю, какую диагональ хочу и чтобы было хотя бы FullHD, а лучше если 4K. Причём, интересует именно проектор.

Интересовался ли кто-то темой? Можете посоветовать, где можно посмотреть/почитать?

На ютубе обзоров крайне мало и в основном на бюджетные модели :(

Что я прочитал - не только ORM

#чтояпрочитал #orm #бд

Ссылка на оригинал: https://habr.com/ru/articles/818761/
Ссылка на гитхаб проекта: https://github.com/amaslyaev/noorm

Кратко

В статье автор описывает устройство ORM и основную, на его взгляд, проблему такого подхода — "персистетные объекты". И предлагает альтернативу в виде кастомной библиотеки, позволяющей работать с БД без использования персистетных объектов, при этом не засоряя основной код SQL-запросами.

Выдержка про проблему персистентных объектов:

Примечательно здесь то, что работа с базой данных идёт через персистентные объекты, являющиеся экземплярами «модельных» классов, описывающих структуру БД. Эти персистентные объекты умеют себя прочитать из базы и в неё себя записать. Они живут внутри открытой сессии. И ещё эти объекты умеют «лениво» дотягивать из базы связанные с ними другие персистентные объекты. Эти самые персистентные объекты — корень всех проблем:

1. По сути, это передача мутабельного объекта в другой процесс. Безобразно тупая затея. Мы запросили сущность «пользователь Вася» из базы данных в процесс своего бэкенда, и теперь где у нас теперь мастер-копия? Как мы их собираемся синхронизировать, в какой момент, и что собираемся делать с возможными коллизиями?
2. Что случается с живущими в сессии объектами когда сессия закрывается? Что если они продолжают быть нужны в логике приложения? Что если эта логика продолжает считать, что это по-прежнему нормальные объекты, принадлежащие живой сессии?
3. Невозможно найти единственно правильный баланс между eager- и lazy-загрузкой. Если увлекаемся lazy, получаем проблему N+1, и всё начинает страшно тормозить. Если увлекаемся eager, на каждый невинный чих ORM пытается вычитать полбазы, и тоже всё тормозит. Короче, у нас две педали, но обе они педали тормоза.

Какой подход предлагает автор взамен?

Выделение отдельного модуля с логикой БД и SQL-запросами, который может выглядеть примерно так:

from dataclasses import dataclass
import noorm.sqlite3 as nm

@dataclass
class DbUser:
  id: int
  username: str
  email: str

@nm.sql_fetch_all(DbUser, "SELECT rowid AS id, username, email FROM users")
def get_users():
  pass

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

Выводы

В целом, подход имеет место быть и я даже уже начал собирать небольшой пет-проект с использованием NoORM. В ближайшие дни будет несколько постов по этой теме.

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

Установка YAML-файла docker-compose по умолчанию

#советы #docker

Можно вот такой .env создать в корне проекта (или в том месте, где лежат композы, или в том месте, где вы обычно выполняете команду docker compose):

COMPOSE_FILE=docker-compose.dev.yml

Тогда команда docker compose будет по умолчанию брать тот файл, который таким образом указан и можно не писать docker compose -f docker-compose.dev.yml up, а ограничиться обычным docker compose up.

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

Переключение сред исполнения в Vite

#советы #frontend #vite

Мало ли вы не знали, но в vite можно использовать MODE. При этом, он будет браться из имени вашего файла. К примеру, у вас есть .env.prod и .env.dev. Если вы хотите, чтобы какой-то код был доступен только в деве (например, когда вы только выкатываете новую фичу для теста, а ветка по какой-то причине одна, такое бывает), то вы можете использовать такой код для этого:

const isProdMode = import.meta.env.MODE === 'prod';

if (isProdMode) {
    // Код, который должен исполняться только в prod режиме
} else {
    // Код для других режимов
}

Такой же код можно вставлять даже внутрь самих компонентов, например в JSX это может выглядеть так:

{isProdMode && <HelloWorld />}

При самой сборке и запуске можно указывать аргумент -m со значением dev или prod (или каким-либо другим значением, которое вы заложите).

  "scripts": {
    "start": "npm run dev",
    "dev:prod": "vite --port 3000 -m prod",
    "dev": "vite --port 3000 -m dev"
  }

Подробнее: https://vite.dev/guide/env-and-mode

Форматируем вывод числа с учётом валюты и локали на фронтенде

#frontend #intl

Несколько месяцев назад, я уже рассказывал вам про такую вещь, как Intl API. Тогда мы разбирались с датами, сегодня предлагаю научиться форматировать валюты с помощью следующей функции:

const formatCurrency = (value, locale, currencyCode, config = {}) => {
    return new Intl.NumberFormat(locale, {
        style: "currency",
        currency: currencyCode,
        ...config,
    }).format(value)
}

console.log(formatCurrency(123456, "ru-RU", "RUB"))
// 123 456,00 р.

console.log(formatCurrency(123456, "en-US", "USD"))
// $123,456.00

Аргумент config был добавлен мною для возможности расширения текущей конфигурации экземпляра Intl, например, можно добавить параметр maximumSignificantDigits для округления до 3 значащих цифр:

console.log(formatCurrency(123456.789, 'ru-RU', 'RUB', { maximumSignificantDigits: 3 }))
// 123 000 р.

По-хорошему, бы тут добавить какую-то проверку, что аргументы передаваемые в config действительно находятся внутри Intl.NumberFormat и корректно им будут обработаны, а также защиту от перезаписывания заданных нами параметров, но моя цель была только в том, чтобы поделиться простым способом форматирования чисел с помощью встроенного браузерного API.

Если верить спецификации, коды валют берутся из стандарта ISO 4217. Мне не удалось найти оригинальный список кодов валют по этому стандарту не в PDF, но зато в онлайне есть наш ОКВ, который основан на этом стандарте.

Подробнее: https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat

Переход с Python на Go и мысли о высшем образовании / ч. 1

Пост в блоге: https://blog.kantegory.me/it-education

Предисловие

Уже около года в моих черновиках для постов гуляет заметка с названием "для чего нужен вуз?". Разумеется, с точки зрения IT. До сегодняшнего дня, там была только одна мысль, которую я подметил, когда писал в дневник:

Осознал, что вуз нужен в том числе для того, чтобы научиться писать отчёты по стандартам, да и в целом делать что-либо с учётом принятых стандартов.

Сегодня я гулял по хабру и наткнулся на две похожих статьи об одном и том же, но от разных людей: "Переход с Python на Go: мысли человека, которому иногда сложно" и "Как я начал учить Go и правда ли он похож на Python. Мой личный опыт".

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

Мысли по ходу прочтения первой статьи

Заранее оговорюсь, что с golang у меня почти нет реального опыта (один пет-проект, который я писал по видео на youtube и несколько дней с документацией), а на python я пишу уже более десяти лет, но все мысли автора, приведённые далее, исходят корнями к общему отсутствию базовых знаний, а не к знаниям в конкретных языках программирования.

Автор пишет:

Сначала я подумал, что это какая-то обёртка, типа как if __name__ == "__main__" в Python, но, похоже, нет. Тут без main вообще ничего не запускается. Это немного сбивает. Почему язык не может просто начать выполнять файл с первой строки?

Моя мысль: python интерпретируемый, а go - компилируемый язык. Потому он и не выполняется с первой строки. Это, если угодно, жанровая необходимость.

Интересно, что он при этом в самом начале упоминает, что заканчивал онлайн-школу. Это как раз и объясняет, видимо, весь последующий текст. Я ничего не имею против онлайн-школ, раскрою эту мысль чуть ниже.

Удивление "странным типам" тоже ни к селу, ни к городу. Очевидно, что в python типизация неявная и динамическая, в то время как в golang она явная и статическая:

Я привык, что переменные сами понимают, кто они. В Python пишешь a = 5, потом a = "текст" — и всё нормально.

В Go, если ты сказал, что a int, то всё — никаких "текстов" туда не положишь. Я не сразу понял, как это работает. Ещё есть :=, и я не сразу понял, чем := отличается от =. Оказалось, := — это когда переменную создаёшь. А = — когда она уже есть. Почему нельзя просто одно оставить?

Переход с Python на Go и мысли о высшем образовании / ч. 2

Пост в блоге: https://blog.kantegory.me/it-education

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

Блистательное утверждение, орфография автора сохранена:

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

Скажу, как человек, который прособеседовал более сотни кандидатов: отсутствие или наличие высшего образования не отражает реальных знаний. Но люди с высшим образованием мыслят несколько иначе. Это проверено на опыте и не единожды.

Итог этого поста вполне очевиден и закономерен, - его заминусовали на хабре. В комментариях пишут:

Но больше всего мне непонятен посыл статьи.

Судя по приведенным примерам, вам и в питоне пока многое не понятно.

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

может скажем ему?

Мысли о второй статье

Очевидно, что автор имеет опыт работы и понимает то, о чём он пишет. В некоторых моментах он даже довольно глубоко копнул, когда писал про запуск golang-кода внутри python (в виде собранной библиотеки, конечно).

Отсюда я узнал довольно много нового для себя, а некоторые знания по go освежил. Рекомендую к прочтению всем интересующимся.

Можно ли при этом однозначно сказать, что у этого автора есть высшее образование? Нет. Однозначно сказать нельзя. Можно ли сказать, что у автора есть какая-то база в программировании? Да, она есть. И это куда важнее, на мой взгляд.

Мысли о высшем образовании в IT

Возвращаясь к моим мыслям о первой статье:

Скажу, как человек, который прособеседовал более сотни кандидатов: отсутствие или наличие высшего образование не отражает реальных знаний. Но люди с высшим образованием мыслят несколько иначе. Это проверено на опыте и не единожды.

Является ли при этом высшее образование панацеей? Нет, не является.

Главное отличие в мышлении человека, получавшего высшее образование - умение систематизировать знания и пользоваться ими.

Если же мы говорим о высшем образовании в IT, то именно благодаря высшему образованию, формируется та самая "база", к которой довольно часто относят и знания в Computer Science.

Под этой "базой" я понимаю не только Computer Science, но и наличие прочих разнообразных навыков. Во время своего обучения, мне довелось как алгоритмы писать на разных языках, так и сети самостоятельно настраивать, сервера конфигурировать, даже рисовать картинки через python.

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

Переход с Python на Go и мысли о высшем образовании / ч. 3

Пост в блоге: https://blog.kantegory.me/it-education

Мысли об онлайн-школах и преподавании

В то же время, как альтернатива 4-6 годам в вузе, на рынке уже давно существует предложение пройти курсы на 3-18 месяцев и стать готовым специалистом. Некоторые даже говорят, что сделают вас middle-разработчиком (это просто маркетинг, не ведитесь).

Закономерным итогом обучения в онлайн-школах является неадекватная накрутка опыта в резюме и полное отсутствие фундамента для становления специалистом. Пишу это на примере моей текущей ученицы, с которой мы уже более двух месяцев занимаемся. Я не спрашивал, сколько стоило её обучение, но итоговый результат отталкивает. Да, что-то в её голове действительно отложилось, но крепкого фундамента по фронтенду не было сформировано. Мы более двух месяцев мусолим ванильный JS, HTML, CSS, чтобы освоить общие концепции и не запираться в одном react. Иметь гибкость. Уметь ориентироваться.

В среднем, на выходе из онлайн-школы, мы имеем человека, который не умеет подстраиваться и адаптироваться под возникающие условия. Конечно, всё индивидуально. Почти наверняка есть люди, которые прошли курсы, но при этом самостоятельно получали и дополнительную информацию из различных источников. Их опыт может отличаться. Да и в вузах преподаватели далеко не всегда мастера своего дела. Мы тоже можем ошибаться. Более того, мы регулярно это делаем. Но ошибаться - это не страшно. Главное, чтобы студенты ничего не поняли в итоге получили корректную информацию.

В преподавании для меня самым показательным и приятным моментом является то, что есть несколько человек, которые не хотели связывать свою жизнь с IT и получали высшее образование, что называется "для родителей", но после моих предметов заинтересовались. Почти все из них уже работают. Это для меня лучший показатель того, что я делаю это не зря.

Но вернёмся к критике онлайн-школ и их общей проблеме. Подведём итог.

Выводы

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

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

Поиск мотивации в скучных задачах

Частенько бывает, что нехватка мотивации для решения чего-то неинтересного заставляет это неинтересное откладывать в долгий ящик. Я и сам не до конца понимаю, как мне с этим справляться. Обычно стараюсь разбивать большую неприятную задачу на более мелкие, чтобы избегать излишней прокрастинации, но какой-то чёткой системы всё ещё не выработал.

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

Настоятельно рекомендую, буду пробовать применять в своей работе.

Ссылка: https://habr.com/ru/articles/906258/

Основные паттерны микросервисной архитектуры: Strangler Fig, API Gateway, Service Mesh и другие

#чтояпрочитал #микросервисы

Ссылка на оригинал: https://habr.com/ru/articles/904954/

Краткая выжимка

Strangler fig (удушающее дерево) — подход, при котором создаётся некий фасад, изначально перенаправляющий запросы в монолит. По мере реализации микросервисов, перенаправление запросов переключается на них. Процесс повторяется, пока монолит не будет полностью вытеснен.

API Gateway (API-шлюз) — точка для аккумуляции и последующего распределения пользовательских запросов по сервисам. По сути, он и является тем самым фасадом, который может помочь в случае использования паттерна Strangler fig.

API Gateway делят на несколько шаблонов:

- Routing — шлюз выполняет функцию маршрутизатора, прокси
- Aggregation — шлюз агрегирует данные: получая один запрос от клиента, ходит в несколько сервисов, возвращает клиенту единый ответ
- Offloading — шлюз берёт на себя ряд общих задач для сервисов (например, авторизация, логгирование, etc.)

На практике, API Gateway часто совмещает все эти роли.

Service Mesh — архитектурный паттерн для организации умной сетевой прослойки в микросервисной архитектуре. По сути, это распределённая система прокси-серверов, сопровождающая каждый из сервисов. То есть, у каждого сервиса появляется свой прокси под боком. Нужно это для того, чтобы снять с микросервисов необходимость реализации логики для балансировки, шифрования, отслеживания метрик и так далее.

Sidecar — это паттерн, предлагающий вынесение неосновной логики приложения в отдельный контейнер, запускаемый рядом с основным сервисом. Например, логгирование, конфигурация, связи с внешними системами. Это позволяет повысить модульность вашего приложения.

Database per Service — паттерн "база данных на сервис".

CQRS (Command Query Responsibility Segregation) — паттерн, разделяющий ответственность за изменение состояния и чтение состояния приложения между разным компонентами или моделями. По сути, это про использование двух БД для одного сервиса: одна БД для записи, другая для чтения.

Event Sourcing — паттерн хранения состояния системы, при котором каждое изменение состояния сохраняется, как отдельное событие. По сути, мы храним историю изменений каждого объекта в виде списка событий.

Выводы

Отличная статья, довольно подробная, с примерами и обоснованиями что и когда нужно и не нужно использовать. Рекомендую к прочтению.

Настраиваем автодокументирование для express-приложений

Читать полностью: https://blog.kantegory.me/express-autodoc

Долгое время в express было принято использовать решения, которые довольно большую часть работы перекладывают на разработчика. Одним из самых популярных решений и по сей день является swagger-jsdoc.

Поскольку, оно является и самым проверенным, я продолжал рассказывать о нём студентам из года в год. Но в этом году что-то пошло не так... Один из студентов спросил: "а нет ли чего-то такого же удобного, как в Nest.JS?". Тут-то всё и началось.

Я прочитал более десятка статей, пересмотрел несколько роликов в поисках оптимального решения. И вот мы здесь. Я выделил 3 решения для настройки автодокументации и подготовил сравнения и примеры для них.

swagger-jsdoc

Пример кода:

/**
 * @openapi
 * /v1/testCreate:
 *   post:
 *     produces:
 *       - application/json
 *     parameters:
 *       - name: username
 *         in: formData
 *         required: true
 *         type: string
 *       - name: password
 *         in: formData
 *         required: true
 *         type: string
 *     description: Test create
 *     responses:
 *       200:
 *         description: Returns a created object.
 */
router
  .route('/testCreate')
  .post(exampleController.post)

Полный код примера доступен на github.

Плюсы:
- простота
- универсальность

Минусы:
- много ручной работы

routing-controllers

Пример кода:

@JsonController()
export class ExampleController {
    @OpenAPI({ summary: 'Test create' })
    @ResponseSchema(TestCreateResponseDto, { statusCode: 200 })
    @Post('/testCreate')
    post(
        @Body({ type: TestCreateDto }) body: TestCreateDto,
        @Res() response: Response,
    ): void {
        const uuid: string = randomUUID();

        const responseBody = {
            uuid,
            ...body,
        };

        response.status(201).send(responseBody);
    }
}

Полный код примера доступен на github.

Плюсы:
- код более структурирован
- вынужденное использование валидаторов
- синтаксически близко к Nest

Минусы:
- проблема с рантаймом tsx
- остаётся ли express всё ещё таким же лёгким?

tsoa

Пример кода:

@Route()
@Tags('Example')
export class ExampleController extends Controller {
    @Post('/testCreate')
    @Response<TestCreateResponseDto>(201, 'Returns a created object.')
    public async post(
        @Body() body: TestCreateDto,
    ): Promise<TestCreateResponseDto> {
        const uuid: string = randomUUID();

        return {
            uuid,
            ...body,
        };
    }
}

Полный код примера доступен на github.

Плюсы:
- код более структурирован
- встроенная валидация
- комплексное решение
- синтаксически близко к Nest

Минусы:
- остаётся ли express всё ещё таким лёгким?

Выводы

Сухое сравнение доступно на npm-compare. По моим личным ощущениям, tsoa — самый оптимальный вариант.

Читать полностью: https://blog.kantegory.me/express-autodoc