Мысли о разделении ответственностей фронта и бека
Кто должен принимать решения в тех или иных ситуациях – фронт или бек, как должно быть организовано их взаимодействие?
- Нейминг определяет бекендер. Конечно, речь не идёт о локальных для фронта именах (т.е. таких, которые есть только на фронте и которых нет на беке, например, функции для обращения к API – ну вот хочется фронтендерам, чтобы их имена имели префикс
fetch – да пожалуйста!), но вот, например, имена бизнес-сущностей должны браться с бека; ибо именно там, в BLL, живёт предметная область.
- Структуру ответа (response) с сервера на клиент определяет фронтендер, именно он говорит, какие данные и в каком виде должны приходить; плевать, что отдел и сотрудник в БД – две таблицы, на бекенде – вложенные объекты, если фронту нужен плоский объект, значит, должен быть плоский объект.
- Структуру запроса (request) с клиента на сервер типа “дай” определяет бекендер. Если фронтендер говорит: дай мне список сотрудников конкретного отдела, то бекендер отвечает – давай айдишник отдела. И не важно, что фронту проще отдавать, например, название отдела – это никого не волнует, только бекендер знает, какие данные ему нужны для того, чтобы сформировать ответ.
- Структура запроса (reques) типа “возьми, на” (например, данные формы) – ну, тут надо договариваться, т.к. обе стороны заинтересованы: бекендер знает, что ему нужно, а фронтендер знает, что он может.
Дедушка Волшебник, 2023-03-01