В последнее время GraphQL стали предрекать смерть от http/2. Ниже мои мысли на этот счет.
Давным-давно сайты были легкими и HTTP/1 отлично гонял свои килобайты по стабильному соединению (один ресурс — одно TCP соединение). Шло время, а вместе с ним увеличивались объемы данных и росло количество запросов. Это порождало большие накладные расходы на дорогие операции открытия TCP. Помню, как мы старались склеивать картинки, лишь бы сократить их количество 🙂
Стало совсем невыносимо и появился HTTP/1.1 с persistent (keep-alive) connections и pipeline. Мы смогли отсылать несколько запросов и ответов в одно соединение и это было реально круто! Вот только один медленный запрос блокировал последующие, а бездействующее соединение все же потребляет какие-никакие ресурсы.
Что сделал GraphQL? Он позволил клиенту запросить все ресурсы за раз. Клиент сам решает, какие данные ему нужны, запрашивает их и получает одним пакетом. Вспомним времена HTTP/1, когда для заполнения одного экрана нужно было сделать несколько реквестов, в каждом ответе по 15 полей из которых нужных — по 2-3 максимум. Знатный оверхед.
В HTTP/2 (к слову — он стал бинарным, что уже сделало его более быстрым) появилась новая фича — request multiplexing. Эта фича позволяет точно так же, как в HTTP/1.1 использовать одно соединение для множества запросов, но только здесь все запросы выполняются параллельно, что исключает блокировку последующих запросов одним медленным.
Фактически в HTTP/2 заложено решение той проблемы, которую решал GraphQL с точки зрения производительности. И если брать скорость как единственный критерий, то GraphQL уже не так и нужен. Но на GraphQL можно посмотреть шире — он сдвинул парадигму в сторону клиентоцентричности.
На уровне обращения к API всегда бэк решал, что отдать фронту. «Хочешь получить имя пользователя? Вот готовый сервис. Возвращающий еще три десятка параметров (за которыми вызовы десятка микросервисов).». И вот с помощью GraphQL наконец фронт может сам решать, какие данные ему нужны и запрашивать только их (а значит будут вызваны только микросервисы, возвращающе конкретные данные). Это фундаментальный сдвиг парадигмы.
Можно долго спорить о надежности GraphQL, но то, что он привнес своего рода клиентоцентричность в процесс разработки — этому можно только порадоваться, так что если его кто и похоронит GraphQL, то не HTTP/2, а другой инструмент, развивающий эту парадигму.
Давным-давно сайты были легкими и HTTP/1 отлично гонял свои килобайты по стабильному соединению (один ресурс — одно TCP соединение). Шло время, а вместе с ним увеличивались объемы данных и росло количество запросов. Это порождало большие накладные расходы на дорогие операции открытия TCP. Помню, как мы старались склеивать картинки, лишь бы сократить их количество 🙂
Стало совсем невыносимо и появился HTTP/1.1 с persistent (keep-alive) connections и pipeline. Мы смогли отсылать несколько запросов и ответов в одно соединение и это было реально круто! Вот только один медленный запрос блокировал последующие, а бездействующее соединение все же потребляет какие-никакие ресурсы.
Что сделал GraphQL? Он позволил клиенту запросить все ресурсы за раз. Клиент сам решает, какие данные ему нужны, запрашивает их и получает одним пакетом. Вспомним времена HTTP/1, когда для заполнения одного экрана нужно было сделать несколько реквестов, в каждом ответе по 15 полей из которых нужных — по 2-3 максимум. Знатный оверхед.
В HTTP/2 (к слову — он стал бинарным, что уже сделало его более быстрым) появилась новая фича — request multiplexing. Эта фича позволяет точно так же, как в HTTP/1.1 использовать одно соединение для множества запросов, но только здесь все запросы выполняются параллельно, что исключает блокировку последующих запросов одним медленным.
Фактически в HTTP/2 заложено решение той проблемы, которую решал GraphQL с точки зрения производительности. И если брать скорость как единственный критерий, то GraphQL уже не так и нужен. Но на GraphQL можно посмотреть шире — он сдвинул парадигму в сторону клиентоцентричности.
На уровне обращения к API всегда бэк решал, что отдать фронту. «Хочешь получить имя пользователя? Вот готовый сервис. Возвращающий еще три десятка параметров (за которыми вызовы десятка микросервисов).». И вот с помощью GraphQL наконец фронт может сам решать, какие данные ему нужны и запрашивать только их (а значит будут вызваны только микросервисы, возвращающе конкретные данные). Это фундаментальный сдвиг парадигмы.
Можно долго спорить о надежности GraphQL, но то, что он привнес своего рода клиентоцентричность в процесс разработки — этому можно только порадоваться, так что если его кто и похоронит GraphQL, то не HTTP/2, а другой инструмент, развивающий эту парадигму.