arturvolokhin
@arturvolokhin
Frontend-разработчик

Делегирование обязанностей между Frontend и Backend разработчиками, на чьей стороне должна выполняться та или иная работа (Подробнее в деталях)?

Например, у нас есть канбан, который имеет определенное количество колонок, допустим 5.
У каждой колонки есть свое название.
На канбане будут находиться таски (за пример можно взять джиру).
Каждый таск должен лежать в определенной колонке.

Есть два варианта распределения работы между фронтенд и бэкэнд:

1) Отдается массив данных с уже распределенными по колонкам тасками, фронтенд-разработчику остается только отрендерить данные. В таком случае придется структурировать данные полученные с БД на стороне сервера.

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

То же касается и функциональности сортировки, фильтрации, поиска и так далее.
Есть ли смысл делать это все на сервере?
Поясняю: на клиенте все это можно сделать в разы быстрее, приложение будет отвечать моментально, чем если мы будет делать запрос на сервер при каждом действии.

Как правильно разделить обязанности между фронтенд и бэкэнд разработчиками в 2022 году?
Хотелось бы получить аргументацию и развернутые ответы, а не просто "это должен делать сервер, или это должен делать фронтенд". Можно привести в пример другие кейсы, необязательно опираться на описанные мной выше.
Заранее спасибо!
  • Вопрос задан
  • 162 просмотра
Пригласить эксперта
Ответы на вопрос 1
VoidVolker
@VoidVolker
Разработчик ПО и IT-инженер
Как правильно разделить обязанности между фронтенд и бэкэнд разработчиками в 2022 году?

Сделать декомпозицию всего проекта в несколько интераций, далее правильно его структурировать и спроектировать архитектуру, которая будет решать поставленные перед проектом задачи и соответствовать его требованиям. Архитектуру разрабатывает/разрабатывают архитектор и/или тим- и тех- лиды. И вот когда на руках будет исчерпывающее ТЗ со всеми деталями - на этом этапе тимлид и прожект-менеджер создают задачи для фронт-энда и для бэкэнда. При этом, выставляются взаимосвязи и блокировки задач: например, "список пользователей в админке" для фронта, зависит от "базовое API для управления пользователями" для бэка, если задача для фронта требует каких-то дополнительных точек API - просто создается подзадача для бэка типа "поиск пользователя по всем полям учетной записи". И такие подзадачи не просто могут быть, они однозначно будут и надо просто учитывать этот момент.

То же касается и функциональности сортировки, фильтрации, поиска и так далее.
Есть ли смысл делать это все на сервере?

Конкретная реализация зависит от задач. Если данных мало и их можно быстро передать - то да, удобнее на клиенте обрабатывать, если данных много - то на сервере, при этом сделать кэш и группировку для горячих данных для ускорения. Приведу реальный пример из практики (тыц): была задача сбора и отображения статистики использования десятки терминальных серверов на нескольких сотен пользователей. От каждого активного пользователя по несколько сотен точек в день, десяток машин. И для каждой машины и для каждого пользователя надо было сделать график и чтобы все это можно было быстро и удобно просмотреть. Десятки и сотни мегабайт данных - сотни тысяч точек за несколько месяцев. На одной странице. Все данные хранятся в БД, горячие данные - в кэше памяти, аппроксимация точек для разных периодов времени за 3 месяца, быстрые фильтры для получения данных для построения графика с нужной точностью за выбранный период. Т.е., фронт говорит "дай данные за такой-то период для такого-то сервера/пользователя" - бэк быстро фильтрует нужное среди нескольких сотен мегабайт данных и отдает от нескольких десятков до нескольких сотен КБ.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы