Comments 13
Где хардкор и конкретика?
Например, вопрос: Что использовать для случая, когда надо и избежать проблемы N+1 и сделать возможность не загружать 400 КБ вместо 20 без надобности? JSONAPI? GraphQL? И то и другое? Как это всё лучше сделать на практике?
Все по делу, но ощущается некоторая недосказанность, покрова не сорваны.
Мне нравится концепция, когда к бэку относятся как к медленной асинхронной базе данных и дают доступ выполнять произвольные запросы (GraphQL, по сути sql к обычной БД), где я сам могу выбирать какие данные, в каком объем объеме получать и как их агрировать.
Всё больше разочаровываюсь в HTTP REST API, семантики HTTP не хватает для сложных действий, языка запросов хотя бы для определения набора возвращаемых полей и минимальной фильтрации нет.
Пагинация с сортировкой и фильтрацией самая больная тема, даже без учёта возможности появления новых записей. Вроде бы идеально загрузить на клиент всё и там пускай пользователь играется, но это "всё" может быть очень огромным, но иногда пользователю реально нужно 50-я страница с его фильтрами и сортировкой, когда он ищет какие-то резко аномальные записи, но чётких условий даже сформулировать не может.
В случае с независимыми асинхронными запросами мы всегда получаем только нужный контент. Более мелкие запросы приходят в разы быстрее, интерфейс отрисовывается быстрее и по мере подгрузки каждого запроса (пользователь видит отклик быстрее).
Не всегда хорошо грузить одним запросом не связанные между собой данные.
Часто это совсем не хорошо. Собственно это частичный возврат к рендерингу полной HTML-страницы на сервере, когда в одном ответе передаются и основные данные страницы, которые собственно обычно пользователя интересует, и куча данных для навигации, информирования и прочего, что пользователю может понадобиться, когда основной контент он изучит.
Как по мне, то по умолчанию должна возвращаться одна сущность (или их коллекция если запрос типа /users, а не /users/1), максимум — агрегат. Даже для включения в ответ агрегируемых в корне сущностей при запросе корня нужны веские основания, а уж для включения несвязанных сущностей, типа данных о заказе и данных текущего пользователя, в заказе не фигурирующего — очень веские.
Удалено
С точки зрения общения с фронтендом — это должен быть единый API, желательно построенный на одних и тех же принципах, и который можно менять более-менее целостно.
Посмотрите в сторону api gateway, например apigee
Если я, как фронтенд lead, для реализации какой-то функциональности на вебе придумываю API и иду договариваться с бэкенд разработчиками о том, чтобы его реализовать — я должен учесть не только интересы веба, не только интересы бэкенда, но и интересы мобильных команд. Только в таком случае не придётся мучительно переделывать.
А ещё можно завести позицию архитектора, чтобы он решал такие вопросы.
Дизайн REST API для высокопроизводительных систем