JavaScript *

Это девятая статья про инженерные решения в ONEMIX. Тема узкая, push-уведомления. Но я её давно хотел разобрать, потому что туториалов в интернете много, а production-граблей в них почти нет.

Если коротко, туториал по push выглядит так. Регистрируешь токен через Notifications.getExpoPushTokenAsync(). Отправляешь на бэкенд. Когда приходит пуш — addNotificationResponseReceivedListener ловит тап, навигируешь в нужный экран. Всё.

В реальном мессенджере таких туториалов недостаточно. Появляется десяток узких проблем. Пуш приходит когда юзер уже в этом чате. Пуш приходит когда приложение убито системой. Navigation после открытия из пуша добавляет дублирующийся экран в стек. На iOS звонки идут через отдельный канал VoIP который требует совершенно другой инфраструктуры. Эти грабли я и разберу.

Всем привет! Хочу поделиться, возможно, не новым, но, на мой взгляд, довольно изощренным видом фишинга. Кто-то уже наверняка сталкивался с таким методом, а для кого-то он окажется в новинку.

Real-time без авторизации опасен. Если пользователь может подписаться на чужой канал, он может получать чужие уведомления, статусы заказов, сообщения, события админки или финансовые обновления. В обычном HTTP API такая ошибка выглядела бы как доступ к чужому endpoint. В WebSocket-архитектуре ошибка такая же, просто выглядит менее очевидно.

Разбираем в Centrifugo: публичные и приватные подписки, connection token, subscription token, права доступа и безопасное подключение

Когда локальный стейт в React-модуле начинает расти - разработчик инстинктивно тянется к useReducer+Context. Это работает, пока не перестаёт: ререндеры везде, провайдеры в елочку, логика размазана. В статье разбираю как этот путь выглядит в реальном продакшне на примере редактора субтитров, и почему паттерн Scoped Store на базе Context+Zustand+useRef решает эту проблему чище и проще.

Современная корпоративная разработка — это всегда про компромиссы. Нужно быстро прототипировать, но при этом не потерять в качестве кода. Хочется держать в голове всю архитектуру — и фронтенд, и бэкенд, и контейнеризацию, и тесты. А по факту время уходит на переключение между десятками вкладок, согласование REST-контрактов и разбор ошибок по логам.

В этой статье мы расскажем, как в проекте нейропрототипа модуля Планирования (PlanningProto) мы использовали Cursor — редактор с ИИ, который встроен прямо в репозиторий.

В первой части мы разобрались, что Real-time на Laravel-сайте нужен там, где интерфейс должен получать изменения без перезагрузки страницы: новые уведомления, смену статуса заказа, сообщения в чате, обновления виджетов, события в административной панели. Для таких задач классическая модель HTTP-запроса уже недостаточна, а polling создаёт лишнюю нагрузку на backend. Один из практичных вариантов решения — использовать Centrifugo как отдельный WebSocket-сервер рядом с Laravel-приложением.

В этой статье разберём архитектуру Laravel + Centrifugo: за что отвечает Laravel, какую роль выполняет Centrifugo, как frontend подключается к real-time каналу и как выглядит типовой сценарий публикации события, например при изменении статуса заказа.

Исторически создание карусели в веб-разработке означало использование какой-либо JS-библиотеки. Slick, Swiper, Flickity, Embla Carousel и другие заполняли пробел платформы. Каждая из них увеличивала размер сборки, имела свои особенности обеспечения доступности и накладные расходы на обработку событий. Полный минифицированный пакет Swiper v11 весит приблизительно 140 КБ; даже модульные импорты составляют 40-60 КБ для ядра и навигации. Умножьте это на бесчисленные маркетинговые страницы, галереи товаров в электронной коммерции и макеты с большим количеством медиаконтента, которые зависят от каруселей, и расходы сильно возрастут: долгое время до интерактивности, блокировка основного потока во время инициализации и большой размер передаваемых данных на каждой странице, где используется слайдер.

Разбираем, зачем нужен real-time на сайте, почему polling создаёт лишнюю нагрузку и как Centrifugo помогает добавить WebSocket в Laravel-приложение без разрушения backend-архитектуры.

Привет, меня зовут Александр Богданов, я ведущий фронтенд-разработчик стрима «Программы лояльности» в MWS. Наша команда отвечает за развитие и поддержку продуктов МТС Premium и МТС Cashback. 

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

В посте расскажу, как мы это сделали с помощью npm-пакетов и какие результаты получили.

Это седьмая статья про инженерные решения в ONEMIX. Тема узкая, но болезненная для каждого кто делал мобильное приложение с отправкой сообщений или файлов.

Сценарий с которого всё началось у меня. Пользователь в чате выбирает большое видео, нажимает отправить. Видео начинает грузиться. Пользователь нетерпеливый, прокручивает вверх посмотреть переписку, потом переходит в другой чат, потом возвращается. Что должен он увидеть?

В Telegram он увидит свой видео‑бабл с прогрессбаром, как и оставил. В большинстве самописных мессенджеров он увидит пустой чат без своего сообщения, потому что upload жил в state экрана, а экран размонтировался. XHR продолжал работать в фоне, файл загрузился на сервер, но результат пришёл в null, потому что setter уже не существует. Сообщение фактически отправлено, но пользователь об этом не знает.

Это боль которая лечится не «правильным useState», а отдельным архитектурным слоем. Этот слой называется outbox. В этой статье разберу свою реализацию из ONEMIX, это 820 строк TypeScript которые делают то что в Telegram кажется естественным.

 Архитектура «оркестратор + сабагенты» на одном экране: ведущий агент держит план и раздаёт подзадачи изолированным сабагентам.

Один AI-агент в чате – это удобно, пока задача помещается в контекст. Как только она начинает разъезжаться по 30 файлам, четырём ролям и циклу «исследуй – реализуй – отревьюй – поправь», единый чат превращается в свалку: модель путает, какой шаг где, тащит решения из первой задачи в третью и стабильно проседает по качеству начиная с заполнения окна примерно наполовину. Схема «оркестратор + сабагенты» – это инженерный ответ на проблему: один ведущий агент держит план и раздаёт подзадачи изолированным сабагентам с пустым контекстом.

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

Это четвёртая статья из серии про инженерные решения в ONEMIX — моём мессенджере на React Native. В предыдущих разбирал трёхуровневый кэш сообщений, Double Ratchet E2E и WebRTC звонки с trickle ICE. Последняя про звонки набрала больше всего просмотров, и в комментариях несколько раз спрашивали про десктоп: «а как у тебя там устроено?».

Сегодня — отдельная статья про desktop‑версию. Сразу скажу: я не использовал React Native for Desktop, не Tauri, не React, не TypeScript. Чистый Electron + vanilla HTML/JS. Это нестандартное решение, и я объясню почему пошёл этим путём, что от этого выиграл, и где это бьёт по голове.

Привет, Хаброжители! Как практикующий разработчик ПО вы уже умеете качественно выполнять задачи — на фронтенде или бэкенде. Пора перейти на следующую ступеньку карьерной лестницы и развить навыки, которыми обладают эксперты и senior-разработчики.

Рассказываю, почему в B2B-проектах опасно полагаться на community-ноды и как я перевел интеграцию с мессенджером MAX на стандартный HTTP Request. Фиксим «ловушку» Chat ID (404), требование плоской структуры JSON (400) и ошибки протокола ENOTFOUND. Внутри — готовый конфиг для безопасной отправки сообщений через Header Auth и способ упаковки спецсимволов через Expression-объекты без поломки парсинга.

Я соло-делаю Speakwithai — AI-репетитор английского для русскоязычной аудитории. Месяц назад выкатил публично, за этот месяц получил 50 регистраций, 3 платящих и набор технических граблей, которые честнее разобрать, пока они свежие, а не через год по сглаженной памяти.

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

Это третья статья из серии про инженерные решения в ONEMIX — моём мессенджере на React Native. В первой я разбирал трёхуровневый кэш сообщений, во второй — реализацию Double Ratchet E2E. Сегодня — про звонки.

Звонки в мессенджере — это та функция, которая работает либо отлично, либо никак. Пользователь привык что WhatsApp/Telegram звонят мгновенно, показывают входящие на заблокированном экране, переживают переключения Wi-Fi/LTE, и работают из фона. Если твоя реализация делает хоть что-то из этого хуже — пользователь это сразу заметит и переключится на "нормальный" мессенджер.

Я потратил несколько месяцев на то чтобы довести звонки в ONEMIX до production-уровня. В процессе пришлось изучить WebRTC изнутри, разобраться с iOS CallKit и VoIP push notifications, и собрать десяток граблей которые в туториалах не упоминают. В этой статье — как это устроено, какие решения оказались критичными, и что бы я сделал по-другому.

Сразу оговорка. Я не использую готовые SDK типа Agora, Twilio, 100ms. У них отличное качество и поддержка, но они не дают полного контроля над процессом — а для мессенджера контроль критичен. Когда звонок не проходит, пользователь винит приложение, а не "SDK от третьей стороны". Плюс готовые SDK стоят денег, которые на раннем этапе продукта лучше направить в другие места.

В прошлой статье про трёхуровневый кэш сообщений я уже упоминал, что делаю мессенджер ONEMIX на React Native. Базовое E2E у меня было простое: ECDH P-256 для обмена ключами при первом контакте, AES‑GCM для шифрования каждого сообщения общим секретом. Это работает, но имеет одну проблему: общий секрет один на всю переписку. Если у одной из сторон скомпрометируют приватный ключ — все сообщения за всё время превращаются в открытый текст.

Это называется отсутствием Perfect Forward Secrecy (PFS). И это значит, что человек, к которому в руки попадёт твой телефон через год, может прочитать переписку из прошлого года. WhatsApp, Signal, и серьёзные части Telegram давно используют другую схему — Double Ratchet — которая ключи переизбретает заново на каждом сообщении. Так делают потому, что любой ключ компрометируется в один момент времени, и компрометация не должна давать доступа ни к прошлому, ни к будущему.

Я реализовал Double Ratchet с нуля для ONEMIX. В этой статье разберу:

Собеседования по TypeScript всё чаще проверяют не только знание синтаксиса, но и умение видеть «узкие места» в уже работающем коде. Задача кандидата - не просто сказать «тут ошибка», а предложить более безопасное, читаемое и поддерживаемое решение.

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

Помните тот момент, ĸогда вы отĸрываете свой собственный проеĸт, ĸоторый не трогали пару месяцев, и не понимаете, где что лежит? А если ĸ проеĸту подĸлючается новый разработчиĸ, первые две недели он просто бродит по папĸам в попытĸах понять логиĸу автора.

React дал нам невероятную свободу: фунĸциональные ĸомпоненты с хуĸами, состояние в Redux, Context, MobX, Zustand или useState, запросы где угодно и ĸаĸ угодно. Но эта свобода имеет обратную сторону — отсутствие стандартов.

Каждый разработчиĸ пишет «по‑своему». В одном проеĸте мирно сосуществуют устаревшие подходы с современными, запросы ĸ API разбросаны по всему ĸоду, а состояние приложения напоминает спагетти. Проходит полгода, и даже автор ĸода с трудом объясняет, почему все устроено именно таĸ.

Знакомо?

Существует архитеĸтура, ĸоторая решает эти проблемы. Она называется Bulletproof React. Это не очередной шаблон или стартовый boilerplate. Это философия и набор лучших праĸтиĸ для создания production‑ready приложений, ĸоторые не превращаются в хаос через месяц разработĸи. В этой статье я постараюсь разобрать эту архитеĸтуру детально: от струĸтуры директорий до тестирования и безопасности. Данный материал будет полезен и новичĸам, ĸоторые тольĸо начинают задумываться об архитеĸтуре, и опытным разработчиĸам, ищущим проверенные решения.

Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат.

Если вы хоть раз делали список сообщений на React Native, вы знаете эту боль: открыл чат — пустой экран на 200–800 мс, потом подгрузка, потом скачок при докрутке наверх. В Telegram такого не бывает: открыл — мгновенно увидел последние сообщения, прокрутил наверх — никаких пустот, история идёт сплошной лентой.

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