Много маленьких запросов к REST API или один большой?

Question

[cyberz]

Есть веб-приложение, разработанное с использованием компонентов (VUE..JS, React, Angular). Некоторые компоненты этого приложения получают данные по REST API при инициализации или при взаимодействии с пользователем. Такой подход вызывает много вызовов API на страницу (иногда более 10).
Есть ли проблемы с таким подходом ?
Некоторые предлагают объединить вызовы API в более крупные сервисы на стороне клиента, которые действуют как одиночные. Таким образом, 10 вызовов API могут быть уменьшены до 1, даже если страница может использовать только часть этих данных.
Какой вариант более правильный, множество мелких запросов или же 1 большой ?

Comments

[alex-1917]

конечно один.
что для вас большой запрос? вы что, админ МВИДЕО?
скорее всего речь о 50мс для сервера...

Answer 1

[Антон Спирин]

Если у вас сейчас что-то вроде этого:

GET '/posts/slug/'

{
  post: { /* ... */ }
}

GET '/posts/slug/comments/'

{
  comments: { /* ... */ }
}

GET '/posts/slug/comments/users/'

{
  users: { /* ... */ }
}

GET '/posts/slug/author/'

{
  author: { /* ... */ }
}

GET '/posts/slug/meta/'

{
  meta: { /* ... */ }
}

то логично все связанные данные объединить в один запрос:

GET '/posts/slug/'

{
  post: { /* ... */ },
  linked: {
    users: { /* ... */ },
    comments: { /* ... */ },
    meta: { /* ... */ },
  },
}

Answer 2

[Михаил]

graphql это решает как бы,
Rest не единственная возможность общения клиент-сервер

Comments

[hOtRush]

Решает, и создает разных других проблем :)

[alex-1917]

если все эти 10 запросов уже оптимизированы и скорее всего там поступает только нужная информация, то графкюэль ничего не решает, а только создает ореол моднявости, не говоря уже о накладных расходах.

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

Answer 3

[asdz]

Я думаю, что оба варианта имеют право на существование, они не плохие и не хорошие. Все зависит от задачи, от требований, от того как дальше вы будете развивать систему и т.д. Просто вы должны знать, что чем больше запросов - больше сетевых издержек, но зато вы сможете запрашивать с клиента только то, что вам нужно, вы можете переиспользовать существующее API в разных фичах приложения. В случае комплексной модели - фронт работает быстрее, нет необходимости "склеивать данные", как при этом выполняется более сложный запрос на бэке - это надо смотреть. То есть у каждого варианта есть свои плюсы и минусы, и какой способ выбрать зависит от конкретной вашей задачи.

Answer 4

[AlexisKmetik]

Смотреть нужно, вам на фронте какая разница? Хоть 100 запросов, если сервер не против. Помните, что делать можете, как решите. Если есть проблемы с производительностью? Нет? Забейте.
Есть важные моменты, типа кэша, количества обращений и прочего. Как производите выборку на стороне сервера, делали оптимизацию запросов? Какой кэш используете? И тд

Answer 5

[Игорь]

Представьте, что один клиент, условно выполняет 100 запросов на сервер

100 * 1000 клиентов.

Comments

[vladislav3101]

а разница? Объединишь ты эти 100 запросов в 1, что то изменится? Сервер будет просто на 1 запрос выполнять общую нагрузку из 100.