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