Бэкенд

Я Java-разработчик: пишу на Java 5 лет. Последний месяц собираю портфолио через Spec-Driven Development — связку Spec Kit и Claude Code. Первый проект — Telegram-бот для задач. С шести вечера до двух ночи одного вторника я прошёл полный SDD-цикл от конституции до MVP с шестью командами. Восемь часов. Один вечер. Рабочий продукт. Но главное — что-то сдвинулось в моём инженерном процессе.

В статье рассмотрим кто сегодня выигрывает битву за бэкенд: сравнение синтаксиса, разбор производительности, а главное — честный прогноз на 2-3 года. Если выбираете стек для нового проекта или думаете, учить ли Kotlin вдогонку к Java, — эта статья для вас!

Статья четвертая из серии. Были исследование, личная история, продуктовый инсайт. Здесь будет продукт. Публикую манифест до того, как написана первая строчка кода — чтобы потом было честно сравнить, где я прав, а где разбился о реальность.

Привет, Хабр! Я — Руслан, а это — моя статья написанная в основном по следам моего доклада про будущее ИТ, ИТ-архитектуры и работы айтишников + часть мыслей дооформилась после участия в подкасте (все ссылки в конце).

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

Почему это важно? На конференциях мы постоянно обсуждаем ответы: как сделать микросервис, как спроектировать отказоустойчивость, какой брокер выбрать. Но мы почти не говорим о нерешённых и, тем более, о непоставленных задачах. Мы не обсуждаем будущее. Мы не обсуждаем вопросы, которые ещё не заданы. А чтобы задача поставилась, нужно как минимум о ней задуматься.

Но закончим с лирикой. Говоря о будущем ИТ, начнём, пожалуй, с ИТ-архитектуры — как дисциплины, описывающей базовые построения любого ПО.

Нередко в процессе реверс-инжиниринга мы сталкиваемся с STL-кодом, анализ которого на первый взгляд кажется затруднительным. Неопытный глаз может принять этот код за полезный и потратить время на анализ какого-нибудь конструктора.

На самом деле, здесь важно потратить время на то, чтобы распознать STL-контейнер по косвенным признакам, быстро понять, где какие данные лежат, типизировать их и идти дальше. В новой серии публикаций мы расскажем о самых распространенных контейнерах STL и начнем с std::vector.

Изменения интерфейса мобильного приложения часто упираются не в сложность реализации, а в скорость релизного цикла: даже простые правки проходят через полный конвейер — разработку, рецензирование, сборку и публикацию. При высокой частоте изменений это увеличивает time-to-market, перегружает команду и делает быстрые итерации по интерфейсу практически невозможными.

Меня зовут Михаил Рыбочкин, я бэкенд-разработчик в компании GRI. Участвую в разработке и поддержке платформы для крупного ювелирного ритейлера. Я расскажу, как реализован Server-Driven UI для интернет-торговли с более чем 1000 розничных магазинов; как устроено управление конфигурацией интерфейса через Django Admin и как это позволяет менять интерфейс без релизов приложения; какие у этого подхода есть ограничения и какой инцидент произошёл в эксплуатации. Особенность нашего подхода в том, что SDUI одновременно обслуживает и нативные мобильные приложения, и веб на Vue. Один конфиг, один API, две целевых платформы

В игре Warcraft есть такая тварь — железный голем. Здоровенная кукла, слепленная из глины и металла, которую оживляют магическим словом. Тупой, но мощный исполнитель. Сказали бить — бьёт. Сказали охранять — стоит насмерть.

Я захотел такого же, но в коде.

Телом пусть будет Telegram-бот. А мозгом — нейросеть. Не просто очередной «чат с ИИ», а настоящий кодинг-агент. Чтобы кидаешь ему проект, а он: «Тут у тебя SQL-инъекция, тут гонка данных, тут ты импорт забыл, и вообще у тебя в зависимостях дыра». Идея казалась простой: берём aiogram, прикручиваем DeepSeek, пишем промпт «ты senior-разработчик, разбери этот код» — и готово.

Первая версия была готова за вечер.

Я кинул Голему свой проект. Он задумался на пару секунд и выдал:

При проектировании многослойной архитектуры приложения одной из главных задач является формирование набора моделей данных каждого слоя и определение порядка взаимодействия моделей данных между собой. Под взаимодействием понимаются потоки данных, передаваемые из одной модели данных в другую. В общем случае взаимодействие между моделями данных двунаправленное.

Рассмотрим модель данных application model, которая потребуется в дальнейшем изложении и которая используется в паттерне CQRS.

Реализация архитектурного паттерна CQRS, используемого в приложении для функционала application logic, представляет собой набор классов наследников базовых классов QueryHandler / CommandHandler и набор классов данных, которые являются наследниками базовых классов Query / Command. Классы наследники Query / Command представляют собой модель данных application logic. Такую модель данных логично назвать application model.

Используя application model и другие известные модели данных слоёв приложения можно построить полную схему моделей данных многослойной архитектуры приложения.

Привет, Хабр! Меня зовут Кирилл Нетреба, я Backend-ML-инженер в Авито. В этой статье я разберу, как мы научили платформу отыскивать нужные пользователю объявления, даже если в них нет соответствующего запросу текста. Мы препарируем связку из Qwen2.5-VL, фреймворка vLLM и LoRA-адаптеров, а также заглянем в бэкенд-инфраструктуру, которая переваривает миллионы обновлений в сутки без деградации latency.

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

Привет, Хабр! 

А давайте посоревнуемся, кому не лень. Вот откройте любимый браузер (хоть на телефоне, хоть на компьютере). Сколько там у вас вкладок накопилось? У кого больше? У меня не так давно было под сотку. Так себе повод для гордости, конечно. Копилось как-то вообще незаметно. Сначала искал информацию по проекту - висит открытая статья, которую надо бы прочитать. И еще пара статей на ту же тему (ну вдруг в первой было недостаточно подробно). Потом десяток вкладок с роботами-пылесосами (выбирал подарок на Новый год, но, кстати, в итоге подарил совсем другое). Сколько-то вкладок с рецептами. Со всякой документацией. С… Да много с чем, не суть. И все это висело мертвым грузом. И память, разумеется, кушало. Ну а я, конечно же, верил в то, обязательно почитаю это все, но потом.

(Потом, конечно же, никто ничего не почитал.) 

И вот скажите, как вы думаете, сколько из этих ваших открытых вкладок увидят свет в ближайшие… дни? Недели? 

Бардак этот и мешает, и раздражает. Дело даже не во вкладках. На самом деле это ведь только макушка, как говорится, айсберга. А если поковыряться по всем приложениям? Сотни нечитанных сообщений в мессенджерах. Неразобранные не слишком важные задачи в таск-трекере. В личную почту вообще заходить страшно, а уж если там что-то надо найти… И, кстати, это все неплохо так подрывает мотивацию и портит рабочий настрой. Заметил, что, кажется, даже устаю от этого больше. Каждый раз преодолевать эти завалы практически подвиг.  

И решил я навести тут хоть какое-то подобие порядка. Но без фанатизма. Без глобального закрывания гештальтов, без обещаний "вот ка-а-ак с понедельника начну новую жизнь, ка-а-ак все-все переберу…". Надо просто взять и убрать самое раздражающее. Ну и начать вот прямо сейчас.  

Привет, Хабр! Меня зовут Артём Корсаков. Я пишу на Scala и руковожу группой разработчиков в компании «Криптонит», а также веду Scalabook — русскоязычную базу знаний по Scala и функциональному программированию. В этой статье расскажу про обработку ошибок в библиотеке http4s на Scala 3. Мы разберём, как настроить декодирование запросов так, чтобы клиент получал не просто код “500” или “422” с общим сообщением, а сразу видел развёрнутый список всех проблем в запросе. Например, что логин уже занят, пароль содержит недопустимые символы, а капча не введена.

Пожалуй, самая раздражающая ошибка — это получение кода “500” в ответ на запрос, который ты десять раз перепроверил, сверился с документацией и уверен на все 100%, что запрос рабочий. Даже на 110%! 

В такие моменты раздражённо думаешь: “Что же этому серверу надо? Я же чётко сформулировал запрос!

Ответить на этот вопрос порой сложно. Например, я хочу зарегистрироваться на сайте, ввожу логин/пароль и получаю сообщение "Internal Server Error". Первое желание – тут же покинуть сайт и поискать более дружелюбный.

Давайте подумаем, как можно сделать сообщение об ошибке более информативным. Для этого будем использовать Scala 3, уточняющие типы и http4s.

Представим, что мы создаём API сервиса авторизации, который (помимо прочего) должен регистрировать новых пользователей.

Для начала определим структуру данных для создания нового пользователя.

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

Этот переход - от знания к результату - и закрывает Биржа заказов Инфостарт. В экосистеме, где уже есть База знаний, публикации и сообщество специалистов по 1С, Биржа становится следующим шагом: местом, где экспертиза переходит в практическую работу.

Теперь этот механизм получил важное изменение: для авторов сообщества Инфостарт отменена комиссия на платные консультации, внедрение и доработку собственных решений...

Продолжаем серию «Kotlin для новичков». Сегодня разбираем фундамент, без которого не обходится ни одно приложение: строки и коллекции. Как правильно резать подстроки, форматировать JSON, чем List отличается от MutableList и зачем enum в Kotlin круче, чем в Java. Заглядывайте, будет полезно!

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

Давайте же разберёмся, какие костыли есть в телеграме и почему это не всегда плохо.

Гляньте-ка! Это я с сервером Minecraft, запущенным на компьютере UNIVAC 1219B:

А ниже будет эмулятор NES с первым отрендеренным кадром Pinball.

… и селфи, напечатанное на телетайпе при помощи техники многократной печати «overstrike».

Мы сделали ещё кучу безумных штук, и в том числе:

• Программы OCaml (!)

• Веб-сервер

• Шифрование Curve25519 + AES

• Интерпретатор BASIC

• ELIZA

• Игры наподобие Oregon Trail, Wordle и Battleship

… а также многое другое! И всё это на компьютере из 1960-х с частотой 250 кГц и всего с 90 КБ ОЗУ. Ради такого я и живу! Я одержим запуском кода в странных местах и преодолением технических ограничений. Этот проект стал для меня самым амбициозным на данный момент, он отнял у меня и других примерно восемь месяцев.

Исходники проекта я выложил на Github. Также можете посмотреть видео TheScienceElf об этом проекте!

Telegraph API обещает принимать content до 64 КБ, но на практике CONTENT_TOO_BIG прилетает уже на 17-20 КБ. Разбираю, как измерял реальный лимит, при чём тут UTF-8 vs UTF-16 для кириллицы, и каким обходным путём чинил молчаливую деградацию RU-канала.

Для создания графического интерфейса для приложений на FastAPI часто Python-разработчики используют что-то вроде gradio или streamlit. В этом уроке я расскажу про ещё одну альтернативу - api2app.

Отличие этой альтернативы в том, что вам не нужно изучать библиотеки и программировать, графический интерфейс для своего приложения можно создать, используя другой интуитивно понятный графический интерфейс. При этом код не будет привязан к какому-то стороннему серверу, вы сможете его скачать и использовать на своём сервере. Кроме того, при помощи api2app вы можете тестировать свои API.

Всем привет! Я Дмитрий Пономарев, разработчик ESB ИТ-интегратора «Белый код». В большинстве интеграционных проектов мы опираемся на стандартные коннекторы платформы и живём спокойно, пока реальность не подбрасывает задачу вне «типового набора». Именно так и случилось: по требованиям заказчика результаты соревнований необходимо было отправлять на сервер по протоколу SFTP, а в DATAREON «из коробки» такого коннектора просто нет. Единственным разумным вариантом стало расширить платформу — через программные модули и кастомный SFTP-коннектор.

В этой статье мы разберём, как была реализована интеграция: от постановки задачи и ограничений DATAREON до разработки собственного SFTP-модуля, его встраивания в существующие процессы и организации безопасной выгрузки файлов на Linux-сервер. По сути, это кейс о том, как использовать DATAREON не только как «конструктор из готовых блоков», но и как платформу, которую можно расширять под конкретные сценарии, когда стандартного функционала уже недостаточно.

Задача: спроектировать и настроить схему обработки, обеспечивающую корректную маршрутизацию сообщений с результатами соревнований и их последующее сохранение в заданный каталог на сервере — с соблюдением требований к формату данных, надежности доставки и контролю ошибок.

Представьте: сервис А звонит сервису Б, а тот зависает. Сервис А ждёт, занимает потоки, не освобождает ресурсы. Потом к нему приходит другой сервис — и тоже встаёт в очередь. Так один сбой разрастается по всей системе, как снежный ком. Этот эффект называется каскадным отказом.

Паттерн Circuit Breaker (предохранитель) решает эту проблему. В статье разбираем его на примере ассистента HR с зонтиком, показываем, как настроить Resilience4j, и делимся, какие ошибки стоит (а какие не стоит) учитывать в статистике.

 Описание

Паттерн Circuit Breaker (предохранитель) занимает важное место среди паттернов архитектуры приложений, особенно в микросервисных системах.

В чем его суть. Представим сервис А, который обращается к сервису Б. Сервис Б по каким-то причинам начинает плохо себя вести: долго отвечать на запросы или отвечать ошибкой — например, потерял соединение с базой данных. Тогда начинает «страдать» сервис А: он вынужден долго ждать на каждом запросе, занимая ресурсы — свободные потоки, соединения с БД, удерживая транзакции открытыми.

Проблема распространяется и умножается на всю систему. У сервиса А занимается всё больше потоков, которые ничего не делают, а просто ждут. Если будут заняты все потоки, сервис А станет полностью неработоспособен. Так проблема разрастается по цепочке — этот эффект называется каскадным отказом (cascading failure).

Чтобы решить проблему, сервис А должен иметь защитный механизм, который определяет, что сервис Б сейчас в аварийном состоянии, и временно не обращаться к нему. Этот механизм и называется Circuit Breaker (предохранитель).
 

Описание модели памяти Go начинается со слов «если вы читаете этот документ — вы излишне умный, остановитесь». Многие и правда остановились, но не автор этой статьи. 

Привет, Хабр! Я — Игорь Панасюк, и это вторая часть материала по мотивам моего выступления на GolangConf, где я рассказывал о модели памяти Go. В первой мы разобрались с  отношением happens before, формализмом, посмотрели практические примеры и многое другое. Сегодня поговорим о линеаризуемости исполнения, барьерах памяти (можно ли опустить абстракцию модели памяти), гарантии для программ с data race и использовании продвинутых техник.