Проектирование бэкенда
Бэкенд не смотря на множество возможностей его реализации должен быть максимально простым, чтобы добавление новых возможностей не требовало больших усилий.
В связи с этим бэкенд должен решать ограниченное количество проблем. Часть проблем необходимо перенести на клиент, для того чтобы улучшить отзывчивость бэкенда.
Так как сейчас преимущественно используются языки со статической типизацией, желательно изначально проектировать апи используя технологии типа flatbuffers или protobuf. Они не только помогут улучшить отзывчивость бэкенда за счет меньших расходов на десериализацию данных но и помогут делать десериализацию в тех языках где рефлексия не развита, или нет единого понимания того как делать десериализацию данных.
Ответ бэкенда на разные запросы должен быть как можно более определённым(одинаковым в разных запросах).
Все ответы на запросы get должны быть вида {dataList:[], totalCount:0, error:"", descriptiveError:""}.
error и descriptiveError появляются только если код ответа не 200. Фронт должен обрабатывать особый случай когда код ответа не 200, но ответ не соответствует заданной форме. Фронт выводит пользователю текст error, сопоставив его через словарь переводчик в перевод, который будет виден пользователю. descriptiveError это ошибка для разработчиков, чтобы было легче проводить отладку, на production его можно оставить, или отсечь с помощью middleware.
Все запросы GET должны иметь в параметрах limit и offset а так же комманду count, при этом если offset не равен 0 то даже при наличии в запросе count, totalCount не должен считаться. TotalCount может быть 0 в 3 случаях: он действительно 0, limit 0 offset больше чем totalCount.
Если нужен только один элемент по id или ещё как-то то всё равно остаётся dataList, и используется limit=1. DefaultLimit не следует делать слишком маленьким, если можно себе позволить возвращать 200 строк на фронт, лучше сделать так, чем вызывать с фронта по 25 элементов кучу раз.
Желательно сделать команду select, чтобы не возвращать на фронт ненужные данные.
На бэкенде реализация эндпоинта list выводится из таблицы соответствия полей запроса и полей таблицы и их типов.
Дополнительно ограничиваются возможности select и возможности сортировки.
Так же можно сделать ограничение на количество фильтров.
Join с другими таблицами и поиск по полям связанных таблиц производится через view объявленный в базе данных.(не материализованные view можно задавать прямо в каждом запросе) факт в том что не нужно делать сложную логику join и поиска по связанной таблице через библиотеку в коде, так как это не её задача.
Last updated
Was this helpful?