15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Чёрт… Это может перевернуть всё представление об эмуляторах AWS.
Команда разработчиков отказалась от привычного подхода к созданию эмуляторов AWS и представила Floci.
Это один исполняемый файл на Go размером всего 13 МиБ, который менее чем за 1 секунду запускает 45 сервисов AWS (S3, Lambda, DynamoDB, SQS, SNS, IAM, CloudFormation, Step Functions и другие). Никакого Docker. Никакого LocalStack. Никаких счетов за AWS. Никаких 4 ГБ оперативной памяти, занятых контейнерами. Никакого ожидания по 30 секунд.
Достаточно скачать исполняемый файл, запустить его — и у вас локально работает практически вся инфраструктура AWS.
https://github.com/floci-io/floci
👉 @BackendPortal
Golang: Можно было бы ожидать, что лёгкий мьютекс Go окажется быстрее реализации на основе pthread, но на практике всё наоборот.
Solod — подмножество Go, которое транслируется в C, — использует мьютексы pthread. В бенчмарке, где восемь потоков многократно захватывают и освобождают один и тот же мьютекс, реализация на pthread показала производительность почти в три раза выше, чем мьютекс Go.
👉 @BackendPortal
🇷🇺 Разбираешься в радиочипах, оптике и связи? Забери до 1 000 000 рублей за свои инженерные навыки на турнире «Дронкон» 🇷🇺
«Сталинские Соколы» открывают регистрацию на 4-й Всероссийский турнир «Дронкон», который пройдет с 22 по 26 августа.
Турнир пройдет по направлению:
- Инженерное дело: навыки программирования, сборка электронного оборудования, беспроводная связь, оптические системы + стратегия «Битва Дронов»;
Призовой фонд для победителей:
🥇место – 1 000 000 рублей
🥈место – 700 000 рублей
🥉место – 500 000 рублей
Награда за 4-8 места - 100 000 рублей
Пройди заочный онлайн-этап и получи путевку на очный этап турнира в Республику Татарстан!
Перелет, питание, проживание - за счет организаторов.
🇷🇺 Подать заявку и узнать подробности 🇷🇺
Немного разобрался с тем, как работают блокировки в PostgreSQL. Главный вывод: разные SQL-команды захватывают разные режимы блокировок, и многие из них специально сделаны совместимыми друг с другом, чтобы минимизировать конкуренцию за блокировки.
Даже обычный SELECT захватывает блокировку, которая препятствует выполнению некоторых «тяжёлых» операций (например, VACUUM FULL, REINDEX и т. п.). Оказалось, существует удивительно много сочетаний SQL-команд, которые могут или не могут выполняться одновременно.
И ещё: вот отличный сайт, который наглядно показывает в виде графа, какие SQL-команды могут выполняться параллельно.
👉 @BackendPortal
Инсайд: Я думал, что довольно хорошо знаю PostgreSQL, пока не наткнулся на это.
Оказывается, PostgreSQL способен заменить гораздо больше, чем просто базу данных:
* очереди;
* cron-задачи;
* Redis;
* MongoDB;
* векторные базы данных;
* журналы аудита;
* и даже некоторые сценарии использования Kafka.
Я не говорю, что нужно заменить Postgres'ом каждый инструмент в вашем стеке.
Но мне кажется, что большинство стартапов начинают использовать Redis, Kafka, MongoDB и ещё десяток других сервисов гораздо раньше, чем в них действительно возникает необходимость.
Определённо стоит прочитать, если вы разрабатываете backend-системы. Этот материал заставил меня пересмотреть многие свои представления.
👉 @BackendPortal
Хайлоад: производительность и планирование мощностей
Приглашаем на практический курс для Middle/Senior-разработчиков, техлидов, архитекторов, EM и CTO, которые хотят не просто “знать про хайлоад”, а руками разобраться, как работают производительность, нагрузочное тестирование и масштабирование.
Будем выжимать 20–100K RPS из своих сервисов на своей инфраструктуре, строить latency/RPS-диаграммы, искать ограничения в стеке и использовать эти данные для capacity planning. В программе: Linux-инфраструктура, nginx, Prometheus/Grafana, нагрузочное тестирование через wrkx, тюнинг производительности, планирование мощностей.
Вас жду живые онлайн-сессии и практические домашние задания, в ходе которых вы прокачаетесь в вопросах хайлоада, инфраструктуры и переосмыслите архитектурные подходы в более прагматичном, экономичном и инженерном ключе.
📌 Старт потока 13 июля.
Кто мы: R&D-центр Devhands, основатель и автор курса Алексей Рыбак, ex-СТО Badoo и Yum! Brands, член программного комитета Highload.
Изучайте программу и записывайтесь.
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzquZx6p5
Если вы давно хотели интуитивно разобраться, как работает KV Cache в LLM, то это, пожалуй, одна из лучших статей на эту тему.
saad.ahmed1926q/kv-cache-explained-intuitively-2b425a36dfc7" rel="nofollow">https://medium.com/@saad.ahmed1926q/kv-cache-explained-intuitively-2b425a36dfc7
👉 @BackendPortal
НОВИНКА: Устойчивые функции (Durable Functions) в PostgreSQL 🤯
pg_durable — это расширение PostgreSQL. Состояние рабочего процесса, очередь, повторные попытки и восстановление хранятся в Postgres, и оно использует устойчивость Postgres / высокую доступность / резервное копирование / восстановление.
https://techcommunity.microsoft.com/blog/adforpostgresql/introducing-durable-functions-in-postgresql/4526821
👉 @BackendPortal
Разработчик на Rust нашёл реальный баг в компиляторе. 🦀
Parsa отлаживал парсер, который молча падал на валидном входе. После исключения логических ошибок он сузил поиск до одного приведения: bool as u32.
Сгенерированный ассемблер был неверным: пропущенный inc esi означал, что приведение выдавало некорректные значения при определённых условиях.
Это баг категории p-critical + i-miscompile — всего 7 issues в истории rustc были одновременно и тем, и другим. Это значит, что корректно выглядящий Rust-код молча выдавал неверные результаты во время выполнения, без каких-либо предупреждений или ошибок от компилятора.
Команда компилятора Rust исправила его за 18 часов.
Две вещи впечатляют:
→ Как Parsa отследил баг: методичное исключение, пока единственным подозреваемым не остался сам компилятор
→ Как быстро среагировала команда: 18 часов от репорта до исправления для p-critical miscompile
Отличная история о дебаггинге и напоминание, что компиляторы — тоже софт.
http://parsa.wtf/cast
#Rust #RustLang #Compilers #Debugging
👉 @BackendPortal
PostgreSQL 19 продолжает расширять свои возможности.
AI-приложениям нужны не только векторные данные. Им нужны связи:
пользователи → документы
пользователи → темы
пользователи → авторы
Реляционная модель + JSON + векторы + графовые запросы.
Индустрия продолжает добавлять новые базы данных.
А Postgres продолжает устранять причины, по которым они вообще могут понадобиться.
👉 @BackendPortal
При каких условиях Postgres материализует CTE?
Для начала напомним, что такое CTE. CTE (Common Table Expression) — это именованный набор результатов, определяемый перед основным запросом и используемый внутри него.
Когда Postgres материализует CTE, он выполняет его один раз и сохраняет результат в памяти или во временном дисковом хранилище. Нематериализованный CTE, напротив, встраивается (inline) в основной запрос и выполняется как часть его плана выполнения.
Так когда же Postgres материализует CTE?
Ответ: когда CTE используется в основном запросе несколько раз.
Если CTE используется только один раз, Postgres встроит его в основной запрос и выполнит как часть его плана выполнения. Но если CTE используется несколько раз, Postgres материализует его, чтобы не выполнять одну и ту же логику повторно.
Посмотрите на аннотированное изображение с выводом EXPLAIN для достаточно сложного запроса. В этом запросе CTE называется my_cte (привет поклонникам Perl). Вы увидите, что он выполняется один раз, а затем используется в плане выполнения основного запроса как CTE Scan.
Особенности random()
Если CTE содержит volatile-функцию (например, random() или gen_random_uuid()), Postgres материализует его, даже если он используется только один раз. Это связано с тем, что результат CTE может изменяться между выполнениями, а Postgres хочет гарантировать, что в рамках выполнения основного запроса будет использоваться один и тот же результат.
Разумеется, если хочется добавить немного хаоса, можно принудительно указать NOT MATERIALIZED (об этом чуть ниже).
Другие случаи, когда Postgres материализует CTE и не может встроить его в основной запрос:
рекурсивный CTE (WITH RECURSIVE);
использование блокировок (SELECT ... FOR UPDATE);
модификация данных (INSERT, UPDATE, DELETE) с предложением RETURNING.
В целом это вполне логично. Вряд ли вы захотите блокировать таблицу несколько раз или выполнять несколько INSERT прямо внутри одного запроса. В этих случаях выбрать «максимум хаоса» не получится — NOT MATERIALIZED будет проигнорирован.
Принудительная (не)материализация
Для CTE можно явно указать, следует ли материализовать его или встроить в основной запрос, используя ключевые слова MATERIALIZED и NOT MATERIALIZED.
WITH my_cte AS MATERIALIZED (...
WITH my_cte AS NOT MATERIALIZED (...
MATERIALIZEDNOT MATERIALIZEDWHERE из CTE и основного запроса. Этот прием называется Filter Push Down.
Почему используется Event-Driven Architecture?
Представьте систему с двумя микросервисами:
1) payments
2) emails
Когда платеж подтверждён, payments вызывает emails, чтобы отправить чек.
Но приложение растёт. Теперь нужно ещё сгенерировать счёт, обновить метрики и отправить уведомление.
Чтобы это сделать, payments начинает вызывать каждый из них.
Каждая новая функциональность добавляет ещё один вызов. Со временем такой поток становится всё сложнее поддерживать.
Event-Driven Architecture предлагает другой способ коммуникации.
Когда платеж подтверждён:
1) payments публикует событие "payment confirmed".
2) emails отправляет чек.
3) billing генерирует счёт.
4) metrics обновляет дашборды.
Если завтра вы добавите ещё один микросервис, ему просто нужно реагировать на это событие. Payments не меняется.
Вот почему это так хорошо сочетается с микросервисами: каждый сохраняет единственную ответственность и может развиваться без прямой зависимости от остальных.
Очевидно, не всё только преимущества. Система также становится сложнее. Возникают такие проблемы, как повторные попытки, дублирующиеся события, порядок обработки и наблюдаемость.
На практике обычно используется брокер (например, Kafka или RabbitMQ), который получает событие и распределяет его по подписанным микросервисам.
👉 @BackendPortal
PostgreSQL 19 добавит в SQL поддержку графовых запросов.
Можно описывать пути связей вроде:
user → likes → topic ← likes ← peer → follows → creator
Это полезно для рекомендаций, прав доступа, социальных графов, цепочек мошенничества и памяти ИИ.
👉 @BackendPortal
Каталог содержит тысячи файлов, и нужно понять, сколько их там.
Запусти:
find . -type f | wc -l
find . -type f -name "*.txt" | wc -l
.txt на любое расширение)
Как на самом деле работает Git
Большинство использует Git, не понимая, что происходит внутри.
Суть такая:git init
создаёт папку, за которой Git начинает следитьgit add
говоришь Git: «эти изменения пойдут в сохранение»git commit
фиксирует снимок состояния проекта в этот моментgit push
отправляет эти снимки в облако (обычно GitHub)git pull
забирает снимки, которые отправили другиеgit branch
создаёт отдельную линию разработки, где можно работать изолированноgit merge
объединяет эту ветку обратно в основную
👉 @BackendPortal
Создавайте первоклассную документацию для своего API или проекта.
Starlight предлагает всё необходимое: высокую скорость благодаря Astro, встроенную оптимизацию для SEO, доступность и поиск, а также поддержку Markdown, MDX и нескольких языков.
→ http://starlight.astro.build/es
👉 @BackendPortal
Прикол: большинство разработчиков до сих пор не знают, что такое вообще существует.
Буквально полноценный браузер Chromium можно запустить прямо в терминале 🤯
Он поддерживает WebGL и WebGPU, запускается примерно за секунду, работает с частотой до 60 FPS и практически не потребляет ресурсы процессора в режиме простоя. Браузер также работает по SSH без необходимости в оконном сервере, а ещё в нём можно смотреть YouTube прямо из терминала.
Да, YouTube действительно можно смотреть прямо в терминале.
https://github.com/fathyb/carbonyl
👉 @BackendPortal
Git: merge vs rebase
А что предпочитаете вы ?
👉 @BackendPortal
Ребят, тут Авито регистрацию на свой первый CTF открыл с призами до 300 000 рублей на команду 📍
AvitoTech устраивает CTF онлайн с денежным призовым фондом, мерчем и интересными тасками!
Регистрация команд уже открыта по ссылке, а ниже собрали инфу, что предстоит делать во время HoneyBadger CTF AvitoTech.
Возьмите на себя роль медоеда, проверьте защиту пчелиного улья и найдите все скрытые уязвимости в сотах.
Чего ждать от турнира: тасков на веб-уязвимости, инфраструктурных мисконфигов, анализа скомпилированного кода, расследования инцидентов, слабостей шифров, всего, что требует хакерской смекалки. И розыгрыша мерча, помимо основного призового фонда.
Важно: CTF не только для спецов по кибербезопасности — есть отдельная лига для всех, кто любит разбираться, как устроены IT-системы 🐝
Fable 5 монстр: чуваки создали невероятно лёгкий бэкенд, совместимый с Supabase, который работает как единый бинарный файл размером всего около 57 МБ!
Да, внутри уже есть полноценный PostgreSQL с RLS (Row-Level Security), а также встроенные Auth, Storage и Realtime.
https://tinbase.vercel.app/
👉 @BackendPortal
Запомни: Монолит ≠ Модульный монолит ≠ Микросервисы
Многие команды думают, что путь выглядит так:
Монолит → Микросервисы
Но между ними есть важный этап, который многие пропускают... Модульный монолит.
Вот самый простой способ запомнить разницу:
Монолит ➜ одна кодовая база, одно развёртывание, компоненты тесно связаны между собой.
Модульный монолит ➜ одно развёртывание, но кодовая база разделена на хорошо определённые модули с чёткими границами.
Микросервисы ➜ множество независимых сервисов, которые можно разрабатывать, развёртывать и масштабировать отдельно друг от друга.
Простая шпаргалка 👇
✅ Монолит = одно приложение
✅ Модульный монолит = одно приложение, много модулей
✅ Микросервисы = множество независимых приложений
Когда использовать каждый подход?
🔹 Монолит
стартапы и MVP;
небольшие команды;
быстрая разработка;
простое развёртывание.
🔹 Модульный монолит
растущие приложения;
команды, которым нужна чистая архитектура без сложности распределённых систем;
проще тестировать, сопровождать и развивать.
🔹 Микросервисы
большие инженерные команды;
независимое развёртывание сервисов;
разные требования к масштабированию отдельных доменов;
высокая доступность и масштабируемость организации.
Самое распространённое заблуждение. Микросервисы не становятся автоматически лучшим выбором.
Они привносят распределённые транзакции, сетевые задержки, обнаружение сервисов (service discovery), наблюдаемость (observability), версионирование, пайплайны развёртывания и дополнительные операционные издержки.
Во многих случаях грамотно спроектированный модульный монолит оказывается лучшим долгосрочным решением — до тех пор, пока бизнесу действительно не понадобятся распределённые сервисы.
Фраза, которую стоит запомнить
Монолит = простота
Модульный монолит = организованность
Микросервисы = независимость
Лучшая архитектура — не самая сложная, а та, которая решает сегодняшние задачи, не создавая завтрашних проблем.
Ищешь работу? Пусть отклики шлёт ИИ, а не ты.
Пока ты занят делами, агент откликается на hh.ru: до 200 вакансий в день с сопроводительными письмами — персональные, под твою вакансию и под требования работодателя.
Настроил, запустил один раз и забыл. 6000 откликов в месяц сделает за вас
Первые 2 часа — бесплатно.
Оцени результат сразу. Попробовать можно тут
Зачем нужен обратный прокси (Reverse Proxy)?
У вас есть API на Node.js.
Поначалу пользователи отправляют запросы напрямую в приложение, и всё работает отлично.
Но по мере роста проекта появляются новые задачи:
- использовать HTTPS;
- раздавать статические файлы;
- применять ограничение частоты запросов (Rate Limiting);
- масштабировать приложение.
Часть этих задач можно решить прямо в API. Но проблема в том, что тогда ему приходится выполнять две разные роли:
реализовывать бизнес-логику (пользователи, платежи, заказы и т. д.);
решать инфраструктурные задачи (HTTPS, раздача статики, Rate Limiting и т. д.).
По мере появления новых инфраструктурных задач становится логично отделить их от бизнес-логики.
Для этого между интернетом и вашим API добавляют дополнительный слой.
Этот слой называется обратным прокси (Reverse Proxy).
Он принимает входящие запросы и решает, что с ними делать: обработать их самостоятельно или перенаправить в API.
Интернет → Reverse Proxy → Ваш API
Одним из самых популярных решений для реализации обратного прокси является NGINX.
Главное преимущество такого подхода в том, что API может полностью сосредоточиться на бизнес-логике, а обратный прокси берёт на себя управление входящим трафиком до того, как он попадёт в приложение.
Недостаток заключается в том, что в архитектуре появляется ещё один компонент, который необходимо настраивать и поддерживать.
Однако по мере роста приложения такое разделение ответственности обычно значительно упрощает масштабирование и сопровождение системы.
👉 @BackendPortal
Кто-то собрал Kubernetes, который полностью работает в браузере.
Это может быть самый простой способ изучить Kubernetes.
- Не нужен Docker.
- Не нужен Minikube.
- Не нужен Kind.
- Не нужен EKS.
- Не требуется установка.
Просто откройте веб-страницу и начинайте изучать Pods, Deployments, ReplicaSets, Nodes, планирование, сеть и многое другое.
Инженерная работа за этим проектом невероятна.
Kubernetes написан на Go, но вместо компиляции в браузер разработчик переписал ключевые компоненты Kubernetes на TypeScript, чтобы они работали нативно внутри браузера.
Это один из лучших примеров использования ИИ, который я видел.
ИИ помог портировать тысячи строк кода Kubernetes, пока разработчик вручную проверял всё и подтверждал обширными тестами, чтобы убедиться, что поведение соответствует реальному кластеру.
Это не для продакшн-нагрузок.
Он создан для обучения, преподавания, экспериментов и подготовки к DevOps-собеседованиям.
Представьте онбординг новых инженеров или обучение Kubernetes без необходимости тратить час на установку Docker, настройку Minikube или создание EKS-кластера.
Я искренне считаю, что такие проекты изменят то, как мы изучаем инфраструктуру.
Интерактивные лабораторные работы > Статическая документация.
Пост в блоге: https://ngrok.com/blog/i-ported-kubernetes-to-the-browser
👉 @BackendPortal
⚡️ПОСЛЕДНИЙ ДЕНЬ АКЦИИ ЖАРКОЕ ЛЕТО
Таких условий больше не будет
🟦Диплом установленного образца (Системный администратор) - это не просто сертификат о прохождении, это официальный документ, который открывает двери в корп-сегмент и гарантирует железобетонный фундамент в Linux.
🟦Полная база пентеста (Red & Blue Team) - от сканирования инфраструктуры до сложных атак на Active Directory и веб-уязвимостей. Вы начинаете думать и действовать как профессиональный хакер.
🟦Взлом баз данных - глубокое понимание SQL-инъекций и архитектуры БД, чтобы доставать самые ценные активы компаний.
🟦AI-помощники на Python - автоматизация всей рутины. Пока другие работают руками, ваши ИИ-агенты парсят уязвимости и пишут отчеты, умножая ваш чек и скорость.
Самая большая слабость JWT — его гибкость. PASETO устраняет её.
Спецификация JWT позволяет токену самому указывать, какой алгоритм использовать. Это единственное дизайнерское решение стоит за большинством проблем с JWT в продакшене.
Вот что PASETO делает иначе.
1. Атака живёт в заголовке
JWT содержит поле alg, которое указывает свой же алгоритм подписи. Вы можете установить его в "none", и некоторые библиотеки пропустят проверку.
Или взять публичный RSA-ключ, использовать его как HMAC-секрет, подписать через HS256 — и сервер, доверяющий заголовку, примет поддельный токен.
Это атака RS256→HS256 confusion, и она до сих пор ломает реальные системы.
2. PASETO привязывает криптографию к версии
Токен PASETO имеет формат version.purpose.payload. Версия фиксирует набор шифров — нечего согласовывать.v4.public — всегда Ed25519. v4.local — всегда XChaCha20 с BLAKE2b. Нет заголовка alg — нет атаки alg:none и confusion-атак.
3. Вы выбираете назначение, а не алгоритм
Локальный токен (local) зашифрован симметричным ключом. Публичный токен (public) подписан так, что любой с публичным ключом может его проверить.
Стандартный JWT только подписан — payload читается как обычный base64, и секреты утекают, когда люди забывают об этом.
4. Для сессий не нужно ни то, ни другое
JWT безопасны только как короткоживущие токены — минуты, а не недели, на которые тянется сессия. Google делает именно так: JWT используется только для передачи логина между хостами, а сессия в браузере остаётся кукой.
PASETO — лучший выбор для короткоживущего подписанного токена: SSO-переходы, межсервисные вызовы, одноразовое использование.
Для сессий проще кука, подкреплённая Postgres или Redis, а отзыв одной сессии — это удаление одной строки.
Большинство логинов хватаются за токен там, где подошла бы сессия.
https://gist.github.com/samsch/0d1f3d3b4745d778f78b230cf6061452
👉 @BackendPortal
pg_cron — это расширение PostgreSQL, которое запускает задачи по расписанию прямо внутри базы, используя стандартный синтаксис cron. Если ты пишешь фоновые джобы, которые в основном сводятся к SQL-запросам, проще отдать это Postgres’у через pg_cron. Получается проще, стабильнее и без внешнего планировщика.
Настройка
В managed PostgreSQL (например, Crunchy Bridge и похожие провайдеры) pg_cron обычно уже доступен.
Если поднимаешь Postgres сам, ставишь пакет:
sudo apt install postgresql-18-cron
postgresql.conf:shared_preload_libraries = 'pg_cron'
cron.database_name = 'postgres'
shared_preload_librariescron.schedule_in_database.cron.schedule. У неё несколько перегрузок, поведение зависит от количества аргументов.SELECT cron.schedule(
'nightly_vacuum',
'0 3 * * *',
'VACUUM ANALYZE big_table'
);
cron.job.cron.job_run_details.pg_cron используют не только для базы:http)pg_lake)pg_prewarm перед пиками нагрузки
Статья о том, как высокопроизводительная база данных оптимально организует хранение данных на диске в колоночном формате, как используются Bloom-фильтры, как шардинг столбцов помогает повысить уровень параллелизма и т. д., с наглядными иллюстрациями — действительно интересное чтение.
Материал полностью рассчитан на новичков, никаких глубоких знаний сложных структур данных не требуется.
👉 @BackendPortal
Учишь Go?
Выбери свой путь:
1. Go + Gin → Backend API
2. Go + gRPC → Распределённые системы
3. Go + Kafka → Event-Driven системы
4. Go + Kubernetes → Cloud Native
5. Go + Docker → Контейнеры
6. Go + Terraform → Инфраструктура
7. Go + Prometheus → Наблюдаемость
8. Go + Redis → Высокопроизводительное кэширование
9. Go + WebSockets → Real-Time приложения
Один язык. Бесконечно много карьер. 🫡
👉 @BackendPortal
ОДИН РАЗРАБОТЧИК ЗАНОВО ПРИДУМАЛ ФОРМАТ PDF. И проблема, которую он решил, до смешного очевидна.
Банк попросил его предоставить 17 PDF-файлов для оформления ипотеки.
Он открывал их по одному.
Закрывал их по одному.
Объединял их в один файл.
Стало только хуже.
Тогда он подумал: а что, если PDF работал бы как Figma?
Горизонтальная прокрутка — между страницами.
Вертикальная — между файлами.
До него этого никто не сделал.
Поэтому он расширил стандарт PDF, добавив метаданные.
Он придумал новый формат.
Назвал его .pdfx.
Claude сделал 80% проекта за 2 часа.
В этом и разница между тем, чтобы десятилетиями жаловаться на нерешённую проблему… и однажды настолько устать от неё, что взять и исправить всё самому.
https://github.com/AlexandrosGounis/pdfx
👉 @BackendPortal