Структура данных на фронт-енде и бек-енде отличаются. Кто должен переделывать?

Question

[plainview05]

При разработке модуля системы произошло несоблюдение контракта.
Фронт-енд работает с сущностями без вложенных подсущностей, но бек-енд принимает их только в таком формате. На фронте данные построены так, чтобы было удобно рендерить, а на бек-енде - для запросов в БД.

export interface someEntity {
  prop: string;
  someMoreProp: string;
  someArr: string[]
}

export interface someBackendEntity {
  prop: string;
  someBackArr: [{
    someMoreProp: string;
    someArr: []
}]
}

Должны ли данные приходить на фронт в нужном формате или их необходимо map-ать перед каждым обращением к серверу (на самом деле вложенный foreach - что выглядит как-то слишком мудрено для простого запроса)?

Comments

[Rustam Bainazarov]

Обычно в приоритете бэкенд. Но недавно была примерно аналогичная ситуация: принимать данные так, как отдает сервер, модулю React было настолько неудобно, что он рендерил (сетку с карточками и данными) с существенной задержкой. В итоге решили сделать больше запросов с бэкенда, так как лишние запросы погоды не делали, но задержки обработки на машине клиента не стало в силу упрощения массива с данными.

Этот пример проблемы я привёл с целью сказать, что, наверное, стоит отталкивать от того пути решения, что позволит обеспечить лучшее быстродействие с учётом всех потребностей.

[Immortal_pony]

Конвертер было бы написать быстрее чем этот вопрос...

[Толстый Лорри]

Вообще, API планируется не из желания кого-то меньше переделывать. Кто у вас там архитектор, product owner, тимлид или какое-то координирующее лицо?
С точки зрения здравой логики restAPI должен стремиться к снижению сетевой нагрузки, т.е. нормализации данных.
А модельки у вас в примере не выглядят эквивалентными.

[plainview05]

Immortal_pony, структура тут только для примера

[batyrmastyr]

plainview05, я что-то не так прочёл или у вас структура запроса = структуре ответа, хотя на деле они могут быть совсем непохожи?

Answer 1

[abmanimenja]

На фронте данные построены так, чтобы было удобно рендерить, а на бек-енде - для запросов в БД.

А между ними - API - в котором данные должны быть в виде удобном взаимопонимания.
Как договоритесь, как удобнее.

Что там во фронтенде, что там в бэкенде - это их внутренние дела.
Единственная точка взаимодействия - API.
Вот этот формат и оговаривается.

Comments

[abmanimenja]

OnYourLips,

Если каждый будет лезть в код чужого проекта

"Как договорились" - это не означает, что нужно лазать в чужой код.

Answer 2

[Евгений Ромашкан]

Выкиньте бэкендеров и воспользуйтесь каким-нибудь serverless решением если они просто прослойка перед базой и не умеют даже данные в формат отличный от таблички для write модели конвертить
Удобство это по сути главное требование к API, а проблемы Бэкенда должны оставаться на бэкенде.

P.s. а ещё лучше прикинуть costs/benefits вместо непродуктивных споров

Comments

[plainview05]

Не совсем понимаю - сарказм ли это?
И почему разработчик вовлечен в costs/benefits?

[Евгений Ромашкан]

plainview05, Гипербола )
Разработчик выбирая решение должен представлять и доказывать что оно окупится. Архитектор у вас, кажется, не имеется.

То что Апи должно быть удобным именно для клиента, мне кажется так же ясно, как то что важнее удобный для чтения а не для написания код.

Если ваши бэкендеры не могут сделать апишку удобнее чем запросы напрямую к базе (см. backebdless, prisma.io, firebase, postgrest, etc.) то зачем они нужны?

[Евгений Ромашкан]

plainview05, p.s. требовать вложенные сущности на вход API прям вообще жуть какая-то.

[plainview05]

Евгений Ромашкан, тем не менее - встречается довольно часто

[Евгений Ромашкан]

plainview05, Открытие в стиле "большинство программистов говнокодеры" :)

[Сергей]

Я как бек вас поддерживаю. Например моим апи пользуется 5 разных приложений, им что каждому писать парсер? Нет. Я должен сделать хорошее апи.
*Тут должен быть мем про ужасную сторону бека и милую фронта