15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Git Workflow
> git add
↳ Добавляет изменения из рабочей директории в область подготовленных файлов (staging area)
> git commit
↳ Сохраняет снимок текущих подготовленных изменений в локальном репозитории с сообщением
> git push
↳ Отправляет коммиты из локального репозитория в удалённый (например, GitHub)
> git fetch
↳ Загружает изменения из удалённого репозитория, не применяя их локально
> git merge
↳ Объединяет изменения из одной ветки в другую
> git pull
↳ Сначала делает fetch, затем merge — подтягивает изменения из удалённого репозитория в текущую ветку
> git diff
↳ Показывает изменения, которые ещё не были добавлены в staging или закоммичены
> git diff HEAD
↳ Показывает разницу между текущими файлами и последним коммитом
> git status
↳ Показывает текущее состояние рабочей директории и staging area
> git branch
↳ Показывает все локальные ветки
> git checkout
↳ Переключает ветку или создаёт новую
> git log
↳ Показывает историю коммитов в текущей ветке с подробностями
> git stash
↳ Временно сохраняет незакоммиченные изменения и позволяет применить их позже
> git rebase
↳ Переносит коммиты из одной ветки в другую (меняет историю)
> git reset
↳ Откатывает изменения в рабочей директории и возвращается к конкретному коммиту
> git revert
↳ Отменяет изменения, создавая новый коммит (в отличие от reset)
> git cherry-pick
↳ Применяет отдельные коммиты из одной ветки в другую
📁 Рабочая директория (Working directory)
↳ Папка, где ты вносишь изменения в файлы проекта
📁 Staging area (область подготовленных файлов)
↳ Позволяет выбрать, какие изменения пойдут в следующий коммит
📁 Локальный репозиторий
↳ Версия проекта, хранящаяся на твоём компьютере
📁 Удалённый репозиторий
↳ Версия проекта на сервере (например, GitHub, GitLab)
👉 @BackendPortal
Rate limiting в Go Fiber (стратегия Sliding Window)
Rate limiting необходим для защиты сервисов от злоупотреблений.
Go Fiber отлично поддерживает middleware, такие как limiter, которые позволяют легко реализовать ограничение запросов.
Вот простой пример с использованием стратегии Sliding Window, IP-белого списка и кастомного извлечения ключа (актуально при использовании reverse proxy)
👉 @BackendPortal
Если хочешь безопасные API-запросы — нужно реализовать идемпотентность.
Что такое идемпотентность:
— Предотвращает дублирование действий (например, двойные списания или повторные заказы)
— Позволяет безопасно повторять запросы при сбоях
— Повышает надёжность в распределённых системах
👉 @BackendPortal
Запусти своего ChatGPT локально через Docker Compose
Устал от лимитов и задержек?
Разверни у себя полноценного AI-ассистента, как ChatGPT — с помощью open-source LLM (например, Ollama) + Open WebUI.
Всё запускается одной командой через Docker Compose.
Быстро, удобно, полностью под твоим контролем.
Идеально для локальной разработки и приватного использования 🤍
👉 @BackendPortal
💻 Открытый вебинар «Модели межсервисного взаимодействия».
Изучите различные модели взаимодействия между микросервисами и выберите оптимальный подход для вашего проекта
🗓 28 мая в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «Software Architect».
На вебинаре вы узнаете:
✔️ Основные принципы и типы межсервисного взаимодействия.
✔️ Синхронные и асинхронные модели взаимодействия: плюсы и минусы.
✔️ Использование API Gateway и Service Mesh для управления трафиком.
✔️ Паттерны и лучшие практики для надежного и масштабируемого взаимодействия.
✔️ Примеры успешных реализаций межсервисного взаимодействия в реальных проектах.
Вебинар будет полезен:
- Разработчикам, работающим с микросервисной архитектурой.
- Архитекторам ПО, стремящимся оптимизировать межсервисное взаимодействие.
- Backend и Fullstack разработчикам, заинтересованным в улучшении взаимодействия между сервисами.
- DevOps-инженерам, отвечающим за развертывание и управление микросервисами.
🎁 Всем участникам вебинара дарим промокод, который дает скидку на обучение - SoftwareArc_06
👉 Регистрация на вебинар: https://otus.pw/D6Mg/
#реклама
О рекламодателе
Многие Cloud-инженеры думают, что load balancer — это просто про распределение трафика.
Но в современной облачной архитектуре у него гораздо больше применений.
Вот визуалка, чтобы прояснить это
👉 @BackendPortal
Кто то думает, что нужно ускорять API вот так:
– Везде добавить кэш
– Кэшировать каждый эндпоинт, даже динамический
– Считать, что если кэш сработал — значит, всё быстро
Как на самом деле ускоряют API:
– Оптимизируют медленные запросы к базе
– Убирают синхронную логику, блокирующую основной поток
– Сначала профилируют и устраняют реальные узкие места, а не маскируют их кэшем
Кэш — это финальный этап оптимизации, а не первый.
Используй его, чтобы масштабироваться, а не выживать 🏹
👉 @BackendPortal
Что такое Model Context Protocol и почему о нем все говорят в AI индустрии?
29 мая в 11:00 команда KTS — IT–компания, основанная выпускниками МГТУ и создающая IT-продукты для крупного бизнеса с 2015 года, проведёт вебинар для руководителей проектов и разработчиков. Если вы работаете с ИИ или просто следите за развитием LLM — этот вебинар для вас.
Model Context Protocol — один из новых стандартов взаимодействия LLM с реальным миром, выпущенный Anthropic. MCP активно внедряется во множество инструментов, таких как: Cursor, Claude, n8n, Zed и другие. Он открывает возможности по легкому встраиванию самых разнообразных систем в LLM, превращая языковые модели в "многоруких помощников", не прибегая даже зачастую к программированию.
Что будет на вебинаре?
✅ Проведем экскурс в function/tool calling в LLM - как языковые модели могут оперировать фактами из реального мира
✅ Расскажем о появлении Model Context Protocol (MCP): что дает новый протокол?
✅ Продемонстрируем архитектуру взаимодействия MCP-серверов и клиентов
✅ Покажем практические примеры использования в Claude Desktop, Cursor, n8n
✅ Объясним, как написать свой собственный MCP-сервер (Python SDK, Node.js SDK) и интегрировать в свои процессы
Также на вебинаре поговорим о том, как собрать MCP-сервер без кода на n8n, где искать существующие MCP-серверы, что существует кроме MCP?
Если вы хотите понять, куда движется интеграция ИИ, и как использовать это в своих продуктах или проектах — приходите.
❗️Регистрация на вебинар не требуется! Просто переходите в канал и следите за обновлениями.
Реклама. ООО "Студия КТС", ИНН: 7733257480, erid: 2VtzqwWP3C8
Изучи эти паттерны выполнения на бэкенде, чтобы прокачать скиллы
Любому бэкенду нужен способ обрабатывать запросы и выполнять задачи.
То, как ты это реализуешь — называется паттерн выполнения (execution pattern).
Это базовое архитектурное решение, от которого зависит производительность и масштабируемость твоего приложения.
Вот три основных подхода, которые стоит знать:
1. Один поток на запрос (Thread-per-Request)
> Каждый входящий запрос обрабатывается в своём отдельном потоке.
> Этот поток сам всё делает — считывает данные, обрабатывает, отправляет ответ.
➕Подходит для простых приложений или когда важна изоляция между запросами (если один упадёт — остальным не помешает).
➖Много потоков = больше памяти и нагрузки на CPU. Переключения между потоками тоже дают ощутимую просадку при нагрузке.
2. Событийная модель (Event-Driven) — паттерн реактора
> Один (или несколько) потоков слушают события: входящие запросы, завершённые I/O и т.д.
> Для каждого события вызывается нужный колбэк.
➕Отлично справляется с большим количеством соединений — минимум затрат, не нужно плодить потоки.
➖Если какая-то задача долго выполняется, она может "забить" event loop, и сервер станет неотзывчивым.
(Чтобы решить это — используют chunking, воркеры или отдельные процессы.)
Хорошо бы понять следующее: 😡
[ I/O-зависимые задачи ] — неблокирующий ввод/вывод (Non-Blocking I/O)
> Такие задачи (например, сеть или файл) работают асинхронно и отлично подходят под событийную модель.
> Event loop отдаёт их системе и идёт дальше.
> Когда операция закончится — приходит сигнал, и вызывается нужный обработчик.
> Это позволяет loop’у оставаться отзывчивым даже при куче одновременных операций.
[ CPU-зависимые задачи ]
> Тут уже тяжёлые вычисления, которые могут надолго занять процессор.
> В однопоточном event loop-е такие задачи всё блокируют — и это может "положить" весь сервер.
3. Асинхронный подход — корутины, промисы, future-объекты
> Позволяет запускать задачу и не ждать, пока она завершится. Всё работает через async/await, промисы или колбэки.
Важно: Любая асинхронщина — это по сути событийная модель, потому что асинхронные операции вызывают события (например, "готово" или "ошибка").
Но. Не любая событийная система — асинхронная.
Даже event-driven система может использовать блокирующий I/O, если loop ждёт завершения каждой операции.
Событийное программирование — это просто способ реагировать на происходящее 🍻
👉 @BackendPortal
Многие облачные инженеры до конца не понимают, какие бывают типы DNS-записей в AWS и как они работают
Эта шпора для вас, чтобы помочь лучше понять
🔥 — спасибо
👍 — ого
👉 @BackendPortal
Наткнулся на годную карту по System Design от ByteByteGo — охватывает всё
От API-дизайна и баз данных до масштабирования, безопасности и DevOps
Если хочешь разбираться в архитектуре систем ставь лайк 💖
👉 @BackendPortal
Удалённый доступ к Docker-демону с другой машины
Иногда бывает нужно запускать команды Docker с отдельной машины, где установлен только Docker CLI, но не сам движок. Например, Docker работает на домашнем сервере, а управлять им хочется с ноутбука или рабочей машины.
Чтобы это настроить, можно открыть доступ к Docker-демону по TCP — для этого нужно обновить daemon.json на сервере 🪄
👉 @BackendPortal
Лайфхаки визуального сторителлинга 😉
Рассказываем, почему это полезно и как его построить, чтобы было понятно всем: и менеджерам, и разработчикам, и дизайнерам ⬆
И да, вы справитесь, даже если не умеете рисовать! Александр Зинченко, СТО Яндекс 360, поделился инструментами для быстрых и удобных скетчей. А ещё рассказал про сложности передачи идей в проектных командах, которые можно решить с помощью визуального сторителлинга 😎
Больше интересной и полезной информации в канале от команды Яндекс 360
Только начинаешь работать с Linux или скриптами?
Этот 6-часовой курс от freeCodeCamp — именно то, что тебе нужно 💪
Простой, понятный и абсолютно бесплатный
> https://youtu.be/sWbUDq4S6Y8?si=heWoH-o1DCiK2xQ1
👉 @BackendPortal
Устали управлять Linux-серверами только через терминал?
Cockpit — это современный веб-интерфейс для управления Linux-серверами. Он лёгкий, работает в реальном времени и идеально подходит, когда хочется видеть, что происходит, не открывая десяток вкладок с терминалом. ✍️
С его помощью вы можете:
> Просматривать логи, загрузку системы и службы
> Управлять хранилищем, сетью и пользователями
> Обновлять систему прямо из браузера
Дополнительно можно подключить модули для управления:
> Podman (контейнеры)
> Samba (обмен файлами)
> KVM (виртуальные машины)
Ставь лайк если полезно
👉 @BackendPortal
Хочешь прокачать навыки работы с API?
Попробуй Dragon Ball API — бесплатное открытое API, созданное для фанатов и разработчиков
– Данные о персонажах, расах, трансформациях
– Удобный REST-интерфейс
– Отлично подходит для pet-проектов и практики
→ http://web.dragonball-api.com
👉 @BackendPortal
Ты можешь обойти 99% конкурентов в системном дизайне, просто делая то, что большинство игнорирует:
> Изучай реальные архитектуры, а не только учебные примеры.
> Разбирай системы, которыми пользуешься каждый день — Slack, Uber и т.д.
> Проговаривай вслух плюсы и минусы разных решений
> Сфокусируйся на базе: масштабируемость, согласованность, доступность.
> Рисуй простые и понятные схемы, которые рассказывают историю.
> Пиши и делись своими дизайнами.
> Получай фидбек от опытных инженеров.
> Будь стабилен и регулярно прокачивай мышление.
Системный дизайн — это не талант. Это навык. А навыки развиваются 😊
👉 @BackendPortal
Топ-4 стратегии масштабирования в Kubernetes
1. HPA — Horizontal Pod Autoscaler
> Масштабирует в ширину: добавляет/удаляет поды в зависимости от метрик (CPU, память и т.п.)
2. VPA — Vertical Pod Autoscaler
> Масштабирует в глубину: увеличивает ресурсы (CPU/RAM) у уже запущенных подов
3. Cluster Autoscaler
> Когда не хватает нод для запуска подов — автоматически добавляет новые ноды в кластер
4. Predictive Autoscaling
> Масштабирование на основе предсказаний (ML): KEDA + метрики → масштаб ещё до того, как нагрузка реально вырастет
👉 @BackendPortal
Эта картинка наконец-то помогла мне понять "низкую связанность и высокую когезию" — и тебе тоже поможет.
Разберём оба термина простыми словами:
> Высокая когезия (High Cohesion)
Компоненты или модули системы должны отвечать за одну задачу или схожий набор данных.
Представь себе аккуратный ящик с инструментами:
— в одном отсеке — только отвёртки,
— в другом — молотки,
— и так далее.
Каждый отсек (модуль или класс) — когезивный, потому что содержит логически связанные вещи.
Так проще находить нужное и не путаться.
Высокая когезия делает код понятным, удобным в поддержке и переиспользуемым.
> Низкая связанность (Low Coupling)
Здесь речь про минимальные зависимости между модулями.
Если один модуль меняется — другим всё равно.
Пример — поезд: можно отцепить и заменить один вагон, не трогая остальные.
То же самое и в коде: модули можно модифицировать или заменять по отдельности.
Вместе они дают:
> модульную архитектуру
> гибкость
> лёгкость поддержки
Компоненты легко понимать и разрабатывать отдельно — благодаря когезии.
Их легко комбинировать и заменять — благодаря слабой связанности.
Ставь лайк если пост понравился 😎
👉 @BackendPortal
Шпаргалка по паттернам проектирования
Поблагодарить можно лайком 🌹
👉 @BackendPortal
Как мы строим новое облако MWS — рассказываем в технических статьях «под капотом».
Читайте и берите идеи в свои проекты.
➡️ Сетевая телеметрия для облака — от протоколов до продакшена
Про BFD, TWAMP и STAMP, зачем нам push-модель и gNMI, и что происходит, когда Telegraf не дружит с Kafka.
➡️ Как мы наливаем Kubernetes на железо и управляем десятками кластеров
Рассказываем про платформу собственной разработки — Piñata.
➡️ IAM в облаке: от логина до сервисных агентов
RBAC, сервисные учётки, HMAC-ключи — и почему у нас нет «режима бога».
➡️ Как устроен Compute: декларативный API, реконсиляция и немного геймдева
Рассказываем про архитектуру Compute в MWS и наш подход к его разработке.
🔗 Подпишись на облачный хаб MWS
⏩️Там регулярно рассказываем, как строим новое облако с нуля.
tproxy — сетевой прокси для бэкендеров
Когда нужно разобраться в сетевых соединениях, gRPC, MySQL-пулах или просто понять, почему всё лагает — tproxy решает.
Это лёгкий open-source инструмент, который перехватывает TCP-трафик и в реальном времени показывает, что происходит.
> Мониторит все TCP-соединения в реальном времени
> Показывает стадии gRPC, HTTP2, Redis, MongoDB и других протоколов
> Видит сетевые метрики: RTT, ретрансляции
> Анализирует соединения с базой: общее число, пик, пул
> Можно замедлить/задержать трафик для тестов
Установка — одна команда в Docker
💪💪
👉 @BackendPortal
Шпаргалка по DOCKER
Всё, что тебе нужно — в одном месте 👑
👉 @BackendPortal
HTTP совет
Идемпотентные методы можно безопасно повторять — без побочных эффектов.
> GET, PUT, DELETE, HEAD, OPTIONS → идемпотентны
> POST → не идемпотентен
Почему это важно:
> Делает API предсказуемыми
> Позволяет повторять запросы при сбоях сети
> Упрощает кэширование, мониторинг и отладку
👉 @BackendPortal
Использование Git submodule в GitHub Actions с приватными репами
Если в проекте используются Git submodule — особенно приватные — во время checkout в GitHub Actions могут возникнуть проблемы с доступом.
Submodule — это просто вложенные репозитории внутри основного. Их применяют, когда проект зависит от другого репо. Но по умолчанию GitHub Actions может не иметь доступа к приватным submodule при выполнении actions/checkout.
Чтобы это исправить, нужно использовать персональный fine-grained токен доступа с правами только на чтение нужного репозитория. Затем токен подключается в workflow ❤️
👉 @BackendPortal
👩💻 Всем программистам посвящается!
Вот 17 авторских обучающих IT каналов по самым востребованным областям программирования:
Выбирай своё направление:
👩💻 C/C++ — /channel/cpp_ready
👩💻 C# & Unity — t.me/csharp_ready
🖥 Базы Данных & SQL — t.me/sql_ready
👩💻 Python — t.me/python_ready
👩💻 Java — t.me/java_ready
👩💻 Всё IT — t.me/it_ready
🖼️ DevOps — t.me/devops_ready
🤔 Хакинг & ИБ — t.me/hacking_ready
👩💻 Linux — t.me/linux_ready
👩💻 Bash & Shell — t.me/bash_ready
📱 GitHub — t.me/github_ready
👩💻 Нейросети — t.me/neuro_ready
👩💻 Frontend — t.me/frontend_ready
📱 JavaScript — t.me/javascript_ready
👩💻 Backend — t.me/backend_ready
📖 IT Книги — t.me/books_ready
🖥 Design — t.me/design_ready
📌 Гайды, шпаргалки, задачи, ресурсы и фишки для каждого языка программирования!
Можно заучить паттерны — и всё равно построить систему, которая развалится.
Потому что настоящий system design идёт уровнями.
Уровень 0 — Базовые основы:
> Клиенты шлют запросы
> Серверы обрабатывают логику
> Базы данных хранят данные
Ты учишь HTTP-методы, коды статуса, что такое REST API. Выбираешь между SQL и NoSQL, не до конца понимая зачем.
Ты ещё не бэкендер, пока не чинил продовый 500-ый из-за пропущенной проверки на null
Уровень 1 — Освоение базовых компонентов:
> Балансировщики нагрузки
> Кэши (Redis, Memcached) для снижения нагрузки на БД
> Фоновые воркеры для асинхронных задач
> Очереди (RabbitMQ, SQS, Kafka) для разцепления компонентов
> Реляционные и документные БД — с пониманием, где что уместно
Ты понимаешь, что чтение и запись масштабируются по-разному.
Узнаёшь, что согласованность, доступность и устойчивость к разделению — не всегда совместимы. Перестаёшь спрашивать "SQL или NoSQL?" и начинаешь с "Какой у нас паттерн доступа?"
Уровень 2 — Архитектура под сложность:
> Разделение путей чтения и записи
> Circuit breakers, повторы и таймауты
> Rate limiting и backpressure, чтобы не положить систему
> Идемпотентные эндпоинты
Ты начинаешь рисовать sequence-диаграммы до написания кода. Перестаёшь мыслить сервисами — начинаешь думать границами.
Уровень 3 — Надёжность и наблюдаемость:
> Структурированные логи, метрики, трассировки
> Health checks, дашборды и алерты
> SLO — чтобы понимать, что считается «достаточно хорошо»
> Chaos-тесты для симуляции сбоев
> Correlation ID — чтобы отслеживать цепочку вызовов
На этом уровне тебе важнее MTTR, чем MTBF. Ты понимаешь, что самые опасные системы — это те, которых не видно.
Уровень 4 — Масштабируемость и эволюция:
> Делишь монолит только тогда, когда нужно
> Используешь событийную архитектуру для слабой связности
> Поддерживаешь версионирование в API и сообщениях
> Разносишь вычисления и хранение
> Договариваешься об интерфейсах, а не просто пишешь код
> Обрабатываешь частичные сбои в распределённых системах
Ты проектируешь с расчётом на изменения, а не идеальность. Принимаешь компромиссы. Понимаешь, когда стоит упростить, а когда — выложиться по полной.
А какой урок по дизайну систем ты усвоил на собственных ошибках? ❤️
👉 @BackendPortal
В Go не всегда нужен WaitGroup
Если ты просто передаёшь данные между горутинами, а не ждёшь сложной логики — буферизованный канал может решить задачу проще:
> Буферизованные каналы не блокируют отправителя, пока буфер не заполнен.
> С буфером на 1 элемент горутина может отправить данные и завершиться — без синхронизации.
> Главная горутина может получить данные, когда будет готова, без WaitGroup
👉 @BackendPortal
Backend Talks от Яндекс 360
Смотрите записи докладов с митапа от Яндекс 360 для бэкенд-разработчиков, архитекторов и DevOps-инженеров.
На пути к 9999: Игорь Обручев, руководитель группы SRE, рассказал, какими принципами команда руководствуется при создании сервисов, как без паники чинят инциденты и как в этом помогают учения.
Эволюция проектирования общих решений в Яндекс 360: Евгений Ширанков, руководитель команды платформенных сервисов, рассказал про подходы и лайфхаки, которые помогли выдержать рост команды и оставаться в контексте создания общих решений, не переизобретая велосипеды.
Ценности и культура команды: Роман Акинфеев, руководитель бэкенд-разработки, рассказал, почему культура и ценности являются важнейшими активами команды, которые сложно создать и поддерживать, но легко потерять в период взрывного роста.
Больше материалов о технологиях в Яндекс 360
@yandex360team
Многие не до конца понимают структуру Terraform-проекта или роль каждой его части.
Здесь я разложил всё по полочкам, чтобы помочь лучше разобраться
environments/
Разделяем конфигурации по окружениям:
> dev/ — ресурсы и переменные для разработки
> staging/ — для тестов
> prod/ — продакшн
В каждой папке: main.tf, variables.tf, provider.tf, outputs.tf, *.tfvars
modules/
Переиспользуемые модули, которые можно подключать в любом окружении:
> network/ — VPC, сабнеты
> compute/ — EC2, инстансы
> data/ — S3 и прочее хранилище
В каждом модуле — свои main.tf, variables.tf, outputs.tf
Примечание: модули рекомендуется хранить в отдельном центральном репозитории 🫡
👉 @BackendPortal