Граф Кю-эль

tonsky — 16.11.2016

Интересная штука. В Фейсбуке придумали Virtual DOM. Идея оказалась такой хорошей, что им выдали кредит доверия на его реализацию (React), и там ещё осталось. И теперь, что бы не сказал Фейсбук, все слушают, раскрыв рот. Так Фейсбук закрепился законодателем мод по фронтенд-фреймворкам.

А у Фейсбука идет обычный рабочий процесс. Идеи рождаются, о них рассказывают на конференциях, они умирают. Естественный отбор, как везде. Скажем, было несколько подходов к Flux, все загнулись, но выстрелил Elm, и тогда Фейсбук просто нанял автора порта Elm архитектуры на JavaScript.

И вот они додумались до GraphQL. На всякий случай повторю: успех GraphQL не связан с качеством самой идеи GraphQL. Его успех — следствие кредита доверия, завоеванного еще статьей про Virtual DOM. GraphQL — плохая спецификация. Но люди слушают, потому что считается, что в Фейсбуке понимают про фронтенд. Они не понимают. Они перебирают варианты. GraphQL — просто еще одна флуктуация.

То есть, проблема, которую предполагает решать GraphQL, она правильная и актуальная. REST — штука идиотская, если делать приложения, а не один раз дернуть (вот я, например, еще в 2014-м на него катил бочку). Проблема в том, как GraphQL к ней подошел.

Смотрите. Задача — запросить данные с сервера. Т.е. нужен язык запросов. Что сделали в Фейсбуке? Они посмотрели на самый простой случай. Типа, запросить одну entity. И придумали самый идиотский, непонятно как сериализуемый, птичий язык. Да, это не JSON. Да, основной мотивацией при изобретении формата запроса было, чтобы запрос выглядел похоже на ответ. Не знакомость, не компактность, не простота генерации/парсинга, не простота реализации, не компонуемость (она будет нужна), не теоретическая база какая-нибудь вроде реляционной алгебры. Короче, придумали. А потом посмотрели, какие случаи такой формат не покрывает. Случаи взяли из своей практики. Какие запросы Фейсбук делает, такие случаи и залатали. Как залатали: налепили хаков поверх того, что придумали выше. Ну, типа, давайте мутации описывать тем же языком, что и запросы. Для пагинации давайте придумаем специальный синтаксис. И т.д.

Ладно. Получилось как получилось. Глобальных претензий две.

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

И вторая проблема. Ладно бы, если бы этот слой как-то магически решал проблемы за вас. Так нет, писать GraphQL сервер придется вам самим. Причем, сама спека очень нетривиальная, там всякие интерфейсы, инклюды, кондишны прям в самом языке запросов, серьезно. То есть люди сели, решили: а давайте сделаем вот чтобы реально была simplest possible thing. Ну и наворотили. Возможно, думали слишком много про удобства, а вышло в целом неудобно, потому что слишком много удобств.

Ну ладно язык, тут расчет, что язык за вас распарсит библиотека, если она есть под что вы там пишите. Эликсир? Джава? Ну, молитесь, чтобы работало. Надеюсь, не выйдет как с HTTP, в котором столько разных возможностей, что добрую половину из них веб-серверы in the wild просто не реализуют. Главное, что всё равно потом вам нужно писать эту логику, которая мапит схему вашей БД на иерархический JSON. И она не получается красивая, она получается рекурсивная. Т.е. это всё та же проблема N+1 запросов, только между сервером и БД. А если сам запрос рекурсивный (можно же рекурсивный запрос на GraphQL написать?), можно и N² сделать.

И всем этим люди занимаются только потому, что Фейсбук так сказал. ¯\_(ツ)_/¯

В общем, мораль такая, что проблема важная, данные с сервера надо таскать, и не REST-ом же это делать. Но и не GraphQL. Мне кажется, что что-то более конкретное, более приземленное, что не боится знать, как выглядят данные, в каком виде их будут хранить и использовать и клиент, и сервер, не абстрагируется от этого, по крайней мере, в каждом конкретной комбинации будет проще.

Оставить комментарий

Популярные посты:

titus

Алюминиевый профиль V-паз: универсальный строитель современных конструкций

kwakin_misha

Про обсуждение с жителями Африки празднования Нового года в России

eirc63

остался один

ka_mysh

Хорошо бывает полюбоваться на хамелеона или агаму, когда

v_strannik

И это тоже "Made in Germany"

magman67

Коллекционер пластинок

peremogi

Дурнеску оголосил!

georgith55

угличский шлюз

panchul

Он хотел на старости сидеть в баре и смеяться, вспоминая как он убивал, но все

• Архив