Нормально ли что бекенд отдает сырые данные на фронт?
Я не очень силён в базах данных и посему назрел вопрос, так как раньше подобные ситуации не встречались, либо мне так кажется, либо проекты такие были.
Суть в том, что на проекте бекенд присылает "сырые данные", то есть, чтоб построить список(категорию)товаров, мне необходимо слепить как минимум три таблицы с разных запросов:
запрашиваю, например: localization, menu, и еще какие-то обьекты с набором разных полей.
Далее по айдишникам начинаю конструировать Lego-Menu находя связи между разными обьектами.
И это только категории товаров. В проекте, насколько мне кажется, нету не единого обьекта данных, чтоб просто запросить и вывести на экран. Каждый полученный обьект необходимо сравнивать к каким-то другим обьектом, сравнивая их айдишники-связи, чтоб получить целую картину.
Как вы счиатете, нормальна ли ситуация? Правильно ли работает бекенд?
Если же это я расслабился и привык к красивым данны с бекенда, работая на разных проектах, то из этого следует другой вопрос, зачем мне бекенд на этом проекте? Я тоже так могу, может не SQL, но как минимум в mongo.
Буду очень признателен за ваши ответы, ваше мнение очень важно для меня :)
Если ты не можешь на это повлиять, то смирись. На самом деле, то что ты описал, и как ты это описал, должно делаться еще на уровне самого SQL запроса, и возвращаться должны готовые для употребления данные. Вот эти все сравнения идентификаторов должна делать субд на основе пришедшего к ней SQL запроса. А тебе должно быть достаточно сделать запрос вроде getMenu(params), где params это и локализация, и прочие нужные поля.
А так выходит что бэкенд это файл базы данных, а роль субд выполняет фронтенд.
Работать с сырыми данными на клиенте накладно всем.
Накладно клиенту, потому что приходится работать с сопоставлением справочников, что должна делать СУБД "одной левой пяткой" при правильно составленном запросе с помощью индексов и кэша.
Накладно инфраструктуре связи - гоняем много данных по каналам и не один раз.
Накладно бекэнду - постоянно создавать соединение с клиентом и СУБД, разрывать соединение.
Накладно СУБД - делать серию мелких запросов с толстой процедурой подготовки соединения, проверки прав пользователя на объекты, выполнения запросов, вместо того, чтобы выполнить запрос в один/два присеста.
Что делать?
Организовывать на стороне сервера грамотный API - каждая функция API при запросе к серверу должна давать порцию данных, необходимую для отображения конкретного отчета. В ответе не должно быть переизбытка данных. Если это список товаров, то отображать данные не всего списка, а от такой-то позиции до такой-то. Если у товаров есть какие-то "тяжелые" подробности, скажем, посмотреть большую фотку его, то подгружаем ее только по запросу пользователя, скажем, при наведении мыши - то есть вызываем другую функцию API. То есть функции API должны соответствовать механике работы с отчетом, а не предоставлять несвязные клочки данных.
Средний
Простой
Простой
Простой
