Время отклика GraphQL GET медленное по сравнению с RESTful

Question

Я хотел проверить время отклика GraphQL endpoint и RESTful endpoint, поскольку я никогда раньше не использовал GraphQL, и я собираюсь использовать его в своем следующем проекте Laravel.

Поэтому я использую PHP-пакет Lighthouse для обслуживания конечной точки GraphQL из моего приложения Laravel, а также я создал конечную точку RESTful.

Обе конечные точки (GraphQL и RESTful) предназначены для получения всех пользователей (250 пользователей) из моей локальной базы данных.

Итак, основываясь на тесте, я заметил, что когда я тестировал обе конечные точки на Postman, ответ конечной точки RESTful быстрее, чем конечная точка GraphQL.

Могу ли я узнать, почему ответ конечной точки GraphQL занимает больше времени, чем RESTful, в то время как обе конечные точки получают одинаковые данные?

Результат конечной точки GraphQL для запроса GET (время ответа: 88 мс)

Результат конечной точки GraphQL для запроса POST (время ответа: 88 мс)

RESTful результат конечной точки (время отклика: 44 мс)

Answer 1

Нет такого понятия, как бесплатный обед.

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

Если бы вы добавили дополнительные функции к вашей конечной точке REST (запрос и проверка ответа, поддержка частичных ответов, возможностьпсевдонимы отдельных полей ответов и т. д.), которые отражают GraphQL, вы увидите разрыв в производительности между этими двумя сокращениями.Но даже в этом случае это все равно что-то вроде сравнения яблок и апельсинов, поскольку служба GraphQL будет выполнять определенные действия просто потому, что именно это и говорит spec .

Answer 2

TLDR: ваш пример REST прост и менее сложен

В Lighthouse создается AST для анализа запроса graphql и вашей схемы. Затем он передает все директивы и так далее, чтобы выяснить, что вы пытаетесь сделать. Он также должен проверить ваш запрос, чтобы увидеть, действительно ли вы можете запустить его в схеме.

В зависимости от того, как вы определили его в своем приложении, оно проходит через множество шагов. Однако это может быть уменьшено несколькими различными способами, синтаксический анализ вашей схемы graphql может быть кэширован , вы можете кэшировать результат , использовать отложенные поля (prob. не ускорит этот пример). Подробнее об этом вы можете прочитать в разделе документации .

Вы не указываете, как настроен ваш REST, если вы используете какой-то стандарт REST, где он также должен анализировать данные. Если вы добавите больше функций, будет больше кода для выполнения, следовательно, увеличится скорость загрузки.

Answer 3

Начиная с Lighthouse v4, мы добились значительного увеличения производительности за счет отложенной загрузки минимально необходимых полей и типов из схемы. Это приводит к увеличению производительности в 3–10 раз, в зависимости от размера вашей схемы.

Вы, вероятно, все еще не сможете превзойти одну конечную точку REST для такого простого запроса. Маяк начнет сиять на более сильно вложенных запросах, которые объединяются между несколькими отношениями.