Как разрабатывать масштабируемые фронты с низким порогом входа? Детальный гайд разделения на слои, которые дадут прикурить FSD :)

* Мы поговорим об основных подходах к аутентификации в SPA-приложениях.
* Обсудим, как грамотно построить архитектуру авторизации в сервисах, особенно если их несколько.
* Разберем протоколы oAuth и OIDC, сценарии их работы.
* Узнаем, как наилучшим и безопасным образом работать с JWT-токенами: на клиенте, на уровне BFF или вынести в отдельный слой.

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

Мы сделаем обзор от простейших и дойдем до крупных суперпроектов. Подумаем, когда и какие могут быть варианты работы с ними.

Доклад будет полезен разработчикам любого уровня для знакомства и систематизации информации по данной теме.

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

В последние пару лет появился FSD и культ микрофронтов. Однако в их применении присутствуют свои недостатки, такие как высокий порог вхождения и неприменимость к проектам на ранних этапах развития...

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

Уже два года применяю в своей команде такой подход, и пришло время поделиться опытом с обществом.

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

Современные веб-приложения разрастаются до миллионов строк кода и тысяч файлов, поэтому я предлагаю минимизировать чтение кода и сосредоточиться на отдельных признаках проблемных участков. Мы исследуем бандл, изучим внешние зависимости и связи между внутренними модулями, посмотрим на рисунок стека JS, поймём, что указывает на излишнюю императивность.

Доклад будет полезен, если:
* вы замечаете проблемы на своём проекте: пользователи жалуются на медленную загрузку приложения, внесение изменений занимает много времени или растёт частота багов;
* бизнес планирует «квантовый скачок»: готовится расширять команду и наращивать темпы, делать редизайн или добавлять объемные фичи;
* вы ведете разработку на аутсорсе или перенимаете проект у другой команды.

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

Осветим три основных кейса использования Valibot:
* валидация форм: облегчение проверки пользовательских данных;
* чистая архитектура: согласованность данных на всех уровнях приложения;
* аналитика: точность данных для обоснованных бизнес-решений.

Заключение доклада подчеркнёт, как Valibot интегрируется в рабочие процессы, повышая качество веб-разработки и способствуя созданию надёжных приложений.

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

В докладе рассмотрим предоставляемые веб-платформой средства для создания модальных и всплывающих компонентов: элемент dialog и атрибут popover. Поговорим о сходствах и отличиях подходов, какие из UI-паттернов закрывает каждый из них, когда и как их лучше использовать.

Бурное развитие ML в последнее время помогает упростить разработку за счет того, что с его помощью можно автоматизировать многие рутинные задачи.

Часто от фронт-инженеров можно услышать, что верстка им не интересна, но заниматься ею все-таки приходится. Почему бы не объединить ML и верстку для упрощения разработки?

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

Поговорим об актуальных Web API, доступных для использования в рамках PWA (Service Worker, Push и Notifications, API для работы с «железом» и т.д.) и о том, насколько они кросс-браузерны и готовы к применению в продакшне.

Обсудим, каким видится будущее PWA для комьюнити и компаний, а также рассмотрим PWA на живом примере, какие API нам пригодились для продукта, что отбросили, а что в дальнейших планах по внедрению.

В этом докладе мы сравним Bun vs Node.js в различных сценариях: в качестве среды выполнения кода, пакетного менеджера, сборщика, серверного движка и многого другого. Доклад будет содержать множество бенчмарков, таблиц и метрик. Мы разберёмся, действительно ли Bun так хорош, как утверждают официальные источники, и ответим на вопрос: стоит ли переходить на Bun уже сейчас?

Рассмотрим в докладе основные метрики для наблюдения за Node.js-приложением с SSR. Разберем два варианта их сбора и визуализации с использованием Prometheus+Grafana / OpenTelemetry+JaegerUI.

Вас ждет:
* минимальный набор метрик, который позволить понимать, что происходит с приложением;
* как подключать инструменты мониторинга и избежать утечки памяти;
* настройка алертинга для вашего приложения;
* улучшаем время ответа Next.js с использованием кеша;
* находим проблемные места приложения.

1. Деградация производительности фронтенда в последние годы.
2. Что влияет на загрузку страницы.
3. Инструменты анализа производительности сайта.
4. Методы оптимизации отображения контента и анимации.

Со времён первых терминалов 60-х годов и до наших дней CLI — основа взаимодействия с ЭВМ. Командная строка буквально связывает всё: человека и программы, программы и программы, программы и операционную систему. Давайте погрузимся в то, как эта связь устроена, поищем подводные камни. Особое внимание уделим эффективному применению CLI в JavaScript-разработке. И попробуем сделать наши скрипты чуть лучше, процесс сборки — быстрее, а деплои — надёжнее.

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

В докладе я поделюсь методами сбора покрытия кода E2E-тестами и опытом, как мы в команде платформы Ozon автоматизировали этот процесс для множества проектов в нашей компании. При этом проектам не пришлось делать какие-либо шаги для включения данного функционала благодаря возможностям расширения тестов через Playwright.

Качество поставляемого функционала должно как-то измеряться, а отклонения от нормы — фиксироваться. К сожалению, во фронтенде часто пренебрегают таким инструментом, как SLO. В докладе я поделюсь опытом нашей компании в формировании ключевых метрик, как мы их агрегируем и куда выводим, какие показатели для нас самые важные. Опишу концепции уровней SL* и приведу примеры реальных кейсов.

* Поговорим, для чего собирать метрики;
* рассмотрим, что такое SLA, SLO, SLI;
* обсудим, как считать базовые показатели и как приготовить сбор данных;
* расскажу, какие инструменты существуют и какие из них удобные;
* покажу, как это всё хранить, выводить и рисовать красивые графики;
* расскажу, куда слать алерты, когда пробило, и как выстроить культуру реакций на них.

Доклад посвящен оптимизации скорости загрузки веб-приложения в Яндекс Еде и Маркет Деливери.

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

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

Самая «эффектная» часть платформы — приложение с интерактивными картами. Мы можем посмотреть на результат моделирования — вывести орбитальные группировки, терминалы связи и шлюзовые станции, отследить их движение и траекторию в режиме реального времени.

Из доклада вы узнаете, как:
* собрать стек Web-GL-технологий для решения широкого спектра картографических задач;
* поделить планету на части вместе с H3-сотами;
* отобразить большие данные на карте, используя гибридную кластеризацию;
* сэкономить работу на стороне бэка, используя геодезические преобразования при отрисовке линий;
* реализовать real-time-анимацию объектов на примере спутниковой группировки.

Обещаю, будет как минимум красиво, как максимум — полезно!

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

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

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

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

Какое-то время назад я увидел у друга в коде следующую конструкцию:

arr2.forEach((item) => arr1.push(item));

И когда я его спросил, зачем это, то получил в ответ: так мы сливаем массивы вместо спред-оператора

[...arr1, ...arr2]

Так быстрее.

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

Что из этого вышло? Приходи послушать доклад.

Что делать, если билд прошёл успешно, а страница не грузится? Как читать ошибки Вебпака? Что такое runtime chunk?

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

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

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

В докладе расскажу, как мощны лапищи современных CSS-селекторов, как их можно необычно применять и почему старые шпаргалки про вес селекторов уже не работают.

Фронтенд-разработчики пишут на Javascript, Typescript, выбирают себе фреймворк по вкусу, библиотеки компонентов, пишут разнообразные тесты, а сеть принимают как должное. Ну что там — HTTP-запросы во вкладке Network ходят туда-сюда, тут запрос POST, тут GET, все работает — работает, не трогай!

Мы тоже так думали. Пока к нам не пришли странные пользователи, которые зачем-то открывают все в новой вкладке. «Закройте!» — говорили мы им, но с каждым новым репортом становилось все яснее, что долго так продолжаться не может.

И мы отправились в большое приключение — снимать таинственное проклятие седьмой вкладки.

Когда говорят об обеспечении доступности веб-приложений, разработчики в основном представляют добавление соответствующих ARIA-атрибутов в HTML-тегах. Однако на практике всё оказывается сложнее.

В своём докладе я расскажу о шагах, которые нужно предпринять, чтобы сделать свое приложение по-настоящему доступным, а также об особенностях мобильных скринридеров (VoiceOver и TalkBack), которые нужно учитывать при разработке доступных интерфейсов. Приведу практические примеры из опыта адаптации Яндекс Лавки к работе с мобильными скринридерами.

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

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

Я расскажу про особенности реализации AppShell. Покажу, как реализовать его в React и как это сделано у нас на серверном рендеринге в kPHP. Обсудим результаты А/В-экспериментов, интересные особенности и фишки работы с Service Worker.

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

* Реактивность в современных фронтенд-фреймворках, мемоизация.
* Сигналы: новый подход к управлению состоянием и зависимостями.
* А что с управлением серверным состоянием? Tanstack.

Доклад погружает в детали работы с видеопотоком в браузере с точки зрения спецификации Media Capture and Stream. По мере выступления разберёмся: указанная спецификация — часть WebRTC или самостоятельный стандарт. 

Детально погрузимся в getUserMedia, посмотрим, каким образом метод описывается в спецификации, а главное, проанализируем, как реализовали этот метод в исходном коде движка Chromium.

Вместе исследуем механизм связывания видеопотока с HTML-элементами через атрибут srcObject и посмотрим, каким образом интегрируется WebAssembly. Не забудем обсудить сценарии использования этого интегрирования.

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

Atomic CSS с нами уже почти 10 лет, но несмотря на это, вокруг подхода остается много споров и мифов. Пришло время разобраться, как накопленный опыт и современный CSS помогут нам верстать быстро, гибко и без потери качества кода.

Рассмотрим ключевые тезисы за Atomic CSS в сравнении с иными подходами. Развеем мифы, о которых не говорили (или сказали недостаточно) в других докладах и статьях. Разберем лучшие практики подхода: как обойти стандартные грабли и получить заявленный эффект. Покажу примеры сложных кейсов: как использовать современные возможности CSS в атомарном подходе.

Ключевая мысль доклада: Atomic CSS — это не для тех, кто плохо знает CSS. Это не очередной Bootstrap, а полноценный подход, со своими идеями, плюсами и минусами.

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

Мы разберём как, можно ускорить их разработку, какие инструменты нам помогут в этом и как быстро доставить наш результат пользователю.

Сколько типов вы пишете и используете в своих проектах? Насколько они сложны? Случалось ли вам думать, что что-то невозможно полноценно затипизировать? А задумывались ли вы о том, на что действительно способна система типов TypeScript? Спойлер: она способна на большее, чем вы думаете.

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

В докладе разберём, какие инструменты для управления зависимостями есть в экосистеме JavaScript, и поймём, какие проблемы они решают.

Полтора года назад 🚀 наша компания начала пилот по ИИ в разработке. Эксперимент показал, что использование ИИ существенно сокращает время выполнения задач и увеличивает скорость написания кода. За время проекта у нас активно формировалась книга рецептов по применению ИИ-инструментов.

Приходите на доклад! Я расскажу про практику применения ИИ для фронтенд-разработки и самые горячие кейсы применения! 🔥

Фронтенд-разработĸа все больше движется в сторону сервера.

Команда Kodix поделится опытом работы с высоĸим потреблением ресурсов сервера фронтендом при ежедневном трафиĸе оĸоло 20 тысяч посещений. Мы рассĸажем о действиях, ĸоторые предприняли для снижения нагрузĸи и повышения стабильности приложений. Разберем ошибĸи, ĸоторые больше всего вредили производительности, и объясним, ĸаĸ их устранение позволило избавиться от рестартов приложения, а таĸже повысить сĸорость отдачи страницы.

Рассмотрим новую возможность — partial-prerendering и ĸаĸ она повлияет на разработĸу. Основное внимание будет уделено выбору оптимальных стратегий рендера и их ĸомбинации.

Говоря об оптимизации сервера, мы таĸже рассĸажем о наших ошибĸах и проблемах c производительностью при использовании Next-image.

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

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

Мы обсудим:
* в каких кейсах может помочь WebAssembly;
* что нужно, чтобы скомпилировать С++-код в WASM и успешно подключить его в проекте;
* как подружить всё это с Typescript, Webpack и Web Workers;
* почему придется рефакторить код и менять типы;
* чем отличаются структуры данных в JS и WASM;
* как реализовать версионирование WASM-модуля;
* как это всё покрыть тестами.

Введение.
* Мотивация доклада: почему ИИ — это важно на фронтенде и сделает тебя лучше.

Про технологию.
* Что такое тенсорфлоу.
* Направления применения тенсорфлоу (зрение, звук, текст).
* Кейсы решений для бизнеса на фронтенде (у многих нет понимания, именно КАК применять?).

Примеры реализаций.
* Процесс работы с TensorFlow.
* Делаем «умное рисование».
* Делаем классификацию документов и меняем UI/UX с ИИ.
* Использование модели ИИ.

Заключение.
* Выводы/результаты.

После того как я впервые съездила на завод, стало понятно, почему в дизайнеров кидаются тапками.

Мы работали на ярких прикольных аймаках, проектируя интерфейсы MES-систем в соответствии с трендами. А потом своими глазами увидели, в какой ад для сотрудников производства это превратилось.

Стоит только коснуться производственной специфики, как стандартные подходы разваливаются на куски — даже если у вас уже есть огромная дизайн-система на основе популярной методологии Material Design.

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

1. Введение в пользовательский опыт (UX)
1.1 Определение UX и его значимость.
1.2 История появления и развития UX.

2. Основы когнитивного восприятия
2.1 Введение в когнитивные процессы, связанные с восприятием информации.
2.2 Как когнитивное восприятие влияет на взаимодействие пользователя с интерфейсом и с окружающими объектами.

3. Визуальные аспекты UX
3.1 Значение цветов и их влияние на восприятие.
3.2 Типографика и читаемость текста как элементы улучшения UX.

4. Профайлинг
4.1 Предпочтения, интересы, проблемы пользователей.
4.2 Психотипы пользователей.
4.3 Примеры применения знаний о психотипах для целевого дизайна.

5. Отзывчивость и доступность
5.1 Важность быстрого отклика интерфейса на действия пользователя.
5.2 Доступные интерфейсы для пользователей с различными ограничениями (как проверять, что смотреть).

6. Заключение
6.1 Подведение итогов значимости качественного UX.
6.2 Направления для дальнейших исследований в области UX.

Ничто так не бодрит томными вечерами, как обнаружение крита в продакшне. В современном мире инциденты в IT-системах могут приводить к тяжелым последствиям, включая финансовые и репутационные потери. Доклад фокусируется на методах обнаружения, реагирования и предотвращения инцидентов, чтобы обеспечить стабильность и надежность сервисов.

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

А также рассмотрим несколько примеров, в которых мы успешно (и не очень) применяли эти практики.

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

Пугающие истории о самозванцах и других нежелательных паттернах в IT.

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

Периодически слышу от коллег-разработчиков мнение, что разработчик создан только для того, чтобы писать код и пушить его в ветку. Протестировать его? Для этого же тестировщики. Отсмотреть макеты? Ну дизайнеры же есть. Проверить, собрался ли PR на стенде? А девопсы зачем?! И подобных примеров достаточно много.

Это доклад-рассуждение о том, как иногда смена статуса в Jira может упростить релизный процесс и жизнь всей команде.

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

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

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

Боишься, что твой код уронит прод и компания понесет миллионные убытки? Этого легко избежать, если использовать современные практики разработки: автоматизацию проверок (линтинг, тестинг), автоматизацию мониторинга, практики развертывания и деливери кода.

В докладе я расскажу, как все эти практики помогают перестать волноваться после нажатия на кнопки «merge» и «deploy».

Кажется, что когда весь отдел состоит из 7 человек, то проблемы с код-ревью появляются редко или не возникают вовсе. Но что, если бизнес решил за короткое время увеличить отдел в 4 раза за полгода? А если еще в это время проходит реструктуризация команд в кросс-функциональные?

Именно с такой ситуацией мы и столкнулись в отделе веб-разработки в Звуке.

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

* Сколько и каких задач взять в итерацию, чтобы успеть в срок?
* Как улучшить качество разработки?
* Где в процессе узкие места?
* Как доказать, что нужен наем и кого?
* Как защитить решения по техдолгу?
* Как наиболее выгодно выбрать задачи в итерацию?
* Как понять, что мой процесс хороший или плохой?
* Какие из текущих задач имеют риск быть невыполненными вовремя?
* Какие SLA по срокам я могу гарантировать зависимым от нас командам?
* Насколько лучше стало качество нашего решения с течением времени?
* Когда проект будет завершен?

Все ответы на эти вопросы ты можешь получить, если научишься анализу процессных метрик.
Что это за процессные метрики и как их использовать — ты узнаешь из доклада.

Через 4 года после внедрения микрофронтендов наша архитектура значительно возросла и усложнилась. Сейчас у нас:
1. оркестраторы оркестраторов. Сабдоменная система на микросервисной архитектуре с black- и white-темами;
2. 160+ микрофронтов, 68+ фронтенд-разработчиков, 40+ независимых кросс-функциональных команд;
3. платформа с 1 млн коннектов в месяц. Активно развивающийся продукт.

Когда у вас катится в среднем 26,6 фич в день, оказалось, что консистентность пользовательского опыта (UX) и соблюдение стандартов — это меньшая из проблем.

Куда важнее стабильность вашего продукта.

В докладе поговорим:
1. об инструментах мониторинга: Prometheus, Grafana, Sentry и о том, что делать, когда вы упираетесь в ограничения вендора;
2. о построении карты отказов: почему, если у вас все хорошо — это не значит, что все хорошо;
3. про реакции на Alert's: как не превратить их в спам-атаку.

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

P.S. Данный доклад является сиквелом «Микросервис головного мозга».

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

В техтоке обсудим, как мы пришли к FSD в качестве эффективного архитектурного решения для проекта в условиях монолита и нескольких продуктовых команд.

Локализация в нашем продукте прошла путь от текстов и их переводов до возможности выпускать продукт под разные региональные особенности и стандарты.

Расскажу, какие подходы и технологии мы применяем в локализации, какие при этом могут возникнуть проблемы и как мы их решили. Также расскажу про процесс whitelabeling'а и как мы реализовали его у себя в продукте. Отдельно расскажу про взаимодействие с техническими писателями и локализаторами и как построить эффективный процесс взаимодействия с ними.

Доклад посвящен созданию полноценного собственного REPL для разработки на TypeScript и его практическому применению. В ходе презентации хочу показать, как, используя Monaco Code Editor, можно добавить поддержку статических библиотек и собирать TypeScript в браузере через babel-standalone. Также я продемонстрирую, как реализовать динамическую загрузку библиотек через CDN и ESM, встроить файловую систему, улучшить сборку с помощью esbuilder и добавить загрузку ассетов.

Расскажу, что происходит с вашим CSS после того, как браузер его загрузил и распарсил, как на самом деле работают селекторы и !important, почему ваш сайт хоть как-то выглядит, даже если никакие стили не загрузились, что такое каскад и почему специфичность селекторов — это только его часть.

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