Юрий Белк – Full stack Developer (страница 14)

Экосистема огромная, но это не значит, что любую библиотеку стоит тянуть в проект.

Полезные привычки:

– не добавлять зависимость «ради одной функции»;

– смотреть на поддержку и актуальность;

– обновлять регулярно, а не раз в год «одним большим взрывом».

4) Добавьте наблюдаемость до того, как станет больно

Минимум, который окупается рано:

– структурированные логи,

– корреляционный id,

– метрики (хотя бы время ответа и ошибки),

– трассировка (по возможности).

Так вы быстрее поймёте, где Node «упёрся» – в базу, в внешние API или в CPU.

5) Держите архитектуру простой, но с границами

Не обязательно усложнять. Но границы должны быть:

– transport слой (HTTP) отдельно,

– бизнес‑логика отдельно,

– доступ к данным отдельно,

– общие типы/контракт отдельно.

Это снижает «расползание» и облегчает тестирование.

1.6. Итог

TypeScript/Node.js – выбор про скорость и удобство:

– быстро разрабатывать,

– легко интегрироваться,

– удобно жить в одном языке с фронтендом,

– отлично подходит для BFF и продуктовых API.

Но за это платите необходимостью инженерной дисциплины:

– следить за типовой безопасностью на границах,

– контролировать память и GC под нагрузкой,

– профилировать и работать с latency,

– не давать архитектуре расползаться.

Если вы хотите быстро выйти на рынок, постоянно менять продукт и у вас сильная фронтенд‑команда – TS/Node почти всегда хороший старт. А дальше вы либо продолжите масштабироваться на Node с профилированием, либо точечно вынесете критичные части туда, где лучше предсказуемость и производительность.

Глава 2. Python – плюсы/минусы

Python часто выбирают не из‑за «идеальной архитектуры» «самой высокой производ», а из‑за очень практичной вещи: на нём быстрее всего превращать идею в работающий код. Это язык, на котором одинаково комфортно написать API, скрипт мигра данных, интеграцию со сторонним сервисом, джобу для очереди и небольшой ML‑пайплайн.

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

В этой главе разберём Python «по‑земному»: где он особенно хорош, где может подставить и как понять, подходит ли он под ваш сервис.

2.1. Что мы подразумеваем под Python‑бэкендом

Под «Python‑бэкендом» в этой книге обычно подразумевается:

– Python 3.x (желательно актуальный, не «как на сервере поставили 5 лет назад»).

– Web API на одном из фреймворков:

– FastAPI (часто лучший баланс для современных API),

– Django (если нужен «комбайн» с ORM, админкой и большим количеством встроенных решений),

– Flask (минималистичный вариант).

– Работа в контейнерах (часто Docker), чтобы окружение было повторяемым.

– Тесты и линтинг как обязательная часть проекта.

Что стоит установить для работы

Минимальный набор, который обычно облегчает жизнь:

– Python 3 (лучше ставить через менеджер версий вроде `pyenv`, если вы на macOS/Linux).

– pip (идёт вместе с Python) + менеджер зависимостей:

– `poetry` или `uv` (быстро и удобно),

– либо классический `pip` + `requirements.txt` (простая модель, но требует дисциплины).

– Docker (PostgreSQL/Redis/очереди удобно поднимать контейнерами).

– Postman/Insomnia или просто `curl` для ручной проверки API.

– Инструменты качества кода:

– форматирование: `ruff format` или `black`,

– линтинг: `ruff`,

– типизация: `mypy` или `pyright`,

– тесты: `pytest`.

Эти инструменты не «украшают» проект – они компенсируют те места, где Python по умолчанию менее строгий.

2.2. Плюсы Python

Плюс 1. Самая высокая скорость написания бизнес‑логики

Python ценят за то, что он позволяет писать много полезного кода с минимумом шума. Это особенно заметно в бизнес‑логике, где часто нужно:

– обработать входные данные;

– сходить в БД/кэш/внешний сервис;

– принять решение по правилам;

– вернуть результат.