Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Есть еще вот такая библиотека https://github.com/graph-gophers/graphql-go
И она, имхо, поинтереснее.
Есть поддержка схем, описанных на родном dsl. Есть сторонний генератор всего бойлерплейта.
Мне кажется, что обработка GraphQL запросов дорого может обойтись
Бенчмарки есть какие-нибудь? сколько можно потерять в производительности, по сравнению с обычными http запросами?
Бенчмарки есть какие-нибудь? сколько можно потерять в производительности, по сравнению с обычными http запросами?
по сравнению с обычными http запросами
GraphQL — это тоже обычный http-запрос.
Извините, не правильно выразился, по сравнению с REST-запросами имелось ввиду
Сделал простой бенчмарк для сравнения graphql-go с REST на net/http
Результаты:
Разница ~0.3 миллисекунды
Только graphql-go, по сравнению с маршалингом в json и одним REST сервисом, увеличивает время обработки в 1.5 раза на очень простом тесте, а при более сложных, скорее всего, будет еще медленнее. Но это будет только несколько миллисекунд. В зависимости от задачи, это вполне допустимый минус.
Из-за принципа использования graphql и различных паттернов, как dataloader с кэшем, можно получить даже прирост производительности, по сравнению с использованием множества REST сервисов, для получения одинаковых данных на клиенте.
Результаты:
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 сервисов, для получения одинаковых данных на клиенте.
Спасибо за бенчмарк!
Если уже начать использовать протокол HTTP/2, то можно посылать несколько запросов во время одного соединения. Как по мне, вот это преимущество у graphql (получение связанных данных в одном запросе) какое-то сомнительное становится при использовании HTTP/2.
по сравнению с использованием множества REST сервисов, для получения одинаковых данных на клиенте.
Если уже начать использовать протокол HTTP/2, то можно посылать несколько запросов во время одного соединения. Как по мне, вот это преимущество у graphql (получение связанных данных в одном запросе) какое-то сомнительное становится при использовании HTTP/2.
Согласен. С точки зрения рантайм производительности, graphql теряет здесь преимущество.
В зависимости от API, в graphql еще можно выиграть на размере ответов, но это уже в редких случаях даст что-то существенное.
По моему, GraphQL стоит больше рассматривать за его другие преимущества: гибкость запросов и статическая схема — этими преимуществами он ближе к SQL, чем к REST, и как он вписывается в общий процесс развития компании, особенно, если она большая.
Все-таки его создала компания у которой начались проблемы больше организационные в разработке и поддержке API и фронт-систем, нежели связанные с производительностью софта (хотя и здесь они были, т.к. еще не было HTTP/2).
К тому же есть отличные инструменты, которые сильно помогают на этапах анализа и разработки, как playground и voyager
В зависимости от API, в graphql еще можно выиграть на размере ответов, но это уже в редких случаях даст что-то существенное.
По моему, GraphQL стоит больше рассматривать за его другие преимущества: гибкость запросов и статическая схема — этими преимуществами он ближе к SQL, чем к REST, и как он вписывается в общий процесс развития компании, особенно, если она большая.
Все-таки его создала компания у которой начались проблемы больше организационные в разработке и поддержке API и фронт-систем, нежели связанные с производительностью софта (хотя и здесь они были, т.к. еще не было HTTP/2).
К тому же есть отличные инструменты, которые сильно помогают на этапах анализа и разработки, как playground и voyager
По сравнению с запросом в БД время обработки GraphQL стремится к нулю.
Тут перевод статьи GraphQL vs. REST, возможно что-то Вам будет интересно. Бенчмарки не нашёл.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
GraphQL API (CRUD) на Go