если смотреть на тот же инстаграмм там со всех их величием среднее время ответа сервера просто жесть

по итогу пилят рейт лимитеры и особо любопытные клиенты падают в виду непрозрачности апи

Я не маппил это дело на орм, у меня graphql это API Gateway для микросервисов с GRPC ручками.
Но проблем никаких с орм не будет. Ты можешь для любого поля в схеме сделать отдельную функцию резолвер, которая хоть орм, хоть что угодно дернет в любом виде. А dataloaders нужны для оптимизации n+1 и группировки одинаковых конкуретных запросов, кеша.

Отсутствие кеширования? В gql? А что подразумевается под нормальным?)

http кеширование

Нормального кеширования это вы про HTTP Cache?

1. HTTP Cache слишком тупой.
HTTP Cache очень часто ломается об банальные query arguments.

GET products?fields=name,customerId
GET products?fields=customerId,name

по мнению cache’а два выше указанных URL’а разрешают разные ресурсы. Кэш не сработал.
Ладно, не лучший пример. Давайте добавим поле:

GET products?fields=customerId,name,id

Опять, кэш не сработал.

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

1.1 GraphQL нормализирует граф и идентифицирует cache’абильные объекты

Если мы запросили

{
 product(id: “foo”) {
   id
   name
   description
   color
   attributes
 }
}

…то cache GQL клиента нормализует и сохранит по ID объекта данные поля в cache.
При последующем запросе:

{
 product(id: “foo”) {
   name
   description
   color
   attributes
   somethingNew # new field!
 }
}

клиент заметит, что продукт “foo" уже имеется в cache’е, ещё валиден и следственно, автоматически сократит запрос до:

{
 product(id: “foo”) {
   somethingNew # new field!
 }
}

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

2. HTTP Cache невозможно контролировать.
Если я как разработчик хочу контролировать кэш в коде клиента, то увы, с HTTP это не моё собачье дело.

GraphQL хранит весь cache - client-side. Т.е. у нас полный контроль над тем сколько, что, в каком виде и как долго хранится.

3. HTTP не умеет аггрегировать запросы.

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

популярные странички в соцсетях отдаются через http cache

первое вполне решается сортировкой

если клиент - мобильное приложение, например, то запросы будут генирироваться по одному правилу (в рамках одной версии точно), соответственно первый кейс не актуален

1.1  — проблема уровня приложения, а не протокола

про агрегацию не понял зачем нужно

HTTP cache это про server-side caching.
GraphQL cache это про client-side cache.

Разные инструменты для разных задач.

ничто например не мешает поставить HTTP Cache перед GraphQL API сервером

я так и написал, что пример не лучший, но я его специально привёл, для того чтобы уточнить почему именно HTTP cache считаю туповатым. Он не понимаем содержание идентификатора ресурса, он видит URL как ключ.

в редких случаях может быть полезным когда хочется аггрегировать все запросы малых компонентов в один большой запрос. С HTTP/RPC это в принципе невозможно поскольку это не граф.

Использование HTTP Cache это уже крайность, не?) Ну и Роман прав, то что никто не мешает отправлять запросы в gql с GET параметром и использовать HTTP Cache)

Для мобильных приложений с allowed queries (или как они там называются), прям как обычный рест будет 😃

всё верно. HTTP cache никто не отменял. Комбинировать можно, но это скорее когда речь идёт об очень больших нагрузках.

это называется persisted queries.

Т.е. на сервере храним whitelist разрешённых query а клиент присылает нам ID этого query, мы его выполняем и отсылаем ответ.
Один из вариантов борьбы с DoS кстати.

чем это отличается от RPC/REST? Тем что я в runtime могу занести любой query в whitelist не трогая код сервера.

@Romshark А у тебя монолит с gql? Или это api gateway?

api gateway