🐳 Кастомные Docker-образы — пишем правильный Dockerfile

Запуск готовых контейнеров вроде Nginx или PostgreSQL — это здорово, но для деплоя собственного приложения (на Python, Node.js или Go) нужно научиться собирать свои образы. Для этого пишется Dockerfile — текстовый файл с пошаговыми инструкциями для сборки.

Каждая строчка в Dockerfile создает новый слой образа. Чем меньше весят эти слои и чем лучше они кэшируются, тем быстрее будет собираться и разворачиваться ваш проект.

Пример правильного Dockerfile для Python (FastAPI):

# 1. Базовый образ (минималистичный alpine или slim)
FROM python:3.11-slim

# 2. Установка рабочей директории
WORKDIR /app

# 3. Копируем файлы зависимостей отдельно (для кэширования слоев)
COPY requirements.txt .

# 4. Установка пакетов без сохранения кэша менеджера
RUN pip install --no-cache-dir -r requirements.txt

# 5. Копируем остальной код приложения
COPY . .

# 6. Указываем порт, который слушает приложение
EXPOSE 8000

# 7. Команда для запуска
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Зачем это инженеру? Для создания стандартизированной среды. Копирование requirements.txt перед основным кодом — это классический паттерн. Если вы измените строчку в коде, но не тронете зависимости, Docker при сборке возьмет готовый слой с установленными библиотеками из кэша за долю секунды, а не будет скачивать их заново.

Также важно следить за безопасностью и размером. Использование легковесных образов (с тегом -slim или -alpine) уменьшает размер итогового контейнера с условного гигабайта до 100–150 мегабайт. Маленький образ быстрее передается по сети на сервер и содержит меньше потенциальных уязвимостей в системных библиотеках.

Для еще большей оптимизации используют Multi-stage builds (многоэтапную сборку), когда в одном Dockerfile первый контейнер собирает проект (используя тяжелые инструменты компиляции), а второй — просто забирает готовый результат, оставаясь максимально чистым.

Написание кастомных Dockerfile переводит работу с инфраструктурой на уровень "Infrastructure as Code" (Инфраструктура как код). Теперь процесс сборки вашего приложения задокументирован, автоматизирован и не зависит от настроек конкретного сервера.

🚪 Bash Ready | #практика

🔄 Миграции баз данных — как менять структуру без потери данных?

В начале проекта ваша база данных выглядит просто: таблица users с полями id и username. Но проект растет, и вам нужно добавить поле email, изменить тип данных у пароля или создать связь с новой таблицей заказов. Делать это вручную через SQL-запросы на живом сервере — верный путь уронить продакшен и потерять данные. Для правильного управления схемой используют миграции.

Миграции — это система контроля версий для вашей базы данных. Каждое изменение структуры оформляется в виде небольшого файла-скрипта (на Python, JS или чистом SQL), который содержит две обязательные инструкции:
— Upgrade (Up): что конкретно нужно сделать (например, добавить колонку).
— Downgrade (Down): как откатить это изменение назад, если что-то пошло не так.

В экосистеме Python стандартом для миграций являются Alembic (для SQLAlchemy) или встроенный механизм в Django ORM.

Как выглядит типичный процесс работы:
— Вы меняете модель в коде приложения.
— Генерируете файл миграции: alembic revision --autogenerate -m "add_email_to_user".
— Инструмент сравнивает ваш код с текущей базой и создает файл, где прописаны команды вроде op.add_column(...).
— Применяете изменения: alembic upgrade head.

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

В самом файле базы данных создается специальная служебная таблица (например, alembic_version), где хранится хэш последней успешно примененной миграции. Благодаря этому система всегда знает, какие скрипты уже выполнялись, а какие нужно запустить прямо сейчас.

Главное правило при работе на продакшене: никогда не удаляйте старые файлы миграций и не меняйте их задним числом, если они уже улетели в общий репозиторий. Если была допущена ошибка — создайте новую миграцию, которая её исправляет.

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

🚪 Bash Ready | #практика

🪵 Логирование без боли — почему стоит забыть про print()

Когда вы только учитесь кодировать, для проверки значений принято использовать обычный print(). Но в реальных проектах и на сервере print() становится бесполезным: он просто выплевывает текст в консоль, не говоря, когда произошла ошибка, в каком файле она случилась и насколько она критична. Для этого используют логирование (модуль logging или библиотеку Loguru).

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

Стандартные уровни логирования:
— DEBUG: подробная информация для отладки (значения переменных, шаги цикла).
— INFO: подтверждение, что всё идет по плану (сервер запущен, пользователь вошел).
— WARNING: случилось что-то неожиданное, но программа работает (мало места на диске).
— ERROR: серьезная проблема, часть функций не работает (ошибка базы данных).
— CRITICAL: полная остановка системы (упал весь сервер).

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

Пример работы с Loguru:

from loguru import logger

# Настраиваем запись в файл с ротацией (чтобы файл не весил гигабайты)
logger.add("app.log", format="{time} {level} {message}", level="INFO", rotation="10 MB")

def divide(a, b):
    try:
        logger.debug(f"Делим {a} на {b}")
        return a / b
    except ZeroDivisionError:
        logger.exception("Попытка деления на ноль!") # Автоматически запишет весь traceback ошибки

divide(10, 0)

Зачем это инженеру? Простой print() сотрется, как только закроется терминал. Правильный логгер сохраняет данные в файлы, автоматически снабжая каждую строчку точным временем, именем функции и уровнем важности.

Настроив ротацию (rotation="10 MB"), вы защищаете диск сервера: как только файл лога разрастется, Loguru заархивирует его и начнет новый. А благодаря правильным уровням вы сможете настроить отправку уведомлений в Telegram только для ошибок уровня ERROR и выше, не отвлекаясь на штатные INFO сообщения.

Переход от print() к логированию — это маркер взрослой разработки. Это дает возможность проводить аудит системы, понимать поведение пользователей и чинить баги за минуты, просто открыв лог-файл.

🚪 Bash Ready | #практика

🔒 Безопасное хранение паролей — зачем солить хэши?

Когда пользователь регистрируется на вашем сайте, он вводит пароль. Сохранять его в базу данных в чистом виде (plain text) — преступление против безопасности. Если злоумышленники взломают базу, они получат доступ к аккаунтам всех пользователей. Для защиты данных используют хэширование, но даже обычного хэша сегодня уже недостаточно.

---

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

Однако простые алгоритмы (MD5, SHA-1, SHA-256) работают слишком быстро. Хакеры используют радужные таблицы (Rainbow Tables) — гигантские базы заранее вычисленных хэшей для миллиардов популярных паролей. Если ваш пароль 123456, его хэш моментально найдется в такой таблице.

Чтобы защититься от этого, к паролю перед хэшированием добавляют соль (Salt) — случайную уникальную строку символов.

Как это работает:
— Пользователь вводит пароль: qwerty.
— Система генерирует случайную соль: x9F2kL.
— Пароль и соль соединяются, и хэшируется уже строка qwerty_x9F2kL.
— В базу данных сохраняются и соль, и полученный хэш.

Зачем это инженеру? Чтобы сделать радужные таблицы абсолютно бесполезными. Даже если два пользователя выберут одинаковый пароль 123456, из-за разной соли их хэши в базе данных будут кардинально отличаться. Хакеру придется подбирать пароль для каждого пользователя индивидуально методом брутфорса, на что уйдут годы.

В современном бэкенде (Python, Node.js, Go) для этого используют специальные «медленные» алгоритмы, такие как Bcrypt, Argon2 или Scrypt. Они намеренно заставляют процессор тратить миллисекунды на вычисление одного хэша. Для обычного пользователя задержка незаметна, но для хакера скорость перебора падает с миллионов вариантов в секунду до пары сотен.

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

🚪 Bash Ready | #практика

🧵 Потоки против Процессов — как заставить код работать параллельно?

Когда ваше приложение начинает делать несколько дел одновременно — например, обрабатывать запрос пользователя, скачивать картинку и считать тяжелую математику — вам нужно параллелить вычисления. В операционных системах и языках программирования (включая Python) для этого есть два главных инструмента: процессы (Processes) и потоки (Threads). Они звучат похоже, но работают совершенно по-разному.

Процесс — это независимая программа, которой операционная система выделила изолированную область в памяти. Когда вы запускаете браузер, Spotify и среду разработки — это разные процессы. Они изолированы: если упадет один процесс, остальные продолжат работать, потому что они не могут случайно залезть в чужую память.

Поток — это единица выполнения *внутри* одного процесса. Один процесс может запустить десятки потоков. Главное отличие: все потоки одного процесса делят между собой общую память. Они видят одни и те же переменные и объекты.

В чем разница при написании кода:

— Ресурсы: Создать процесс — «дорого» для процессора и оперативной памяти. Создать поток — в разы быстрее и легче.
— Обмен данными: Потокам легко общаться друг с другом, ведь у них общая память. Процессам, чтобы передать данные друг другу, приходится использовать сложные механизмы (IPC, очереди, сокеты).
— Безопасность: Если в одном из потоков случится критическая ошибка (например, Segmentation Fault), упадет весь процесс целиком со всеми остальными потоками. В случае с процессами — погибнет только один, изолированный элемент.

Зачем это инженеру? Чтобы правильно выбирать инструмент под конкретную задачу.

В Python есть своя специфика — GIL (Global Interpreter Lock). Это глобальная блокировка, которая разрешает только одному потоку выполнять код Python в один момент времени. Из-за этого потоки в Python идеально подходят для задач, связанных с ожиданием ввода-вывода (I/O-bound): например, делать запросы к API, скачивать файлы или ждать ответа от базы данных. Пока один поток ждет сеть, другой работает.

Если же вам нужно разгрузить процессор тяжелыми математическими расчетами, кодированием видео или обработкой больших данных (CPU-bound), потоки в Python не помогут — они будут выполняться по очереди на одном ядре. В этом случае нужно использовать процессы (multiprocessing), которые честно запустятся на разных ядрах вашего процессора.

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

🚪 Bash Ready | #практика

🌐 Понимание REST API — как общаются современные сервисы?

Когда вы заказываете еду через приложение, проверяете прогноз погоды или авторизуетесь на сайте через Google, под капотом происходит одно и то же: разные программы общаются друг с другом. Самый популярный стандарт для такого общения — архитектурный стиль REST (Representational State Transfer).


В основе REST API лежит простая концепция: всё в системе является ресурсом (пользователь, заказ, статья, картинка). У каждого ресурса есть свой уникальный адрес (URL). Например, /api/v1/users — это адрес, по которому живут данные всех пользователей.

Чтобы совершить действие с ресурсом, клиент (браузер или мобилка) отправляет серверу стандартный HTTP-запрос, используя определенный метод (глагол).

Основные методы REST API:
— GET — получить данные (например, открыть список постов). Этот метод безопасен: он не должен ничего менять в базе.
— POST — создать новый ресурс (например, зарегистрировать пользователя или опубликовать новый пост).
— PUT / PATCH — обновить существующие данные. PUT обычно заменяет ресурс целиком, а PATCH — меняет только отдельные поля.
— DELETE — удалить ресурс.

Зачем это инженеру? REST делает систему гибкой и масштабируемой. Бэкенд, написанный на Python (FastAPI / Django), ничего не знает о том, как устроен фронтенд. Он просто принимает запросы и возвращает структурированный ответ — обычно в формате JSON.

Пример JSON-ответа от сервера:

{
  "id": 42,
  "username": "python_developer",
  "status": "active"
}

Благодаря такому разделению вы можете полностью переписать мобильное приложение, но если структура REST API (эндпоинты и формат данных) осталась прежней, бэкенд даже не заметит изменений.

После обработки запроса сервер обязательно возвращает код ответа (HTTP Status Code), чтобы клиент сразу понял, что произошло:
— 2xx (например, 200 OK, 201 Created) — всё прошло успешно.
— 4xx (например, 400 Bad Request, 404 Not Found) — ошибка на стороне клиента (неверные данные, ресурс не существует).
— 5xx (например, 500 Internal Server Error) — ошибка на стороне сервера (код упал).

Проектирование чистых, понятных и предсказуемых REST API — один из главных навыков бэкенд-разработчика. Это позволяет легко интегрировать сервис с другими приложениями и делать архитектуру системы по-настоящему независимой.

🚪 Bash Ready | #практика

🗄️ Хранилища Key-Value — зачем бэкенду нужен Redis?

В классических базах данных вроде PostgreSQL или MySQL данные лежат в таблицах на жестком диске. Это надежно, но медленно, если запрашивать их тысячи раз в секунду. Когда приложению нужна максимальная скорость, на сцену выходит Redis — высокопроизводительная СУБД типа «ключ-значение», которая хранит все данные прямо в оперативной памяти (In-Memory).
В Redis нет таблиц, строк и сложных SQL-запросов. Вся работа строится вокруг пар данных: вы записываете значение по определенному ключу, а затем мгновенно извлекаете его. Скорость чтения и записи в Redis измеряется микросекундами, что позволяет обрабатывать сотни тысяч запросов в секунду на скромном железе.

Два главных сценария использования Redis:

— Кэширование: Вместо того чтобы при каждом визите пользователя делать тяжелый запрос к основной базе (например, вытягивать каталог товаров), вы один раз сохраняете результат в Redis. При следующем запросе приложение забирает данные из кэша за доли миллисекунды.
— Хранение сессий: Токены авторизации и сессии пользователей идеально подходят для Redis. При каждом клике на сайте бэкенд проверяет, валиден ли токен. Делать эту проверку через оперативную память гораздо эффективнее.

Зачем это инженеру? Redis избавляет основную базу от перегрузок. У Redis есть встроенный механизм TTL (Time To Live) — вы можете указать время жизни для любого ключа, например, 10 минут:

SET user_session_123 "active" EX 600

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

Помимо простых строк, Redis из коробки поддерживает сложные структуры данных: списки, хэши, множества (Sets) и даже сортированные множества. Благодаря этому его часто используют не только как кэш, но и как брокер сообщений для очередей задач или для реализации счетчиков в реальном времени (например, просмотры статьи или лимиты запросов к API).

Главный минус Redis — оперативная память стоит дороже жестких дисков, а при внезапном отключении питания сервера данные, которые не успели сброситься на диск, могут стереться (хотя у Redis есть механизмы снапшотов RDB и логирования AOF). Поэтому Redis используют как дополнение к основной базе, переводя скорость работы приложения на космический уровень.

🚪 Bash Ready | #практика

🐳 Очистка Docker — как вернуть гигабайты дискового пространства

Docker — потрясающий инструмент, но у него есть вредная привычка: он незаметно пожирает место на жестком диске. Вы обновили код, пересобрали образ, запустили новый контейнер — а старые слои, неиспользуемые тома и остановленные контейнеры остались лежать мертвым грузом. Со временем эта «свалка» может забить диск сервера на 100%, что приведет к падению всех приложений.

Когда вы пересобираете образ, старые слои теряют связь с тегами и превращаются в так называемые dangling (зависшие) образы. В выводе команды docker images они отображаются со странными именами <none>:<none>. Сами по себе они уже никогда не очистятся.

Главная команда для генеральной уборки:

docker system prune

Эта команда в один клик удаляет:
— Все остановленные контейнеры.
— Все неиспользуемые сети (networks).
— Все «зависшие» (<none>:<none>) образы и кэш сборки.

Если вы хотите пойти дальше и снести вообще все неиспользуемые образы (даже те, у которых есть нормальные теги, но которые сейчас просто не запущены), добавьте флаг -a:

docker system prune -a

Зачем это инженеру? Для предотвращения критических сбоев. Но здесь кроется важный нюанс: по умолчанию docker system prune не трогает тома (Volumes). И это сделано ради вашей безопасности, ведь в томах хранятся боевые данные — например, файлы вашей базы данных PostgreSQL или Redis.

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

docker system prune --volumes

Или точечно через команду docker volume prune.

Чтобы держать сервер в тонусе и не доводить диск до критической отметки, опытные админы не чистят всё руками. Они один раз настраивают уже знакомый нам планировщик Cron, добавляя туда задачу выполнять автоматическую базовую очистку docker system prune -f (флаг -f убирает подтверждение y/n) раз в неделю.

Регулярный мониторинг свободного места с помощью команды df -h и своевременный запуск очистки Docker — это простое правило гигиены, которое убережет ваши серверы от внезапных остановок и сэкономит кучу нервов.

🚪 Bash Ready | #практика

⚙️ Переменные окружения — как правильно хранить секреты проекта

Никогда не пишите пароли от баз данных, токены Telegram-ботов и секретные ключи API прямо в коде (хардкод). Если вы случайно выложите такой проект в публичный репозиторий на GitHub, злоумышленники найдут ключи за пару минут с помощью автоматических парсеров. Для безопасного управления конфигурацией используют переменные окружения (Environment Variables или env).

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

В процессе разработки стандартным решением является использование файла **.env, который создается в корне проекта.

Пример структуры файла .env:**

DATABASE_URL=postgresql://user:secret_pass@localhost:5432/mydb
BOT_TOKEN=123456789:ABCdefGhIJKlmNoPQRsTUVwxyZ
DEBUG=True

Критически важно: файл .env должен быть обязательно добавлен в ваш файл .gitignore, чтобы он ни при каких обстоятельствах не попал в Git. Для команды вместо этого создают файл-шаблон .env.example, где оставляют только названия переменных без реальных секретных данных.

Зачем это инженеру? Это делает приложение гибким и безопасным. В экосистеме Python для удобной работы с переменными окружения используют библиотеки вроде python-dotenv или встроенные механизмы Pydantic (pydantic-settings).

Пример чтения переменных в коде Python:

import os
from dotenv import load_dotenv

# Загружаем переменные из файла .env в окружение
load_dotenv()

# Достаем значения
db_url = os.getenv("DATABASE_URL")
bot_token = os.getenv("BOT_TOKEN")
# Второй аргумент — значение по умолчанию, если переменная не найдена
debug_mode = os.getenv("DEBUG", "False") == "True"

Такой подход позволяет использовать один и тот же код в разных средах без его изменения. Локально на компьютере вы используете .env с тестовой базой данных, на стейджинг-сервере прописываете другие значения, а на продакшене — боевые доступы (задавая их через настройки Docker, Systemd или панели управления сервером).

Разделение конфигурации и кода — это один из главных принципов современной разработки (часть методологии *Twelve-Factor App*). Это гарантирует безопасность ваших данных и упрощает масштабирование проекта.

🚪 Bash Ready | #практика

📡 Протокол WebSocket — двусторонняя связь в реальном времени

Классический HTTP работает по принципу «запрос-ответ»: клиент (браузер) просит данные, сервер их отдает, и соединение закрывается. Но что делать, если вам нужно построить чат, онлайн-игру или живой график котировок криптовалют? Заставлять браузер каждую секунду слать HTTP-запросы — дико неэффективно. Для таких задач используют протокол WebSocket.

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

Как устроен жизненный цикл WebSocket:
— Handshake (Рукопожатие): Клиент отправляет обычный HTTP-запрос с особыми заголовками, говоря серверу: «Давай перейдем на WebSocket».
— Upgrade: Если сервер согласен, соединение «апгрейдится» (статус код 101 Switching Protocols).
— Двусторонний обмен: Канал открыт. Теперь данные летают туда и обратно в виде легких фреймов.
— Закрытие: Любая сторона может закрыть соединение в любой момент.

Зачем это инженеру? Ради мгновенной реакции и экономии ресурсов. В HTTP каждый запрос тянет за собой кучу служебной информации (куки, заголовки браузера, тип контента), которая может весить больше, чем полезные данные. В WebSocket после установки соединения накладные расходы составляют всего несколько байт на сообщение.

В экосистеме Python работать с WebSocket невероятно удобно через фреймворк FastAPI. Он из коробки предоставляет простой синтаксис для управления такими соединениями.

Пример простейшего WebSocket-сервера на FastAPI:

from fastapi import FastAPI, WebSocket

app = FastAPI()

@app.websocket("/ws")
async def websocket_endpoint(websocket: WebSocket):
    await websocket.accept() # Принимаем соединение
    while True:
        # Ждем сообщение от клиента
        data = await websocket.receive_text()
        # Тут же отправляем ответ назад
        await websocket.send_text(f"Сервер получил: {data}")

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

🚪 Bash Ready | #практика

🥒 Кэширование на стероидах — зачем использовать Redis Hash?

Когда разработчики начинают работать с Redis, они обычно используют его как простое хранилище строк: записывают объект пользователя в виде JSON-строки по ключу user:100 через команду SET. Но если вам нужно обновить всего одно поле (например, статус или баланс), приходится доставать всю строку, десериализовать её, менять значение, собирать обратно в JSON и перезаписывать. Это медленно и неэффективно. Для работы со сложными объектами в Redis есть идеальная структура — Hash (Хэш).

Хэши в Redis — это полноценные словари внутри базы данных. Они позволяют хранить под одним ключом множество пар «поле-значение». Вы получаете структуру вида Ключ -> [Поле1: Значение1, Поле2: Значение2], которой можно управлять точечно.

Основные команды для работы с Хэшами:
— Записать объект: HSET user:100 username "alex" status "active" age 25
— Получить конкретное поле: HGET user:100 status
— Получить весь объект: HGETALL user:100
— Увеличить числовое поле: HINCRBY user:100 age 1 (идеально для счетчиков)
— Удалить одно поле: HDEL user:100 age

Зачем это инженеру? Ради колоссальной экономии памяти и процессорного времени. Когда вы используете Redis Hash, бэкенду на Python или JS больше не нужно тратить ресурсы на постоянный парсинг строк туда-обратно. Вы можете обновить статус пользователя одной быстрой командой, не трогая остальные данные.

Кроме того, под капотом Redis оптимизирует хранение маленьких хэшей с помощью структуры ziplist (компактный список). Это позволяет хранить миллионы объектов, тратя на них в разы меньше оперативной памяти, чем если бы каждый из них был отдельной JSON-строкой.

Использование хэшей — это стандартный паттерн для хранения профилей пользователей, настроек конфигурации, корзин товаров в интернет-магазинах или текущего состояния игровых сессий.

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

🚪 Bash Ready | #практика

🛡️ Мидлвары — как фильтровать веб-запросы на подлете к коду?

Представьте, что у вас в приложении на FastAPI, Django или Node.js есть 50 разных эндпоинтов. Для каждого из них нужно проверять, авторизован ли пользователь, логировать время обработки запроса и добавлять защитные заголовки. Писать этот код вручную внутри каждой функции — кошмар для поддержки. Чтобы решать такие сквозные задачи в один клик, используют Middleware (промежуточное ПО).

Мидлварь — это специальный слой-перехватчик, который встает прямо на пути сетевого запроса от клиента к вашему основному коду (роутам) и на обратном пути ответа от сервера к клиенту.

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

Как устроен жизненный цикл запроса с Middleware:
— Клиент отправляет запрос к серверу.
— Middleware 1 (Логирование): Записывает время старта и IP-адрес клиента, передает запрос дальше.
— Middleware 2 (Авторизация): Достает токен из заголовков. Если токен битый — мидлварь сразу разворачивает запрос назад и отдает ошибку 401 Unauthorized, даже не беспокоя основной код приложения.
— Ваш код (Роут): Если всё ок, выполняется логика приложения (например, выдача списка товаров) и формируется ответ.
— Обратный путь: Ответ снова летит через все мидлвари в обратном порядке. Например, слой безопасности может прикрепить к нему CORS-заголовки.

Зачем это инженеру? Это идеальное воплощение принципа DRY (Don't Repeat Yourself). Вместо дублирования проверок безопасности, вы выносите их на глобальный уровень.

Пример кастомной мидлвари для подсчета времени запроса на FastAPI:

import time
from fastapi import FastAPI, Request

app = FastAPI()

@app.middleware("http")
async def add_process_time_header(request: Request, call_next):
    start_time = time.time()
    
    # Передаем запрос дальше по цепочке к роуту
    response = await call_next(request)
    
    # Этот код выполнится уже на обратном пути ответа
    process_time = time.time() - start_time
    response.headers["X-Process-Time"] = str(process_time)
    
    return response

Встроенные мидлвари есть во всех популярных фреймворках. Самый частый пример — CORSMiddleware, который разрешает или запрещает вашему фронтенду, запущенному на другом домене, делать запросы к бэкенду. Без него браузер просто заблокирует любые попытки забрать данные.

Использование Middleware позволяет держать ваш основной код чистым, фокусируясь только на бизнес-логике. Все системные задачи — проверка токенов, сжатие ответов (Gzip), защита от атак и сбор метрик — делегируются этим невидимым стражам на входе в систему.

🚪 Bash Ready | #практика

📡 Веб-хуки — как заставить сервер самому звонить вашему коду?

Когда вы создаете Telegram-бота, парсер или платежную систему, вашему коду нужно оперативно узнавать о новых событиях: пользователь отправил сообщение, пришла оплата на криптокошелек или обновилась котировка. У вас есть два пути: постоянно спамить чужой сервер запросами в цикле (Polling) или настроить Webhook (веб-хук).

---

Polling — это когда ваш скрипт каждые две секунды спрашивает: «Ну что, есть новые данные? А сейчас? А теперь?». Это дико перегружает процессор, тратит сетевой трафик и создает кучу пустых запросов.

Webhook работает ровно наоборот (принцип *Don't call us, we'll call you*). Вы один раз говорите стороннему сервису: «Вот адрес моего сервера (URL). Как только что-то произойдет — сам пришли мне данные».

Как устроен процесс работы через Webhook:
— Вы поднимаете простейший веб-сервер (например, на FastAPI) и создаете эндпоинт, готовый принимать POST-запросы (например, /api/v1/telegram-webhook).
— Регистрируете этот URL в стороннем сервисе (через настройки API Telegram, платежки или GitHub).
— Когда происходит событие, сторонний сервис сам формирует HTTP-запрос с JSON-пакетом внутри и отправляет его на ваш адрес.
— Ваш код мгновенно ловит этот запрос, обрабатывает данные и возвращает статус 200 OK, подтверждая, что всё получено.

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

Пример обработки веб-хука на FastAPI:

from fastapi import FastAPI, Request, Response

app = FastAPI()

@app.post("/webhook/payment")
async def receive_payment_webhook(request: Request):
    # Получаем JSON с данными о транзакции
    payload = await request.json()
    
    event_type = payload.get("event")
    amount = payload.get("amount")
    
    if event_type == "payment.success":
        print(f"Зачислено {amount}$! Начисляем баланс пользователю...")
        # Тут ваша логика обработки (например, запись в базу)
        
    return Response(status_code=200)

Однако у веб-хуков есть важный нюанс: ваш сервер должен иметь публичный IP-адрес и работать по защищенному протоколу HTTPS (то, что мы как раз настраивали с помощью Nginx и Certbot). Если вы ведете разработку локально на домашнем компьютере, сторонний сервис не сможет достучаться до вашего localhost.

Для тестирования веб-хуков на локальной машине используют инструменты туннелирования вроде ngrok или LocalTunnel. Они создают временный публичный HTTPS-адрес и перенаправляют весь входящий трафик прямиком в ваш локальный порт.

Использование Webhooks — это стандарт для построения событийно-ориентированных (Event-Driven) систем. Это избавляет инфраструктуру от лишней работы и позволяет вашему коду мгновенно реагировать на любые изменения во внешнем мире.

🚪 Bash Ready | #практика

🛠️ Идемпотентность API — как защитить систему от дубликатов запросов?

Представьте ситуацию: пользователь в мобильном приложении нажимает кнопку «Оплатить заказ». Клик улетает на бэкенд, списываются деньги, но в этот самый момент на телефоне на секунду пропадает связь. Приложение не получает ответ от сервера, считает, что произошел сбой, и автоматически отправляет запрос повторно. Если ваш бэкенд не обладает свойством идемпотентности, у пользователя спишутся деньги дважды.

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

В стандартном REST API некоторые HTTP-методы идемпотентны по определению:
— GET: сколько раз ни запрашивай профиль пользователя, он не изменится.
— PUT / DELETE: если вы обновили имя на конкретное значение или удалили пост с id=5, повторные вызовы дадут тот же результат (пост останется удаленным).
— POST: не идемпотентен. Каждый новый вызов по умолчанию пытается создать новую запись в базе данных. Именно с ним и возникают проблемы при дублировании сетевых пакетов.

Как это правильно реализовать на практике:

Самый надежный способ защитить неидемпотентные операции (например, создание транзакции или отправку сообщения) — использование специального ключа идемпотентности (Idempotency-Key).

— Генерация ключа: Перед отправкой POST-запроса фронтенд (или клиент) генерирует уникальный UUID для этой операции и прикрепляет его в заголовки: Idempotency-Key: 7b9e84b2-a42e-4e1b-b461-9f9361ad2a48.
— Проверка на бэкенде: Когда запрос приходит на сервер, бэкенд первым в цепочке (например, через Middleware) проверяет, есть ли такой ключ в быстром кэше (идеально подходит Redis со временем жизни ключа в 24 часа).
— Если ключа нет: Сервер понимает, что это уникальный запрос. Он сохраняет ключ в Redis со статусом «в обработке» (In Progress) и начинает выполнять код. После успешного завершения статус меняется на «выполнено» (Completed), а рядом сохраняется тело ответа (Response Body).
— Если ключ уже есть: Сервер видит, что этот запрос дубликат. Если статус еще «в обработке», он просит клиента подождать. Если статус «выполнено» — сервер просто берет готовый ответ из Redis и возвращает его клиенту, вообще не трогая основную базу данных и не выполняя код повторно.

Зачем это инженеру? Это критически важный стандарт при работе с любыми финансовыми шлюзами, внешними интеграциями и распределенными системами. Сетевые сбои, повторные нажатия кнопок пользователями или автоматические ретраи (retries) в очередях задач — обычное дело для продакшена.

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

🚪 Bash Ready | #практика

🔄 Пул соединений (Connection Pool) — как не положить базу данных при нагрузке

Когда ваш Python-скрипт или веб-сервер делает запрос к базе данных (PostgreSQL, MySQL), под капотом происходит сложный процесс: приложение стучится к серверу базы по сети, проходит авторизацию, открывает сетевой сокет, выполняет SQL-запрос и закрывает соединение. Если на каждый клик пользователя открывать новое соединение с нуля, сервер моментально захлебнется. Решение этой проблемы — Connection Pool.

Открытие нового соединения — это одна из самых «дорогих» и медленных операций в работе с базами данных. Приложении тратит драгоценное время процессора и сети еще до того, как выполнит сам SQL-код.

Пул соединений работает по принципу кэширования: при старте приложения создается фиксированное количество готовых, уже авторизованных сетевых подключений к базе (например, 10–20 штук), которые удерживаются в памяти в активном состоянии.

Как устроен жизненный цикл запроса с Connection Pool:
— Запрос к базе: Когда вашему коду нужно вытянуть данные, он не создает новое подключение, а просит пул выдать одно из свободных.
— Выполнение кода: Приложение мгновенно получает готовый сокет, выполняет SQL-запрос и забирает результат.
— Возврат в пул: Вместо закрытия соединения (connection.close()), код просто возвращает его обратно в пул. Оно остается открытым и ждет следующего пользователя.

Зачем это инженеру? Чтобы защитить базу от падения и ускорить приложение в разы. У любой СУБД (например, PostgreSQL) есть жесткий лимит на максимальное количество одновременных подключений (max_connections). Если 500 пользователей одновременно зайдут на сайт без пула, база выдаст ошибку Too many connections и сайт упадет. Пул выступает в роли умного диспетчера.

В экосистеме Python при работе с асинхронным бэкендом (FastAPI / SQLAlchemy) пул соединений настраивается автоматически прямо при создании движка (Engine).

Пример настройки пула в SQLAlchemy:

from sqlalchemy.ext.asyncio import create_async_engine

DATABASE_URL = "postgresql+asyncpg://user:password@localhost/mydb"

# Настраиваем пул соединений
engine = create_async_engine(
    DATABASE_URL,
    pool_size=10,         # Базовое количество соединений, удерживаемых всегда
    max_overflow=20,      # Сколько максимум можно создать сверх нормы при пиковой нагрузке
    pool_timeout=30,      # Сколько секунд ждать свободное соединение из пула, прежде чем выкинуть ошибку
    pool_recycle=1800     # Сбрасывать соединения каждые 30 минут, чтобы они не застаивались
)

Если ваше приложение разрастается на несколько серверов или Docker-контейнеров, локального пула внутри кода может не хватить (ведь каждый контейнер заберет себе по 20 подключений, и лимит базы снова исчерпается). В таких масштабах перед PostgreSQL ставят специализированные внешние прокси-пулеры — PgBouncer или Odyssey, которые умеют эффективно делить подключения между тысячами независимых процессов.

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

🚪 Bash Ready | #практика

⚙️ Графическое вычисление (GPU) против Центрального процессора (CPU) — когда бэкендеру нужны видеокарты?

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

---

CPU (Центральный процессор) — это «мозг» компьютера, спроектированный для решения общих и сложных последовательных задач. У него относительно мало ядер (обычно от 4 до 64), но каждое ядро невероятно мощное, имеет высокую тактовую частоту и огромный кэш. CPU отлично справляется с ветвлением логики (if/else), управлением операционной системой, работой баз данных и выполнением стандартного кода вашего приложения.

GPU (Графический процессор) — устроен совершенно иначе. Он создавался для отрисовки графики и работы с 3D, где нужно одновременно просчитывать цвет миллионов пикселей на экране. Для этого вместо нескольких мощных ядер в него упаковали тысячи мелких, простых ядер, работающих параллельно.

Главные отличия в архитектуре вычислений:

— Параллелизм: CPU обрабатывает задачи последовательно (или в несколько мощных потоков). GPU берет массив данных и обрабатывает тысячи элементов одновременно по одной и той же инструкции (архитектура SIMD — *Single Instruction, Multiple Data*).
— Сложность операций: Ядро GPU не умеет эффективно выполнять сложную логику со множеством ветвлений. Его стихия — простая, однотипная математика: умножение матриц и работа с векторами.

Зачем это инженеру? Чтобы понимать, в какой момент архитектуру проекта нужно дополнить видеокартами. Если вы пишете стандартное REST API или парсер — GPU вам ничем не поможет. Но есть три сферы, где без видеокарт проект просто не запустится:

— Искусственный интеллект и Нейросети (AI/ML): Обучение моделей и генерация (будь то текст в LLM или картинки в Stable Diffusion) — это чистая линейная алгебра и гигантские матрицы. На GPU (например, с использованием ядер Nvidia CUDA или Тензорных ядер) эти процессы ускоряются в 100–1000 раз по сравнению с CPU.
— Обработка медиаданных: Сжатие «на лету» потокового видео, кодирование аудио высокого разрешения или рендеринг 3D-сцен на сервере.
— Криптография и Хэширование: Перебор паролей (брутфорс при аудите безопасности) или работа с блокчейн-сетями.

В экосистеме Python для работы с GPU бэкенд-разработчики используют библиотеки вроде PyTorch, TensorFlow или CuPy (аналог NumPy для видеокарт). Они позволяют перенести массив данных из обычной оперативной памяти (RAM) в видеопамять (VRAM) одной командой:

import torch

# Проверяем, доступна ли видеокарта от Nvidia
device = torch.device("cuda" if torch.cuda.is_available() else "cpu")

# Создаем тяжелую матрицу и отправляем её на вычисление в GPU
x = torch.randn(10000, 10000, device=device)
y = torch.randn(10000, 10000, device=device)

# Мгновенное матричное умножение силами ядер видеокарты
result = torch.matmul(x, y)

🚪 Bash Ready | #практика

Проверка времени отклика сервисов

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

▪️ Самый простой замер

time curl -s https://bashtex.com > /dev/null

Показывает общее время выполнения запроса и быстро понять, тормозит или нет.

▪️ Точнее: только сетевое время

curl -s -o /dev/null -w "time_total: %{time_total}\n" https://bashtex.com

Полезные метрики:

time_namelookup
time_connect
time_starttransfer
time_total

Пример:

curl -w "DNS:%{time_namelookup} CONNECT:%{time_connect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" \
     -o /dev/null -s https://bashtex.com

▪️ Проверка нескольких сервисов

for url in https://a.ru https://b.ru; do
  curl -o /dev/null -s -w "$url %{time_total}\n" "$url"
done

▪️ Таймаут обязателен

curl --connect-timeout 3 --max-time 5 https://bashtex.com

Без таймаута любой мониторинг бесполезен.

🍿 Мультивселенная схлопнулась.