С вас вопросы, с нас ответы. Часть 18
Отвечаем на популярные вопросы про Frontend System Design
Консультирует:
Василий Ванчук
Что такое Frontend System Design и чем он отличается от Backend System Design?
Глобально FESD не отличается от Backend System Design — нам все так же нужно спроектировать решение, которое закроет запрос пользователя. При этом нам все так же нужно собрать сам запрос (редкий заказчик сразу вываливает все необходимые детали), подумать про разработку, расширение и поддержку решения, выбрать технический стек и сделать прочие выборы относительно системы. Но разница появляется в деталях, т.к. сама область проектирования отличается, хоть и пересекается с Backend по части интеграции. Однако вызовы и проблемы, которые встают при разработке FE, другие.
Так же, как в BE, нам нужно думать про границы модулей, производительность, кэширование, наблюдаемость, взаимодействие разных команд. Но в случае с FE у нас не одна большая система — скорее, набор большого числа небольших.
При этом у нас еще имеются различные окружения (браузеры, типы сетей и устройства), а не известный заранее Docker-контейнер в стерильной среде дата-центра. То есть главное отличие — не масштаб (хотя да, по объему работающего кода сервер и клиент различаются, но далеко не всегда это соотношение очевидно), а совершенно другой набор ограничений. У нас больше вариативность в плане сред исполнения, меньше вариантов в плане выбора технологий, а состояние приложения на фронтенде по сложности обгоняет многие серверные решения.
Еще нам нужно думать о том, что среда исполнения одна, и ее ресурсы ограничены. Например, решив вопрос взаимодействия большого числа команд через разработку на микрофонах, мы столкнемся с проблемой дублирующегося состояния и повторяющихся запросов. Причем это тяжелые запросы в сеть, а не только межмодульное взаимодействие. А последствия неправильных решений ощутит на себе не только инфраструктура продукта, но и все пользователи — ответственность ни разу не ниже, а то и выше.
Проектирование фронтенда связано с разработкой бэкенда в нескольких точках. Для начала это распределение ответственности, кто чем занимается. В идеале — без дублирования логики. Тут важно думать о надежности операций, сохранности данных и пользовательском опыте. И крайне важно делать это вместе с командой, которая проектирует серверную часть, чтобы все участники проектирования всей системы понимали общую картину, а не тянули одеяло на себя. Где разместить логику валидации? Кто должен отметить отправку невалидных данных? И т.п.
Наконец, чьими ресурсами мы собираемся платить за обработку данных — это можно перекладывать на клиента, но может ухудшить пользовательский опыт.
Вторая важная точка — проектирование API-интеграции, через который данные будут передаваться между сервером и клиентом. Чтобы число запросов оставалось не большим, чтобы избежать отправки лишней информации и т.п. И здесь также важно понимать стандартные серверные решения, поскольку зачастую именно для них есть стандартные инструменты интеграции, и вести продуктивный и аргументированный диалог с командой backend.
Из-за того, что во FE данные (то, что мы показываем пользователю) находятся дальше от своего источника (БД или другие сервисы), приходится учитывать большее число слоев. Каждый из которых может взмахнуть крылом, как бабочка, и вызвать цунами. К примеру, число уровней кэширования, которые возможны в FE, больше того, что встречается в традиционных серверных приложениях.
Однако зачастую эта повышенная сложность незаметна, просто потому, что многие разработчики или принимают привычные решения (т.е. не принимают решения под конкретную задачу), или просто не имеют достаточного кругозора и квалификации для обоснованного выбора. А другие специальности вокруг не имеют хороших примеров перед глазами и застряли в восприятии фронтенда как «формочки и кнопки». И решением тут может быть только поднятие среднего уровня разработчиков, которые своим примером — работой, проектами и опытом — смогут показать, что у каждой задачи может быть больше одного решения. Что «сократить запросы на сервер» — это не про «подключить React Query», а про учет последовательности запросов, депликацию, согласованность API и отражение данных, HTTP-кэширование и смену направления передачи данных. Да, часть этого действительно делает RQ, но это еще нужно осознавать. Как понимать, что под капотом автомобиля, и быть в состоянии сделать больше, чем пнуть колесо и протереть фары.
Так же, как в BE, нам нужно думать про границы модулей, производительность, кэширование, наблюдаемость, взаимодействие разных команд. Но в случае с FE у нас не одна большая система — скорее, набор большого числа небольших.
При этом у нас еще имеются различные окружения (браузеры, типы сетей и устройства), а не известный заранее Docker-контейнер в стерильной среде дата-центра. То есть главное отличие — не масштаб (хотя да, по объему работающего кода сервер и клиент различаются, но далеко не всегда это соотношение очевидно), а совершенно другой набор ограничений. У нас больше вариативность в плане сред исполнения, меньше вариантов в плане выбора технологий, а состояние приложения на фронтенде по сложности обгоняет многие серверные решения.
Еще нам нужно думать о том, что среда исполнения одна, и ее ресурсы ограничены. Например, решив вопрос взаимодействия большого числа команд через разработку на микрофонах, мы столкнемся с проблемой дублирующегося состояния и повторяющихся запросов. Причем это тяжелые запросы в сеть, а не только межмодульное взаимодействие. А последствия неправильных решений ощутит на себе не только инфраструктура продукта, но и все пользователи — ответственность ни разу не ниже, а то и выше.
Проектирование фронтенда связано с разработкой бэкенда в нескольких точках. Для начала это распределение ответственности, кто чем занимается. В идеале — без дублирования логики. Тут важно думать о надежности операций, сохранности данных и пользовательском опыте. И крайне важно делать это вместе с командой, которая проектирует серверную часть, чтобы все участники проектирования всей системы понимали общую картину, а не тянули одеяло на себя. Где разместить логику валидации? Кто должен отметить отправку невалидных данных? И т.п.
Наконец, чьими ресурсами мы собираемся платить за обработку данных — это можно перекладывать на клиента, но может ухудшить пользовательский опыт.
Вторая важная точка — проектирование API-интеграции, через который данные будут передаваться между сервером и клиентом. Чтобы число запросов оставалось не большим, чтобы избежать отправки лишней информации и т.п. И здесь также важно понимать стандартные серверные решения, поскольку зачастую именно для них есть стандартные инструменты интеграции, и вести продуктивный и аргументированный диалог с командой backend.
Из-за того, что во FE данные (то, что мы показываем пользователю) находятся дальше от своего источника (БД или другие сервисы), приходится учитывать большее число слоев. Каждый из которых может взмахнуть крылом, как бабочка, и вызвать цунами. К примеру, число уровней кэширования, которые возможны в FE, больше того, что встречается в традиционных серверных приложениях.
Однако зачастую эта повышенная сложность незаметна, просто потому, что многие разработчики или принимают привычные решения (т.е. не принимают решения под конкретную задачу), или просто не имеют достаточного кругозора и квалификации для обоснованного выбора. А другие специальности вокруг не имеют хороших примеров перед глазами и застряли в восприятии фронтенда как «формочки и кнопки». И решением тут может быть только поднятие среднего уровня разработчиков, которые своим примером — работой, проектами и опытом — смогут показать, что у каждой задачи может быть больше одного решения. Что «сократить запросы на сервер» — это не про «подключить React Query», а про учет последовательности запросов, депликацию, согласованность API и отражение данных, HTTP-кэширование и смену направления передачи данных. Да, часть этого действительно делает RQ, но это еще нужно осознавать. Как понимать, что под капотом автомобиля, и быть в состоянии сделать больше, чем пнуть колесо и протереть фары.
задай вопрос, а мы ответим
