Как эффективно создавать HTML-шаблоны, когда все данные поступают из внутреннего API?

Question

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

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

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

Теперь мы задаемся вопросом, как мы должны спрашивать наш API для данных. Для нас существует 2 совершенно разных варианта:

1. Один запрос, один маршрут, для одной страницы. Таким образом, мы получили бы огромный объект, который будет содержать все необходимое для создания соответствующей страницы.
2. Один запрос для одного небольшого фрагмента данных. Например, на странице листинга мы сделали бы один запрос, чтобы получить данные о текущем зарегистрированном пользователе и отобразить его имя вместе с его аватаром, затем еще один запрос на получение каждой статьи, другой запрос на получение данных о текущей категории страниц. .

Некоторые, как первый вариант, мне совсем не нравится. Я чувствую, что у нас будет много избыточности. Я также не уверен, что один огромный запрос - это намного быстрее, чем X крошечных запросов. Мне также не нравится привязывать данные к определенной странице, так как я чувствую, что API должен быть (несколько) независимым от нашего веб-сайта.

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

Что вы, ребята, думаете?

Answer 1

Первый подход будет хорошим, если получить все данные достаточно быстро. Чем меньше запросов - тем быстрее приложение. Избыточность. Я думаю, вы имеете в виду избыточность кода, поскольку отправка одного и того же количества данных в один запрос будет определенно быстрее, чем в 10 небольших непараллельных (сетевые издержки). Если вы отправляете несколько параллельных запросов из пользовательского интерфейса, вы можете получить выигрыш в производительности. И вы должны учитывать, что у браузеров есть limitations for parallel requests.

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

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

Вы также можете взглянуть на this pattern, который позволит вам найти логику бизнеса/домена внутри одной службы и логику «дружественный интерфейс» к другой службе (служба орфографии).