VV
На одном IP может быть множество сайтов, поэтому если браузер начнет отправлять куки по IP то это будет оченеь большой дырой в безопасности, т.к. эти куки смогут получать сторонние сайты.
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 клиенты умеют аггрегировать несколько запросов в один большой, поскольку граф один.