Веб-разработка *

Если вы пишете бэкенд на Python или только собираетесь вкатиться в эту тему, вы точно слышали про FastAPI. Он обещает скорость NodeJS, автодокументацию из коробки и строгую типизацию. Звучит круто, но для новичка любая новая технология выглядит пугающе.

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

Обзор на браузерные API, которые стали Widely available в феврале 2026. Раз в месяц я буду вам напоминать, что вы уже можете использовать в проде. В этом месяце всё довольно скучно и одиноко.

Каждый месяц выходят новые CSS-свойства, HTML-атрибуты, JavaScript-методы и WebAPI, но применять в проде мы их конечно же не будем. 2.5 года назад также каждый месяц выходили новые фичи в браузере, а вот их уже пора начинать применять.

На дворе конец 2023. Я только что уволился из Яндекса и скучаю по ячану, чуть меньше скучаю по этушке, вообще не скучаю по таскам, дедлайнам, ревью. Чтобы заполнить возникший информационный вакуум, пробую переключиться на реддит, hacker news, пикабу, вышивание крестиком, сканворды, пилатес — не то. Тогда мне в голову приходит гениальная идея: а почему бы не сделать свою имиджборду с авторизацией по корпоративной почте крупных российских компаний? Ячан для всех!

Первая мысль — взять готовый движок и допилить под себя, в открытом доступе уже есть: lynx, vichan, wakaba, kareha, fchannel. Потыкался — ничего не понятно. Как ленивый человек решаю, что надо писать своё.
На тот момент я:

Не понимал разницу между HTTP и HTTPS

Не знал, что такое handler, router, middleware

Считал, что DNS — это какой-то раздел электронной музыки

Думал, что куки и кэш — это одно и то же

Не без труда отличал header от body

Не мог пропатчить kde2 под freebsd

Короче говоря, я был именно тем человеком, который должен был писать проект с нуля. Цель понятна, надо выбрать инструменты. Я неплохо знал питон и c++... поэтому языком разработки выбрал Голанг. Мой опыт с Голангом на тот момент ограничивался прослушанным фоном на х2 ШАДовским курсом. Прослушал я его в автопоездке Москва — Челябинск. Не написал на Го ни одной строчки кода, но суммарно прослушал — именно «прослушал», ибо рассмотреть мелкий шрифт на экране телефона, будучи за рулём, решительно невозможно — около 30 часов материала. Написать свой движок имиджборды - хороший повод попрактиковаться.

Если вы пишете сложный SELECT, в котором одно и тоже вычисляется несколько раз, например, для массовой обработки данных пачками, то наверняка вам хотелось завести локальную переменную

вот пример:

SELECT
price * quantity AS total_price,
(price * quantity) * 0.15 AS tax,
((price * quantity) + ((price * quantity) * 0.15)) AS grand_total
...

Здесь price * quantity вычисляется несколько раз, и tax вычисляется дважды. Но это выглядит еще ок, в реальности это зачастую всякие монструозные свитч-кейсы с NULLIF, COALESCE и прочими ребятами.

Но не суть, вам хочется один раз вычислить значение, без дублирования кода.

Long story short, это делается так:

Меня часто просили как-то удобно организовать поиск по всем материалам, которые были в моём геймдев-дайджесте, и... За один вечер я сделал небольшой сайт для этого, не написав ни строчки кода. В статье расскажу про сам процесс.

Всем привет, уважаемые читатели! В архитектуре проектов мы можем наблюдать применение паттерна BFF (Backend for frontend). При этом BFF может быть в архитектуре, где есть взаимодействие с клиентскими приложениями: веб, мобильное, смарт-устройства и т.д, но может быть всего-навсего один служебный фронтенд, доступ к которому возможен во внутрикорпоративном сегменте, например, банковская система, hr, логистика. Кажется, что при наличии одного фронтенда введение BFF избыточно.

И возникает закономерный вопрос: если клиент всего один, да еще и работает внутри защищенного контура, зачем нам плодить отдельные компоненты системы? Не превращается ли BFF в лишний прокси-сервис, который только пробрасывает запрос и добавляет сетевую задержку?

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

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

Если вас заинтересовал заголовок, то вы, скорее всего, уже знакомы с разработкой Telegram или Discord-ботов. И что также вероятно: для получения обновлений вы используете обычный polling. Сегодня же я вам предлагаю ознакомиться с другим способом получения обновлений - через webhook.

Продолжаю серию статей про вайб кодинг для чайников (это я). Сегодня про главную боль: почему всё, что генерирует ИИ в плане веб-дизайна, выглядит одинаково пластиково, и что с этим делать на практике.

Хотелось бы свалить на конкретную модель и сказать - "надо просто выбрать вот эту и всё будет тип топ". Но на самом деле - это проблема подхода: по умолчанию ИИ пишет и оптимизирует код подходом "работает и не ломается", а не "выглядит как лучшие примеры с Awwwards". У него нет контекста вашего бренда, нет визуального фидбека на результат, нет источника вдохновения. Он берёт самый частотный паттерн из обучающей выборки, и вы получаете среднее арифметическое всех шаблонов интернета (стоит признать - иногда и так нормально). Давайте это починим в этой статье.

Как правило, работа с веб-сокетами сводится к паре строк: connect() и send(). Удобные абстракции библиотек превратили этот протокол в магическую трубу, по которой летают данные в обе стороны. Но магия заканчивается ровно в тот момент, когда соединение молча отваливается с кодом 1006, балансировщик рвет коннект, а в логах появляются странные ошибки фрагментации. В этой статье мы спустимся с небес высокоуровневых фреймворков на уровень байтов и битовых масок.

Мы пройдем полный путь WebSocket-соединения, опираясь на RFC 6455: от генерации ключа на стороне клиента до обмена закрывающими фреймами. Попутно разберем весь необходимый понятийный аппарат: что такое фреймы, какими они бывают, зачем их маскируют и фрагментируют и т.д. Цель не в том, чтобы научиться пользоваться конкретной библиотекой, а в том, чтобы понять, как протокол работает изнутри независимо от языка и реализации. Для иллюстраций по тексту статьи даны сниппеты на Python.

Netflix, Shopify, Vercel — что общего у этих компаний, кроме успеха? Они по-особому строят мост между фронтендом и сервером. Не просто «отдай JSON», а целые архитектурные подходы: BFF под каждое устройство, частичный prerendering, Server Components. В новой статье мы разберем, как современный фронтенд общается с бэкендом и почему старый добрый REST уже не всегда спасает. Спойлер: даже если вы бэкендер, после прочтения начнёте иначе проектировать API.

Всем привет! Кажется, настала пора поделиться изменениями в Азбуке, которые произошли с 2022 года, когда я выпускал прошлую статью. Наш текущий стэк: Vue 3, Nuxt 4, TS.

В процессе создания новых сервисов, столкнулись с проблемами роста, дублирования кода и модульностью в Nuxt - расскажу, как справились с этим.

На Хабре десятки статей про вайбкодинг. Есть переводы сравнений v0 vs Bolt vs Lovable, есть манифесты «вы всё проспали», есть личные истории «навайбкодил сайт за три дня». Но ни одной статьи, где кто-то берёт одно конкретное ТЗ и прогоняет его через все доступные AI-генераторы — западные и российские — с честными скриншотами результатов.

Я это сделал. Одна бургерная, восемь платформ, ноль иллюзий.

В 2013 году на Randomwire была опубликована интересная статья. В ней автор указал на интересные особенности японского дизайна. Японцы известны своим минимализмом, но в случае сайтов у них, почему-то, всё наоборот. Страницы пестрят всевозможными цветами, что уже нарушает 3 принципа дизайна, плюс на них используются мелкие иконки и мно-о-о-о-го текста.  Да вы и сами видите пример этого буйства фантазии на скриншоте выше, сделанном в ноябре 2022 года.

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

И вот мне стало интересно, как обстоят дела сейчас, и можно ли как-то количественно оценить дизайн японских сайтов? Собственно, этим я и занялся.

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

Это, в свою очередь, подтолкнуло меня покодить на Си (чего я не делал сто лет) всякое, ориентируясь на WASM.

А это уже натолкнуло меня на мысль: а не подойдёт ли связка JS+WebAssembly как инструмент для создания минифицированных проектов в духе демосцены?

Короче, хоть я к демосцене никаким боком, но что мешает мне написать игрульку в сайз-факторе 4K? Исключительно for fun.

Сегодня утром я прошёл лайв-кодинг в одну англо-продуктовую компанию. Написал ноль строчек кода руками. Задеплоил результат на свою VPS прямо во время звонка. Интервьюер сказал: "It's so wonderful just how much everything has changed." А неделю назад другая компания не зачла мне тестовое, потому что я забыл про запрет AI.

20+ собесов за последние месяцы. Фронтенд, бэкенд, фулстек, AI-инженер. Python, TypeScript. Разные рынки, разные компании, совершенно разное отношение к одному и тому же инструменту. Я не теоретик, который рассуждает о будущем. Я прямо сейчас хожу на эти собесы и вижу, как рынок разламывается пополам.

Это разбор реального опыта внедрения доступности в крупном веб-продукте с десятками микросервисов и сложным фронтендом. Без лозунгов, зато с кодом, ошибками, переработками дизайн-системы и неожиданными проблемами в CI. Поговорим про ARIA, серверный рендеринг, мобильные скринридеры, автоматическое тестирование и про то, почему доступность — это не про alt у картинок, а про архитектуру.

Когда я впервые услышал фразу сделаем доступность, я честно подумал: окей, добавим alt, поправим контраст, закроем задачу. Спойлер — это был самый наивный момент за весь проект.

Мы работали над крупной B2B-платформой. Много форм, таблиц, кастомных контролов, графиков, drag-and-drop, модалки внутри модалок. И в какой-то момент заказчик сказал: продукт должен соответствовать WCAG 2.1 AA. Причём не формально, а чтобы им реально могли пользоваться люди с ограничениями по зрению и моторике.

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

Давайте по порядку.

Доступность часто воспринимают как техническую тему. ARIA, WCAG, скринридеры — будто это зона разработчиков. Но правда в том, что большая часть проблем появляется ещё в макетах. И если дизайнер не заложил структуру, смысл и сценарий — разработчик это уже не исправит без редизайна.

В части 1 мы выяснили, что объекты в Heap не освобождаются сами по себе этим занимается Garbage Collector. Но как именно GC решает, что можно удалить? Если подумать, задача не такая очевидная: объект не нужен - понятие логическое, а GC работает с физическим графом ссылок.

Ответ в том, что GC не пытается угадать намерения программы. Он задаёт более простой вопрос: можно ли добраться до этого объекта из работающего кода? Если нельзя объект недостижим, и никакой код уже не сможет его использовать. Значит, память можно вернуть.

Алгоритм, реализующий эту логику, называется Mark and Sweep.

В последние несколько дней я начал замечать странную вещь: находясь под средствами обхода блокировок, у меня перестают работать отечественные ресурсы — вроде Яндекс Маркета, Яндекс Телемоста и других сервисов.
Но стоит отключить обход — всё снова функционирует нормально.

Получается парадоксальная ситуация: людям, которые просто хотят посмотреть котиков на YouTube или спросить ChatGPT о какой-нибудь ерунде, снова начинают вставлять палки в колёса.

Из этого напрашивается тревожный вывод: суверенный интернет уже не где-то в теории — он буквально дышит нам в спину. Интернет, в который всё сложнее попасть извне. Интернет, который постепенно замыкается сам на себе.

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

Всем привет! Меня зовут Саша, и последние 12 лет моя жизнь — это дизайн. Сегодня я руковожу дизайн-командой в KISLOROD, а в прошлом — помогал крупным брендам и миллионным сервисам обрести их уникальный голос и форму.

Сегодня расскажу о реализации удобного функционала фильтрации и сортировки товаров.

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