Backend Portal | Программирование
Open in Telegram
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Show more
Network:📈 Analytical overview of Telegram channel Backend Portal | Программирование
Channel Backend Portal | Программирование (@backendportal) in the Russian language segment is an active participant. Currently, the community unites 16 151 subscribers, ranking 7 808 in the Technologies & Applications category and 40 674 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 16 151 subscribers.
According to the latest data from 07 September, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -161 over the last 30 days and by 5 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 8.09%. Within the first 24 hours after publication, content typically collects 4.95% reactions from the total number of subscribers.
- Post reach: On average, each post receives 1 307 views. Within the first day, a publication typically gains 799 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 0.
- Thematic interests: Content is focused on key topics such as sql, арендатор, строка, индекс, хак.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки
Связь: @devmangx
РКН: https://clck.ru/3FobxK”
Thanks to the high frequency of updates (latest data received on 08 September, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
16 151
Subscribers
+524 hours
-127 days
-16130 days
Posts Archive
JOIN как в ORM: можно ли заставить PostgreSQL понимать связи между таблицами?
В статье разбирают интересную идею: вместо того чтобы каждый раз вручную прописывать
JOIN ... ON, использовать уже существующие связи FOREIGN KEY как навигацию между таблицами.
Автор показывает, почему стандартный SQL до сих пор не умеет нормально использовать FK при построении JOIN, какие подходы уже существовали и как реализовать подобную навигацию в PostgreSQL уже сейчас — без патчей и новых расширений.
Отдельно рассматривается свежая инициатива 2026 года по добавлению key joins в PostgreSQL и проблема неоднозначности связей и неочевидного fan-out при 1:N JOIN.
https://habr.com/ru/articles/1065684/
👉 @BackendPortal
Backend Checklist — День 4: Анатомия HTTP-запроса
Долгое время можно было предполагать, что HTTP request — это какой-то упакованный бинарный формат, который браузер и сервер умеют декодировать. Но это обычный текст. Его буквально можно вручную отправить в socket.
По сети передаются четыре части:
Request line: method, path и version Headers: вся информация о запросе, которая не является самим запросом Пустая строка Body: непосредственно данные, причём body отправляют только некоторые методыПустая строка Она выглядит просто как форматирование. Но именно она сообщает серверу, что headers закончились и следующие bytes — это уже payload. Больше ничто не обозначает эту границу. Content-Length После запроса соединение остаётся открытым, поэтому сервер не может определить окончание body просто по тому, что новые bytes перестали поступать. Он считывает ровно столько bytes, сколько указано в
Content-Length, и ни одним больше.
Укажите 25, но отправьте 20 — сервер будет ждать ещё пять bytes, которые так и не придут.
Укажите 25, но отправьте 34 — оставшиеся девять bytes останутся в buffer и могут быть прочитаны как начало следующего request.
В Django это не просто абстракция. DATA_UPLOAD_MAX_MEMORY_SIZE напрямую использует значение Content-Length и может вызвать RequestDataTooBig ещё до того, как выполнится ваш view. Значение по умолчанию — 2,5 МБ.
Если хотите увидеть весь HTTP request целиком, используйте curl -v.
👉 @BackendPortal
Нашёл отличный репозиторий для тех, кто хочет за выходные собрать настоящий DevOps-проект и добавить его в резюме.
Там 54 практических проекта по AWS, Azure и Kubernetes, Terraform и инфраструктуре как коду, Docker и CI/CD, DevSecOps и безопасности, мониторингу, бессерверным и облачным приложениям.
Можно выбрать проект, собрать его за выходные и получить работу, о которой уже не стыдно рассказать на следующем собеседовании.
https://github.com/DevCloudNinjas/DevOps-Projects
👉 @BackendPortal
Нашёл отличный репозиторий для тех, кто хочет за выходные собрать настоящий DevOps-проект и добавить его в резюме.
Там 54 практических проекта по AWS, Azure и Kubernetes, Terraform и инфраструктуре как коду, Docker и CI/CD, DevSecOps и безопасности, мониторингу, бессерверным и облачным приложениям.
Можно выбрать проект, собрать его за выходные и получить работу, о которой уже не стыдно рассказать на следующем собеседовании.
https://github.com/DevCloudNinjas/DevOps-Projects
👉 @BackendPortal
Backend Checklist — День 3: TLS Handshake
Все знают, что HTTPS шифрует трафик. Но часто упускается, что именно происходит во время TLS handshake. Это ещё не само шифрование, а этап согласования параметров и аутентификации, который должен завершиться до того, как начнётся обычная передача HTTPS-трафика.
Нужно решить две задачи:
> Identity
Сервер отправляет свой TLS certificate. Client проверяет его по доверенной цепочке Certificate Authority (CA). Без аутентификации можно было бы установить зашифрованное соединение не с тем сервером.
> Key exchange
Обеим сторонам нужен общий keying material для symmetric encryption, но сам секрет не передаётся по сети. Вместо этого стороны обмениваются публичными значениями и независимо друг от друга вычисляют один и тот же секрет. Сам секрет при этом никогда не передаётся.
В TLS 1.3 handshake процесс выглядит так:
• ClientHello: поддерживаемые версии TLS, cipher suites и key share
• ServerHello: согласованные параметры и key share сервера
• Certificate: сервер подтверждает свою identity
• Client проверяет certificate
• Обе стороны вычисляют traffic keys
• После этого application data защищаются с помощью symmetric encryption
Самое интересное здесь — latency. TLS выполняется после TCP handshake, а не вместо него. Новое TLS 1.2-соединение может потребовать ещё два дополнительных round trips поверх одного round trip для TCP.
То есть получается три round trips ещё до того, как HTTP request сможет дойти до сервера. В TLS 1.3 полный handshake был сокращён до одного дополнительного round trip. А при использовании session resumption TLS 1.3 также может поддерживать 0-RTT early data.
Именно поэтому просроченный или недоверенный TLS certificate способен полностью сделать сайт недоступным. Шифрование не перестаёт внезапно работать. Client просто не проходит проверку identity — поэтому TLS handshake не завершается.
👉 @BackendPortal
12 ключевых сетевых протоколов которые должен знать каждый
Без этих протоколов не обходится ни одно сетевое взаимодействие. От передачи веб-страниц и синхронизации времени до защиты соединений и доставки писем это фундамент, на котором строится интернетСохраняй пригодится 🕵️♂️ 👉 @BackendPortal
Backend Checklist — День 2: TCP Handshake
Все могут повторить: SYN, SYN-ACK, ACK. Три пакета, соединение установлено, идём дальше. Но часто упускается главное — для чего на самом деле нужны эти три пакета.
Это не просто «приветствие». Обе стороны выбирают начальный sequence number, сообщают его друг другу, а затем каждая сторона должна подтвердить, что получила sequence number другой стороны.
• Client отправляет SYN со своим начальным sequence number
• Server отвечает SYN-ACK: отправляет свой начальный sequence number и подтверждает получение номера клиента
• Client отправляет ACK, подтверждая sequence number сервера
Три пакета — это минимум, необходимый обеим сторонам для синхронизации sequence numbers и подтверждения надёжности соединения. Именно поэтому пакетов три, а не два.
Где появляются дополнительные затраты: При обычном TCP handshake ни один из этих пакетов не содержит данные вашего приложения. HTTP request отправляется только после завершения handshake.
Если round trip составляет 200 мс, то 200 мс уже будут потрачены только на установление соединения — ещё до того, как сервер получит HTTP request. Затем TLS добавляет сверху свои round trips.
Именно поэтому существуют keep-alive, HTTP persistent connections и connection pooling. Основные затраты связаны не с созданием самого socket, а с необходимостью совершить ещё один round trip через сеть.
Повторное использование уже установленного соединения позволяет не платить эту цену в виде latency снова.По этой же причине сервер хранит незавершённые попытки соединения в SYN backlog, пока ожидает финальный ACK. А заполнение этого backlog большим количеством SYN-запросов, которые никогда не завершают handshake, является реальным вектором атаки SYN flood. 👉 @BackendPortal
+2LeetCode для DevOps — 70+ реальных хардкорных задач
Коллекция практических заданий для DevOps и backend-инженеров. Все задачи основаны на реальных сценариях, имеют разные уровни сложности и авто-проверку решений
Тренируйся легко 💪
👉 @BackendPortal
Backend Checklist — День 1: DNS Resolution
Все описывают DNS как «преобразование доменного имени в IP-адрес». Это действительно так, но такое объяснение скрывает часть, которая на практике и вызывает проблемы:
DNS — это не один lookup, а цепочка кешей, и обновляются они не одновременно.
Как работает lookup: ваше устройство не знает IP-адрес, стоящий за доменным именем, поэтому запрос проходит по цепочке, пока не доберётся до сервера, у которого есть нужный ответ:
• Устройство обращается к resolver
• Resolver обращается к root servers, которые указывают на серверы зоны
.com
• Серверы .com указывают на серверы, отвечающие за конкретный домен
• Последний сервер содержит нужный ответ, который затем возвращается обратно на устройство
Где появляется кеширование: на обратном пути ответ кешируется, причём каждый кеш хранит его в течение своего времени. Кеширование происходит не на каждом уровне, но обычно задействованы:
• Браузер и OS
• Локальный DNS forwarder, например домашний роутер
• Recursive resolver, используемый вашей сетью
У каждого из них есть свой TTL (Time to Live), который отсчитывается независимо.
Почему один и тот же домен может указывать на разные IP-адреса: поскольку кеши истекают в разное время, изменение DNS не доходит до всех пользователей одновременно. Каждый получает обновлённые данные только после того, как истекут кеши перед ним.
• После deploy у вас всё может работать, а у коллеги — нет: ваш кеш уже получил новый IP, а его ещё хранит старый
• Перед миграцией имеет смысл заранее уменьшить TTL: чем он меньше, тем быстрее истекает кеш и тем меньше пользователей продолжают получать старый ответ
Где это встречается на практике: при планировании миграций, разборе ситуаций «у меня работает, а у него нет», а также при понимании того, почему CDN может направлять один и тот же домен на разные серверы в зависимости от региона.
👉 @BackendPortal
Git: шпаргалка для новичков
Working Directory: Рабочая директория, здесь вы редактируете файлы проекта
Команда:
git add - добавить изменения в индексStaging (Index) подготовительная область: Содержит изменения, которые будут добавлены в следующий коммит Команда:
git commit - зафиксировать изменения в локальном репозиторииLocal Repository локальный репозиторий: Хранит историю всех коммитов на вашем компьютере Команды:
git push - отправить коммиты в удалённый репозиторий git fetch - получить новые коммиты с удалённого репозитория без слияния git pull - получить и объединить изменения из удалённого репозиторияStash временное хранилище изменений: Используется, когда изменения нужно временно убрать, но не коммитить Команды:
git stash - сохранить незавершённые изменения git stash - apply применить изменения из stash, не удаляя их git stash pop - применить и удалить сохранённые измененияRemote Repository удалённый репозиторий: Общий сервер проекта GitHub, GitLab, Bitbucket Лайк если полезно ❤️ 👉 @BackendPortal
Чеклист лучших практик для разработки backend-приложений
Удобный и структурированный чеклист для всех, кто разрабатывает backend: от настройки проекта и API-дизайна до тестирования, логирования и деплоя. Можно буквально пройтись по пунктам и улучшить свой текущий сервис
Полезно для pet-проектов и подготовки к собеседованиям 🎁
👉 @BackendPortal
7,2 млн рублей призового фонда и реальные задачи космической отрасли 🚀
В сентябре пройдет серия КосмоХакатонов для студентов, молодых ученых и специалистов.
Участникам предстоит за два дня разработать собственное решение, поработать с экспертами и представить проект жюри.
Участников ждут:
🛰 реальные задачи космической отрасли
👥 команды от 3 до 5 человек
💻 очный и онлайн-форматы
🧑💻 работа с экспертами и трекерами
🏆 финал в Москве
Первый КосмоХакатон стартует уже 4 сентября в Ростове-на-Дону.
Дальше серия продолжится в Красноярске, Нижнем Новгороде, Благовещенске и Санкт-Петербурге, а завершится финалом в Москве.
Участие бесплатное. Присоединиться могут студенты, аспиранты, молодые ученые и специалисты от 18 лет.
🔗 Зарегистрироваться: https://космохакатон.рф
Следующая тема: 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 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Недавно довольно часто пользуюсь Ansible — очень сильный проект с открытым исходным кодом, уже 69,1 тысячи звёзд на GitHub.
1️⃣ Автоматизацию можно описывать обычными текстовыми сценариями и использовать их для развёртывания приложений, настройки серверов и управления облачной инфраструктурой.
Недавно мне нужно было подготовить окружение сразу на трёх новых машинах. Написал один playbook — и всё поднялось почти автоматически. Вручную через команды на это ушло бы минимум пару часов.
2️⃣ Все машины управляются по SSH, при этом на целевые серверы не нужно ставить отдельный клиент.
Раньше я уже обжигался на зависимости SaltStack от агента, поэтому подход Ansible реально удобнее. Поменял конфигурацию — и можно сразу раскатить её хоть на сотню машин.
3️⃣ Синтаксис довольно близок к обычному английскому, поэтому новичок может разобраться буквально после беглого просмотра документации.
В прошлом месяце я автоматизировал сбор логов в компании. Руководитель думал, что там какая-то сложная система, хотя по факту получилось около 30 строк конфигурации.
Тем, кто работает с ИИ, тоже стоит посмотреть на Ansible. Сам подход к устройству системы очень полезно изучить.
Он столько лет остаётся популярным не просто так. Ansible делает инфраструктуру как код максимально прямолинейной, без лишнего нагромождения терминов.
Среди знакомых мне инженеров по эксплуатации его используют почти все, а в вакансиях это уже фактически стандартный навык.
А чем вы обычно автоматизируете развёртывание ИИ-сервисов и запуск экспериментальных окружений — своими скриптами или сразу через Ansible?
https://github.com/ansible/ansible
👉 @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
Настоящая находка среди репозиториев.
В нём собраны все основные шаги по защите и усилению безопасности Linux-сервера.
Если у вас есть VPS, стоит сохранить:
→ https://github.com/imthenachoman/How-To-Secure-A-Linux-Server
👉 @BackendPortal
Все говорят «поставь кэш». Но почти никто не показывает, где система реально развалится.
Breakscale — это не обычный генератор нагрузки. Это симулятор архитектуры, где ты собираешь систему, постепенно увеличиваешь трафик и смотришь, что сломается первым.
В демонстрации:
2 запроса/с — всё зелёное
840 запросов/с — 99% запросов падают
И самое интересное — узкое место вообще не в API. Обе базы данных загружены на 99,9%.
Вот чему обычная статичная схема архитектуры тебя никогда не научит.
Внутри есть 33 компонента: балансировщики нагрузки, кэши, очереди, реплики, автоматические выключатели и многое другое.
Плюс 23 готовых сценария вроде retry storm, cache-aside, шардинга и автомасштабирования.
Задержки p50, p95 и p99 здесь реально считаются, а не берутся из воздуха. Незавершённая работа продолжает занимать ресурсы. Можно даже устроить хаос, убить один из узлов и посмотреть, выдержит ли архитектура.
k6 на боевой системе это не заменит.
Но как тренажёр системного проектирования перед тем, как трогать реальную инфраструктуру, выглядит очень круто.
Открытый исходный код.
Демо
https://breakscale.tech](https://breakscale.tech
GitHub
https://github.com/xevrion/breakscale
👉 @BackendPortal
+4⚡️⚡️Joker 2026 — теперь больше, чем Java-конференция. Что изменилось?
Огромные системы на Java будут жить еще много лет и знание платформы никак не обесценится. Однако сама работа инженера меняется. Код всё чаще можно поручить машине, а вот ответственность за архитектуру и рабочий продукт — нет.
В этом году Joker пройдет в два дня: 14 октября разберем инженерную базу и современные практики, а 15-го обсудим разработку будущего, перераспределение ответственности и изменение профессии в целом. Поговорим про замысел, рабочее окружение и реализацию идей инженера.
Но сегодня важно не просто знать «как написать», а понимать, что именно мы строим.
Поэтому организаторы подготовили подборку докладов, которые вас точно заинтересуют — в ней собраны темы конференции, максимально близкие к устройству самой Java-платформы.
Трек Core Java — про JVM, JIT и AOT, FFM API, Vector API, Valhalla и будущее языка. Среди спикеров и хорошо знакомые Java-сообществу лица, и те, кого вы увидите на нашей сцене впервые.
Собрали доклады по тематике Core Java первого дня на карточках. Подробности и расписание — на сайте.
🔥 А по промокоду
BackendPortal можно получить скидку на персональный билет
Купить билет
Реклама. ООО «Джуг Ру Груп». ИНН 7801341446