15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Биллинговое решение для хостинг-компаний.
GitHub: https://github.com/Paymenter/Paymenter/
👉 @BackendPortal
Привыкнув к визуальным редакторам вроде VS Code, каждый раз после SSH-подключения к серверу и необходимости править конфиги через Vim не хочется
На GitHub нашёл проект Fresh. Он переносит привычный графический опыт редакторов прямо в терминал.
Поддерживает работу мышью, прокрутку и стандартные хоткеи. Открыл и сразу работаешь, без заучивания команд.
При этом спокойно открывает файлы размером в несколько гигабайт, а потребление памяти практически незаметно.
👉 @BackendPortal
🎬 Что это? А это второй выпуск нового интерактивного шоу «АйТир Лист» от МойОфис
«АйТир Лист» – это шоу, в котором эксперты оценивают технологии, компании, фреймворки и ИТ-решения по шкале от 1 до 4. Каждый выпуск — это 14 табличек от модератора, жаркие дискуссии и итоговый рейтинг, который поможет зрителям разобраться в актуальных трендах и сделать собственные выводы.
Во втором выпуске мы оценим фичи и идиомы C++.
Гости выпуска:
— Данил Черепанов, архитектор Редакторов МойОфис
— Антон Полухин, эксперт-разработчик C++ Техплатформы Городских сервисов Яндекса
🎥 Смотрите наш юбилейный второй выпуск там, где вам удобно:
VK | YouTube | RuTube
Реклама
ООО "НОВЫЕ ОБЛАЧНЫЕ ТЕХНОЛОГИИ"
ИНН: 7703807270
erid: 2W5zFJ7ManC
В SQLite около 155 800 строк кода, а тестовый набор - примерно 92 миллиона строк. Это примерно в 590 раз больше тестов, чем самого кода 🤯
Вот такой уровень тестирования нужен для настоящей продакшен-базы данных. Ниже — какие типы тестов у них есть.
» Тесты на нехватку памяти (OOM)
SQLite не может просто упасть, когда заканчивается память. На встраиваемых устройствах OOM — обычное дело. Они симулируют падения malloc в каждой возможной точке и проверяют, что база корректно это переживает.
» Тесты I/O-ошибок
Диски ломаются. Сеть отваливается. Права могут измениться посреди операции. SQLite подменяет файловую систему на кастомный слой, который может симулировать сбои после N операций, и проверяет, что данные не повреждаются.
» Краш-тесты
Что будет, если питание пропадёт посреди записи? Они симулируют крэш в случайные моменты во время записи, портят несинхронизированные данные, как это делает реальная файловая система, и проверяют, что транзакция либо полностью завершилась, либо чисто откатилась. Никакой порчи данных.
» Fuzz-тестирование
В SQLite кидают кривой SQL, битые файлы базы и случайный мусор. Инструмент dbsqlfuzz прогоняет около 500 миллионов мутаций тестов в день на 16 ядрах.
» 100% покрытие ветвлений
Каждая инструкция ветвления в ядре SQLite проверяется в обе стороны. Не просто «эта строка выполнялась», а «это условие было и true, и false».
Базы данных вообще не прощают ошибок :)
Если хочется копнуть глубже, советую почитать официальную документацию SQLite про их стратегию тестирования. Очень практично и по делу. А если понравился пост - ставь реакцию 👌
👉 @BackendPortal
Обобщённые инвертированные индексы (GIN) - мощный инструмент в Postgres.
Они хороши тем, что переворачивают привычную модель индексации.
Вместо логики вида: строка с ID 2 содержит значение "become a database expert", индекс хранит обратное соответствие: токен "database" указывает на строки с ID 1, 2 и 3, а "expert" — на строку с ID 2.
GIN-индексу на вход подаётся набор значений для каждой строки, которую нужно проиндексировать. Каждое уникальное значение становится ключом в индексе и сопоставляется с набором CTID (идентификаторов кортежей строк), в которых это значение встречается.
У такого подхода есть несколько сценариев применения, и один из самых популярных - полнотекстовый поиск. В MySQL для этого есть отдельный тип индекса FULLTEXT, а в Postgres похожая функциональность строится на более универсальных GIN-индексах.
Как это выглядит на практике:
(a) Добавляем колонку tsvector в таблицу:
CREATE TABLE post (
author TEXT,
publish_date DATE,
content TEXT NOT NULL,
search_vector tsvector
);
UPDATE post
SET search_vector =
to_tsvector('english', content);
CREATE INDEX post_search_idx
ON post USING GIN(search_vector);
SELECT * FROM post
WHERE search_vector @@
to_tsquery('english', 'database & expert');
Postgres CTE
-» небольшие, читаемые блоки SQL
-» можно тестировать запрос по частям
-» переиспользовать фрагменты SQL в других запросах
👉 @BackendPortal
Хорошие новости для пользователей Postgres под конец года. Команда TimescaleDB выпустила и открыла исходники расширения pg_textsearch.
В Postgres уже есть встроенный полнотекстовый поиск, а это расширение делает его более современным и продвинутым за счёт добавления ранжирования BM25.
👉 @BackendPortal
Практический Docker Roadmap
Она включает более 50 практических заданий, дополненных десятками визуальных разборов и несколькими теоретическими глубокими погружениями. На данный момент вы можете изучить:
- Как запускать разные типы контейнеров (веб-приложения, CLI-утилиты, базы данных и т.д.)
- Как перечислять, инспектировать и управлять локальными контейнерами
- Как выполнять команды внутри контейнеров и отлаживать простые проблемы
- Как обновлять контейнерные образы для stateless и stateful приложений
- Как собирать контейнерные образы как профи
...и несколько других тем
https://labs.iximiuz.com/roadmaps/docker
👉 @BackendPortal
Проверяет наличие электронной почты без отправки письма.
https://github.com/reacherhq/check-if-email-exists/
👉 @BackendPortal
Представь, ты стримишь изменения из Postgres в Elasticsearch на Go. В деве всё работает стабильно. Потом растёт трафик, и внезапно сервис перестаёт вывозить…
Профилируешь и упираешься в JSON-сериализацию.
Каждый документ, который уходит в Elasticsearch, нужно закодировать. Когда событий тысячи в секунду, эти микросекунды начинают быстро накапливаться. Стандартная encoding/json удобная, но она сильно завязана на рефлексии.
Рефлексия удобна, потому что универсальна, но за неё платишь скоростью. Это почти всегда медленнее, чем когда структура известна на этапе компиляции.
И да, в любом языке почти никогда нет “одной библиотеки на задачу”. Люди постоянно переписывают одно и то же, и нередко делают быстрее, чем дефолт из коробки.
Так что вместо стандартной encoding/json можно взять пакет jsoniter. По бенчмаркам: декодирование среднего payload у стандартной либы занимает 35 510 ns/op и делает 99 аллокаций. У jsoniter это 5 623 ns/op и всего 3 аллокации. То есть больше чем в 6 раз быстрее и на 97% меньше аллокаций.
Дичь.
Это не значит, что надо срочно переписывать код. Но если у тебя JSON-сериализация в топе на пламеграфе :) переход на jsoniter (или на то, что в текущий момент самое эффективное) может дать ощутимый прирост
И такое есть вообще в каждом языке и почти под любую работу. Пусть этот пост будет напоминалкой: иногда стоит смотреть дальше дефолтов :)
Надеюсь, пригодится. 👍
👉 @BackendPortal
Акторная модель это, по сути, подход, где между процессами/потоками (или акторами) нет общей памяти.
Разные акторы общаются, передавая сообщения. Каждый актор владеет своим состоянием, обрабатывает по одному сообщению за раз и общается с другими только через асинхронные сообщения. Локов нет.
Rust красиво ложится на это через один только трейт Send в трейте актора.
Send означает, что актора можно безопасно перемещать в другой поток. Sync не нужен, потому что ссылка на актора никогда не шарится между потоками. К актору всегда имеет доступ только один поток, и это убирает гонки данных на этапе компиляции.
👉 @BackendPortal
Этот инструмент экономит время на ручном прописывании API.
Вставляешь JSON — на выходе сразу получаешь TypeScript-код.
→ http://app.quicktype.io
👉 @BackendPortal
Команды lsof в Linux, которые реально экономят девопсам часы отладки:
🔸Кто держит порт
lsof -i :5000
lsof -i
lsof -u username
lsof -p 1234
lsof /var/log/syslog
lsof -i TCP
lsof -i UDP
lsof -c nginx
lsof | grep deleted
lsof -i 4
lsof +D /var/log
lsof -i -r 2
lsof -u root -i TCP:80
Заказчик кинул с деньгами? Отправьте его в суд.
Чаще из-за ошибок в договоре правда может быть не на вашей стороне. 8 пунктов для безопасного договора — проверьте прямо сейчас.
В 2026 году требования к IT-компаниям и фрилансерам станут жёстче. Разберитесь с налогами, сайтами и договорами уже сейчас.
Подписывайтесь на LAWLEGKO — канал практикующего юриста Инны Вялковой. Новости от государства и юридические тонкости простым языком.
Или передайте всё юристам: договоры, налоги, реклама — юридическое абонентское сопровождение.
Вы занимаетесь работой, юристы LAWLEGKO — вашим спокойствием.
Подожди, так есть децентрализованная альтернатива GitHub? 😲😲😲
Проект называется Tangled, и его идея в том, чтобы дать тебе полное владение своим кодом, без привязки к центральной платформе.
Можно поднять свои репы через лёгкие узлы knot, либо воспользоваться их управляемым узлом, если не хочется заморачиваться с хостингом.
Функционал привычный: git-воркфлоу, issues, pull requests, комментарии. Но при этом ты контролируешь инфраструктуру и данные.
Если когда-то хотелось GitHub-опыт без единого провайдера сверху, стоит глянуть.
ЗАТЕСТИТЬ
👉 @BackendPortal
Сервер для потоковой трансляции видео, написанный на Go.
GitHub: https://github.com/gwuhaolin/livego/
👉 @BackendPortal
Элегантное разделение ответственности в Apache Kafka даёт кучу возможностей для масштабирования.
Но за это приходится платить компромиссами.
Производитель, потребитель и брокер.
👉 @BackendPortal
Два года назад парень сделал максимально простой демо-пример, который на уровне операционной системы показывает, что происходит, если не использовать пул соединений для Postgres.
С тех пор его рекомендуют даже LLM, и он регулярно получает такой фидбек:
«Впервые наглядно понял, как работает connection pooling».
Это и подтолкнуло поделиться этим видео с вами, друзья 🎷 - смотреть
👉 @BackendPortal
В софте очень часто работают так: система хранит текущее состояние.
Например:
» у пользователя такой баланс
» заказ сейчас в таком статусе
» подписка активна
Event Sourcing предлагает другой подход.
Идея простая:
хранить не финальное состояние, а всю историю изменений.
То есть вместо того, чтобы сохранять
balance = 100
deposit +200
purchase -50
adjustment -50
В небольшом приложении один HTTP-запрос обычно делает всё.
Например, пользователь регистрируется.
Бэкенд сохраняет пользователя, отправляет welcome-письмо, пишет метрики и только потом отвечает. Работает, но пользователь ждёт дольше, а если что-то ломается посередине, может упасть вся операция.
Проблема в том, что в одном потоке смешиваются критичные и второстепенные задачи.
Создать пользователя -» критично. Отправить welcome-письмо -» нет. Когда всё идёт в одном флоу, у всего одинаковый вес, и приложение начинает тормозить.
В более крупных системах это решают через Message Queue.
Бэкенд выступает как producer -» сохраняет пользователя и кладёт сообщение в очередь с отложенной задачей, например «отправить welcome-email». На этом запрос заканчивается и быстро отдаёт ответ.
Позже один или несколько воркеров забирают сообщение из очереди и выполняют задачу. Если отправка письма упала, её можно ретраить, не затрагивая пользователя.
Так создание пользователя и отправка письма перестают зависеть друг от друга.
Обратная сторона -» в системе появляется больше компонентов и растёт сложность.
👉 @BackendPortal
Почему JSON жрёт ваш CPU
Ваш API тормозит. Вы грешите на базу. Потом на сеть. А реальным бутылочным горлышком может быть язык, на котором вы общаетесь.
JSON — это не формат данных. Это текстовая строка.
Каждый раз, когда вы отправляете {"id": 12345}, сервер платит скрытый налог на парсинг. Даже с современными SIMD-оптимизированными парсерами текст упирается в архитектурные ограничения, которых нет у бинарных форматов.
Разбор по инженерке:
1. Стоимость для CPU (машина состояний против арифметики)
JSON (текст):
Чтобы прочитать число 12345, CPU получает поток байт. Даже самые быстрые парсеры вроде simdjson вынуждены работать как машина состояний:
- искать структурные разделители (: и ,)
- проверять escape-последовательности ()
- конвертировать число: проход по ASCII-символам, вычитание '0', умножение на степени 10 и суммирование
Всё это — ветвления, промахи предсказателя и обращения к памяти.
-» Protobuf (бинарь):
Передаёт либо Varint (для маленьких чисел), либо фиксированную ширину (для больших).
Fixed-width (например, fixed32) — это просто memcpy. Парсинга нет вообще.
-» Varint — чтение байт по одному с проверкой старшего бита (MSB), продолжается ли число.
Итог: декодирование сводится к нескольким битовым сдвигам и маскам. Для числовых нагрузок это гарантированно быстрее любого текстового парсинга.
2. Стоимость по пропускной способности (энтропия против избыточности)
JSON:
[{"status": "active"}, {"status": "active"}]
SELECT FOR UPDATE в Postgres фактически делает запись
В heap-странице Postgres у каждого tuple есть заголовок header с метаданными.
Когда транзакция выполняет SELECT FOR UPDATE, у найденных tuple (по предикату) обновляется header: они помечаются как залоченные, а атрибут xmax фиксирует XID транзакции, которая поставила лок.
Конкретно выставляются два бита в infomask заголовка: HEAP_XMAX_EXCL_LOCK и HEAP_XMAX_LOCK_ONLY.
Из-за этого страница становится dirty и это также попадает в WAL, который потом может уехать на standby-реплику.
Позже dirty-страница может быть сброшена на диск background writer-ом.
На commit эти биты очищаются.
Забавно, что операция чтения может породить приличный объём write I/O.
👉 @BackendPortal
Поздравляем, вы на 1 шаг ближе к работе мечты 🥳
Осталось только прочитать этот пост, подписаться на канал и откликнуться на вакансию 😉
Avito Career — место, где Авито делится актуальными вакансиями и стажировками для бэкенд-разработчиков.
Подписывайтесь, чтобы найти ту самую работу ✨
Если ты активно пользуешься JavaScript Intl API, можно выжать немного больше производительности.
Зацени intl-formatter: маленькая обертка, которая добавляет мемоизацию без настроек и при этом сохраняет тот же интерфейс Intl API. В AdonisJS мы такое используем уже много лет.
Бенчмарки: https://github.com/poppinss/intl-formatter?tab=readme-ov-file#benchmarks
👉 @BackendPortal
Разработчик выложил проект ShadowStream, систему отслеживания изменений в базе данных (CDC), построенную на PostgreSQL logical replication.
Цель проекта — ловить любые изменения в реальном времени и передавать их в потоковую инфраструктуру.
Как это работает:
- изменения в базе (INSERT, UPDATE, DELETE) сразу перехватываются через logical replication
- события сериализуются в Protobuf и отправляются в Redis Streams для быстрого доступа
- параллельно те же данные архивируются в Kafka для надежного хранения
- Kafka использует grouped consumer'ов: два обработчика работают параллельно, плюс резервная группа с отдельным offset
- поверх всего в Django Admin добавлена визуализация gRPC-вызовов
Исходники открыты на GitHub
Проект может пригодиться тем, кто работает с потоковой обработкой данных, аналитикой, репликацией или интеграцией микросервисов. 🙂
👉 @BackendPortal
Курс по git на русском прямо в браузере
Проходишь шаги от базовых команд до веток и коммитов, всё через практику.
👉 @BackendPortal
Изоляция рунета ближе, чем ты думаешь
Loading …
██████████████] 99%
Бэкпрешер — ключевая вещь для нормально работающей инфраструктуры.
Когда базы данных, очереди сообщений, коннекшн-пулы и другие системы начинают захлёбываться от нагрузки, как они с этим справляются?
Некоторые продукты просто дают ресурсам выгореть до нуля и в итоге падают в креш или фейл-состояние (OOM и так далее). Реализовать такое поведение проще всего, но дальше начинаются каскадные проблемы, которые могут уложить всю систему и даже привести к потере данных. Так себе вариант.
Подход получше — когда каждый компонент сам отдаёт бэкпрешер своим клиентам. Смысл в том, что если сервис видит, что работает на пределе (лимит подключений, забиты все буферы памяти и прочее), он сообщает об этом клиентам: через явные сигналы или, например, отклоняя новые подключения. То есть он сохраняет своё здоровье ценой того, что часть запросов будет замедлена или отклонена.
Если бэкенды спроектированы так, чтобы уважать сигналы бэкпрешера, внезапные пиковые нагрузки приводят только к деградации производительности, а не выключают всю систему целиком.
👉 @BackendPortal
Go-разработчики обсуждают экспериментальный акторный рантайм, через который прогнали 10 млн сообщений и получили около 30 млн операций в секунду. Проект пока не готов для продакшена, но показал, что базовый паттерн работает эффективно.
Автор использует классическую акторную модель, естественно ложащуюся на примитивы Go - - одна горутина владеет своим состоянием, взаимодействие идёт исключительно через канал сообщений. Это позволяет обойтись без локов и исключить доступ к общему мутируемому состоянию.
Схема проста:
один актор = горутина + mailbox, состояния — приватные, остальная программа общается только через Send(msg), а сам актор крутится в цикле обработки входящих сообщений.
https://github.com/anthdm/hollywood
👉 @BackendPortal
Крыса следит за твоими эндпоинтами, чтобы тебе не пришлось 🐁
statui — TUI-дашборд для проверки здоровья API.
Следи за эндпоинтами, латентностью и фейлами в реальном времени прямо из терминала.
Написан на Rust и собран с помощью ratatui
Тестим здесь: https://github.com/Mohamed-Badry/statui
👉 @BackendPortal