Шаблон Full Stack FastAPI теперь отдаёт фронтенд на React и TanStack прямо через FastAPI.

В итоге одно приложение, один деплой и один домен.

Без отдельного фронтенд-сервера, лишней настройки CORS и постоянной отладки проблем между двумя частями приложения.

https://github.com/fastapi/full-stack-fastapi-template

👉 @BackendPortal

Классика алгоритмов

https://www3.cs.stonybrook.edu/~skiena/373/videos/

👉 @BackendPortal

Бэкенд-разработка не обязана начинаться с 10 инструментов и 50 конфигурационных файлов.

Новый туториал по FastAPI показывает путь от пустой папки до рабочего REST API примерно за 5 минут.

Без Docker.
Без долгой настройки базы данных.
Без часов возни с инфраструктурой до первого эндпоинта.

Внутри разбирают

→ как маршруты связывают URL с функциями
→ как Pydantic автоматически проверяет данные
→ как внедрение зависимостей управляет сессиями базы данных

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

https://youtube.com/watch?v=uOuTlhXDf1Y

👉 @BackendPortal

SSH-туннели, или как стать магом сетевой связности

10 практических челленджей, чтобы прокачать port forwarding через SSH-туннели — от простого локального/удалённого проброса портов до продвинутых сценариев с bastion- и jump-хостами:

- Получить доступ к внутреннему debug-порту через SSH-туннель
https://labs.iximiuz.com/challenges/ssh-local-port-forwarding
- Достучаться до приватного сервиса в VPC через SSH-бастион
https://labs.iximiuz.com/challenges/ssh-local-port-forwarding-bastion
- Получить доступ к удалённому loopback-порту через SSH jump host
https://labs.iximiuz.com/challenges/ssh-local-port-forwarding-jump-host
- Ограничить доступ к SSH-бастиону в зависимости от роли пользователя
https://labs.iximiuz.com/challenges/ssh-local-port-forwarding-bastion-hardened
- Получить доступ к внутренним серверам через SSH-бастион без shell-доступа
https://labs.iximiuz.com/challenges/ssh-jump-host-internal-servers
- Получить доступ ко всей VPC через SSH SOCKS-прокси
https://labs.iximiuz.com/challenges/ssh-socks-proxy
- Пробросить локальный сервис наружу через обратный SSH-туннель
https://labs.iximiuz.com/challenges/ssh-remote-port-forwarding
- Пробросить устройство из домашней сети через обратный SSH-туннель
https://labs.iximiuz.com/challenges/ssh-remote-port-forwarding-home-network
- Пробросить всю домашнюю сеть через обратный SSH SOCKS-прокси
https://labs.iximiuz.com/challenges/ssh-reverse-socks-proxy
- Заменить root-доступ по паролю на админский логин по SSH-ключу
https://labs.iximiuz.com/challenges/ssh-harden-new-server

Приятного хакинга!

👉 DevOps Portal

Упрощает изучение шаблонов проектирования через понятные объяснения и примеры кода на PHP 7.

https://github.com/nilbuild/design-patterns-for-humans

👉 @BackendPortal

Этот репозиторий на GitHub даёт 979 готовых API для скачивания видео, извлечения метаданных, создания расшифровок и анализа контента с YouTube, TikTok, Instagram, Facebook и множества других платформ.

https://github.com/cporter202/video-scraping-apis

👉 @BackendPortal

Что такое Forward Proxy?

Само слово proxy означает «от имени кого-то». Forward Proxy находится между клиентом и интернетом и действует от имени клиента.

Основная идея

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

С точки зрения сервера запрос пришёл от прокси, а не от самого клиента. Реальный клиент для сервера остаётся скрытым.

Пример из реальной жизни

Forward Proxy широко используют в компаниях для фильтрации, блокировки и журналирования интернет-трафика.

Представим, что у вас ИТ-компания, где сотрудники выходят в интернет с рабочих компьютеров. Forward Proxy позволяет

• записывать запросы
• фильтровать их в зависимости от пользователя или типа запроса
• блокировать отдельные сайты

Внешний сервер будет видеть IP-адрес прокси компании, а не конкретного сотрудника.

Где используется Forward Proxy

• приватность
• фильтрация контента
• кэширование
• обход географических ограничений
• журналирование и мониторинг

Главное

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

👉 @BackendPortal

Сегодня запустили pgterm.dev

Терминал для PostgreSQL, написанный на Rust.

Один терминал для всех ваших баз PostgreSQL.

→ Добавляйте любую базу одной командой
→ Следите за состоянием, запросами, индексами и активностью
→ Мгновенно переключайтесь между базами
→ Подключайте pgbot для более глубокой диагностики
→ Всё работает локально

Бесплатно и с открытым исходным кодом.

По сути, это htop для PostgreSQL, только созданный специально для разработчиков и ИИ-агентов.

GitHub ↓

https://github.com/pgrundev/pgterm

👉 @BackendPortal

Вышел pnpm 12!

Лучший менеджер пакетов для JavaScript-проектов.

✓ Безопасен по умолчанию
✓ Полностью переписан с нуля на Rust
✓ В 3 раза быстрее при чистой установке

→ https://pnpm.io/blog/releases/12.0

👉 @BackendPortal

👉 @BackendPortal

Приложения и базы данных, которые стоят за ними.

Instagram — PostgreSQL
Reddit — PostgreSQL
Twitch — PostgreSQL
Notion — PostgreSQL
Figma — PostgreSQL
ChatGPT — PostgreSQL
Skype — PostgreSQL

GitHub — MySQL
Shopify — MySQL
Slack — MySQL
YouTube — MySQL
Uber — MySQL
Airbnb — MySQL
Facebook — MySQL

Netflix — Cassandra

Discord — ScyllaDB

Забавно, насколько большая часть крупнейших сервисов в мире до сих пор держится на PostgreSQL и MySQL.

👉 @BackendPortal

Все говорят «поставь кэш». Но почти никто не показывает, где система реально развалится.

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

В демонстрации:

2 запроса/с — всё зелёное
840 запросов/с — 99% запросов падают

И самое интересное — узкое место вообще не в API. Обе базы данных загружены на 99,9%.

Вот чему обычная статичная схема архитектуры тебя никогда не научит.

Внутри есть 33 компонента: балансировщики нагрузки, кэши, очереди, реплики, автоматические выключатели и многое другое.

Плюс 23 готовых сценария вроде retry storm, cache-aside, шардинга и автомасштабирования.

Задержки p50, p95 и p99 здесь реально считаются, а не берутся из воздуха. Незавершённая работа продолжает занимать ресурсы. Можно даже устроить хаос, убить один из узлов и посмотреть, выдержит ли архитектура.

k6 на боевой системе это не заменит.

Но как тренажёр системного проектирования перед тем, как трогать реальную инфраструктуру, выглядит очень круто.

Открытый исходный код.

Демо
https://breakscale.tech

GitHub
https://github.com/xevrion/breakscale

👉 @BackendPortal

Настоящая находка среди репозиториев.

В нём собраны все основные шаги по защите и усилению безопасности Linux-сервера.

Если у вас есть VPS, стоит сохранить:

→ https://github.com/imthenachoman/How-To-Secure-A-Linux-Server

👉 @BackendPortal

now() — это не «сейчас», а скорее «когда-то было сейчас».

На самом деле now() возвращает время начала текущей транзакции. Реальные часы продолжают идти, но каждый последующий вызов now(), CURRENT_TIMESTAMP, CURRENT_TIME и CURRENT_DATE внутри этой же транзакции всё равно возвращает одно и то же время.

В Postgres это называется transaction-frozen timestamp.

То есть INSERT на 10 000 строк с created_at DEFAULT now() получит один и тот же timestamp для всех строк, а не 10 000 слегка отличающихся значений.

Три варианта времени:

• now() — традиционный для Postgres вариант, хотя он есть и в других СУБД, но это не стандарт SQL. В стандарте SQL используется CURRENT_TIMESTAMP. В Postgres также есть transaction_timestamp(), который работает так же, как now(), но хотя бы честно говорит об этом своим названием.

• statement_timestamp() обновляется один раз на каждый SQL-запрос. Это полезно внутри длинной транзакции, когда вам нужно фиксировать время выполнения отдельных команд, но не переходить к реальному системному времени.

• clock_timestamp() — единственный timestamptz, который меняется даже во время выполнения одного SQL-запроса.

👉 @BackendPortal

Недавно довольно часто пользуюсь Ansible — очень сильный проект с открытым исходным кодом, уже 69,1 тысячи звёзд на GitHub.

1️⃣ Автоматизацию можно описывать обычными текстовыми сценариями и использовать их для развёртывания приложений, настройки серверов и управления облачной инфраструктурой.

Недавно мне нужно было подготовить окружение сразу на трёх новых машинах. Написал один playbook — и всё поднялось почти автоматически. Вручную через команды на это ушло бы минимум пару часов.

2️⃣ Все машины управляются по SSH, при этом на целевые серверы не нужно ставить отдельный клиент.

Раньше я уже обжигался на зависимости SaltStack от агента, поэтому подход Ansible реально удобнее. Поменял конфигурацию — и можно сразу раскатить её хоть на сотню машин.

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

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

Тем, кто работает с ИИ, тоже стоит посмотреть на Ansible. Сам подход к устройству системы очень полезно изучить.

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

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

А чем вы обычно автоматизируете развёртывание ИИ-сервисов и запуск экспериментальных окружений — своими скриптами или сразу через Ansible?

https://github.com/ansible/ansible

👉 @BackendPortal

Backend Checklist: JSON-сериализация

Сериализация — это преобразование Python-объектов в текст для передачи по сети. Звучит как простая смена формата, но на деле это скорее перевод с одного языка на другой. А при переводе часть информации может потеряться.

В JSON всего семь типов, а у ваших объектов их гораздо больше. Весь набор типов JSON — это object, array, string, number, true, false и null. И всё. Никаких datetime, Decimal, set, UUID или bytes.

Поэтому всё, что сложнее этих типов, приходится обрабатывать отдельно — иначе json.dumps() завершится с TypeError:
datetime, UUID, Decimal — в JSON нет соответствующих типов, поэтому их преобразуют, обычно в строки.

set, bytes — прямых аналогов тоже нет, поэтому вы сами выбираете способ представления: например, set как list, а bytes как base64.

tuple — незаметно превращается в array, а после десериализации возвращается уже как list.

Последний пример в миниатюре показывает суть проблемы. Вы сериализуете tuple, а десериализуете list. Данные сохранились, но тип — нет.

Объект, который вы получаете обратно, — уже не тот объект, который вы отправили. Round trip через JSON может приводить к потере информации. datetime уходит как string и остаётся string до тех пор, пока кто-то явно не распарсит его обратно. Decimal, если преобразовать его во float для совместимости с JSON, вернётся как float — и по пути может потерять точность.

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

В Python shell:

json.loads(json.dumps(("a", "b")))
вернёт: ["a", "b"] Round trip изменил тип данных, не сохранив различие между tuple и list.

👉 @BackendPortal

Следующая тема: Routing.

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

Network routing, routers, routing tables, BGP, OSPF, static и dynamic routes, backend routing, path parameters, query parameters, nested routes, API versioning, middleware, route matching — а также то, что происходит под капотом routing engine.

Это не очередной разбор app.get(), представленный как объяснение routing. Здесь рассматривается весь процесс: от того, как сетевые пакеты находят нужный сервер, до того, как backend определяет нужный участок кода для обработки запроса.

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

Вторая статья из серии: https://medium.com/@anuragdotdev/the-ultimate-guide-to-routing-from-network-packets-to-backend-handlers-64cc4f7fdbfa

👉 @BackendPortal

Чеклист лучших практик для разработки backend-приложений

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

Полезно для pet-проектов и подготовки к собеседованиям 🎁

👉 @BackendPortal