Как стать автором
Обновить

Комментарии 9

Есть еще вот такая библиотека https://github.com/graph-gophers/graphql-go
И она, имхо, поинтереснее.
Есть поддержка схем, описанных на родном dsl. Есть сторонний генератор всего бойлерплейта.

Мне кажется, что обработка GraphQL запросов дорого может обойтись
Бенчмарки есть какие-нибудь? сколько можно потерять в производительности, по сравнению с обычными http запросами?
по сравнению с обычными http запросами

GraphQL — это тоже обычный http-запрос.

Извините, не правильно выразился, по сравнению с REST-запросами имелось ввиду
Сделал простой бенчмарк для сравнения graphql-go с REST на net/http

Результаты:
goos: windows
goarch: amd64
pkg: ser/graphql_bench
BenchmarkGraphQLHTTP-4 2000 891501 ns/op
BenchmarkHTTP-4 2000 593000 ns/op


Разница ~0.3 миллисекунды

Только graphql-go, по сравнению с маршалингом в json и одним REST сервисом, увеличивает время обработки в 1.5 раза на очень простом тесте, а при более сложных, скорее всего, будет еще медленнее. Но это будет только несколько миллисекунд. В зависимости от задачи, это вполне допустимый минус.

Из-за принципа использования graphql и различных паттернов, как dataloader с кэшем, можно получить даже прирост производительности, по сравнению с использованием множества REST сервисов, для получения одинаковых данных на клиенте.
Спасибо за бенчмарк!

по сравнению с использованием множества REST сервисов, для получения одинаковых данных на клиенте.


Если уже начать использовать протокол HTTP/2, то можно посылать несколько запросов во время одного соединения. Как по мне, вот это преимущество у graphql (получение связанных данных в одном запросе) какое-то сомнительное становится при использовании HTTP/2.
Согласен. С точки зрения рантайм производительности, graphql теряет здесь преимущество.
В зависимости от API, в graphql еще можно выиграть на размере ответов, но это уже в редких случаях даст что-то существенное.

По моему, GraphQL стоит больше рассматривать за его другие преимущества: гибкость запросов и статическая схема — этими преимуществами он ближе к SQL, чем к REST, и как он вписывается в общий процесс развития компании, особенно, если она большая.

Все-таки его создала компания у которой начались проблемы больше организационные в разработке и поддержке API и фронт-систем, нежели связанные с производительностью софта (хотя и здесь они были, т.к. еще не было HTTP/2).

К тому же есть отличные инструменты, которые сильно помогают на этапах анализа и разработки, как playground и voyager

По сравнению с запросом в БД время обработки GraphQL стремится к нулю.

Тут перевод статьи GraphQL vs. REST, возможно что-то Вам будет интересно. Бенчмарки не нашёл.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории