Юрий Белк – Full stack Developer (страница 1)
Юрий Белк
Full stack Developer
Об чём речь?
Книга‑туториал (максимально практическая): Full‑Stack + Backend Engineering на TS / Python / Java / Go
Сравнение языков, пошаговые проекты, одна предметная область, одинаковые требования.
Чтобы вы могли писать один и тот же продукт четырьмя реализациями бэкенда (TS/Python/Java/Go) и одной фронтенд‑частью, а затем сравнивать: скорость разработки, качество, тестируемость, производительность, сложность деплоя, типизацию, экосистему.
Как устроена книга
Главная идея
Мы строим один и тот же продукт (например, TaskFlow – сервис задач/проектов/команд):
Frontend: TypeScript + React/Next.js (единый для всех)
Backend: 4 реализации одного API:
1) Node.js + TypeScript (например, NestJS/Fastify)
2) Python (FastAPI)
3) Java (Spring Boot)
4) Go (Gin/Fiber/chi)
DB: PostgreSQL
Очереди: (опционально) RabbitMQ/NATS/Kafka (раздел сравнения)
Кэш: Redis
Observability: OpenTelemetry + Prometheus + Grafana + Loki
Infra: Docker Compose → CI/CD → Kubernetes (опционально)
На что будет опираться каждая реализация
Единая OpenAPI спецификация (контракт)
Единая схема БД и миграции
Единые acceptance tests (e2e) для всех реализаций
Единый набор сценариев нагрузки (k6/Locust/JMeter)
Для кого?
От “почти ноль” до уровня уверенного инженера
Для тех, кто хочет практику, но при этом понимать компромиссы
Стандартная структура каждой главы (шаблон)
Каждая глава оформляется одинаково:
1. Цель и результат (что получится в конце)
2. Предварительные требования
3. Шаги (команды + код)
4. Проверка результата (что увидеть/какие тесты проходят)
5. Типовые ошибки и дебаг
6. Домашка/усиление
7. Сравнение TS vs Python vs Java vs Go (если применимо)
Раздел I. Подготовка: инструменты, репо, “скелет книги”
Этот раздел нужен, чтобы один раз настроить окружение и дальше спокойно проходить всю книгу. Мы будем сравнивать несколько бэкендов (TypeScript, Python, JVM, Go) и один фронтенд, поэтому важно сразу договориться о правилах: как ставим зависимости, как запускаем сервисы, где живут контракты API, и как устроен репозиторий.
Главная идея: один монорепозиторий, один docker-compose для инфраструктуры, один контракт OpenAPI, и единые e2e‑тесты, которые одинаково проверяют любой бэкенд.
Глава 1. Как развернуть окружение
Ниже – минимальный набор инструментов, чтобы у вас работало всё: локальный запуск, тесты, генерация кода из OpenAPI и CI.
1.1. macOS / Linux / Windows (WSL2)
macOS
Обычно достаточно:
– терминал (встроенный или iTerm2),
– пакетный менеджер (например, Homebrew),
– Docker Desktop.
Linux
Удобнее всего, когда:
– есть нормальный bash/zsh,
– Docker установлен нативно,
– вы добавили пользователя в группу docker, чтобы не писать sudo на каждый запуск.
Windows
Рекомендуемый путь – WSL2:
– ставите WSL2,
– ставите Ubuntu,
– работаете внутри Linux‑окружения,
– Docker Desktop на Windows подключается к WSL2.
Так вы избегаете большинства проблем с путями, правами, файловой системой и скоростью работы инструментов.
1.2. Git, SSH, GPG (подпись коммитов)
Git
Проверьте:
bash
git –version
Настройте имя и почту (один раз):