System Design: frontend

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

Первое, что приходит в голову — drag-n-drop: таскаешь блоки по канвасу, а на выходе он генерит React-компоненты. За полчаса набросал, вроде работает. И вот тут ты уже проиграл: ты сделал «редактор, который выплёвывает вёрстку», а задача была про систему, которой пользуются не только разработчики и которая живёт дольше одного релиза фронта. Дальше весь пост — как из первого прийти во второе.

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

Идём за этим вопросом
Скорее всего дадут такой ответ(тут зависит от интервьюера конечно же, в какую степь он захочет уйти): собирать интерфейс часто будет не разработчик, а контент-менеджер. А результат должен приезжать не только на веб, но и на iOS с Android - и без релиза приложения. И это меняет всё: JS в стор мгновенно не докатишь, нативную вёрстку из React не соберёшь. Значит выход конструктора в принципе не может быть кодом. Отсюда рождается ядро всей задачи: конструктор не генерит вёрстку, он собирает её описание — сериализуемое дерево, JSON: какие виджеты, в каком порядке, с какими параметрами. А рисует это дерево отдельный рендер-движок, свой на каждой платформе. Вёрстка тут — данные, а не код. Называется это Backend-Driven UI; в Авито ровно ради этого построили движок Beduin. Придёшь к этому сам — ответ уже не джуна, а если и назвать в качестве примера известную реализацию твоей идеи, то это +реп сразу.

Раз вёрстка — это данные
Дальше всё вытекает из этой мысли. Виджет — независимый переиспользуемый блок с контрактом: строго типизированные параметры, у каждого свой тип и обязательность. И первый жирный плюсик: форму настройки не пишем руками под каждый блок, а генерим из контракта. Разработчик зарегистрировал виджет в каталоге, описал параметры — конструктор сам построил форму. Иначе на сотне виджетов утонешь в формочках. У Авито это так и устроено в их Bricks — привести известную реализацию к своим мыслям всегда +реп.

Где сыпятся
Все грабли — из той же мысли «это данные». Забыл про неё — провалился. Наверное, самое тонкое место - превью. Блок, который контент-менеджер видит в редакторе, должен рендериться по тем же правилам, что и прод у юзера — из того же описания и тем же рендером, а не отдельным мокапом на React. Иначе разойдутся: собрал красиво, опубликовал, а у юзера поехало. Никакого eval — это прямое следствие того, что описание есть данные. JSON пришёл из админки, где сидит не разработчик: валидируем по схеме (те ли типы, на месте ли обязательные поля, разрешённый ли виджет), но не исполняем. Начнёшь evalить — получишь дыру в безопасности и падение на первом же кривом вводе.

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

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

В следующем посте — задача от Яндекса, которую дают бэкендерам!
Кстати, если хотите оставаться в тренде айти рынка и его требований, то советую наши курсы старт, на который мы продлили финальные скидки на 24 часа.
➡️ Записаться

Подписаться: @codeof_art
Вступить в чатик: @code_of_art