Что такое GraphQL

В последние несколько лет популярность и известность GraphQL растет среди разработчиков, и многие компании начинают применять эту технологию для создания своих API. GraphQL — это язык запросов, разработанный Facebook в 2012 году и опубликованный в 2015 году. Он получил широкую популярность и был принят многими крупными компаниями, такими как Spotify, Facebook, GitHub, NYTimes, Netflix, Walmart и т. д.

В этой статье я собираюсь рассказать что это такое GraphQL и что делают его таким интуитивно понятным и простым в использовании.

Начнем с рассмотрения типичных проблем с REST API и того, как GraphQL решает их.

REST API

Давным-давно, когда мы перешли с архитектуры API с SOAP на REST, мы думали, что этот шаг даст разработчикам больше гибкости в их работе. Нельзя отрицать, что это работало в течение длительного времени и было хорошим шагом в то время. Но по мере того как приложения и Интернет становились все более изощренными со временем у REST выявилось много проблем. Давайте рассмотрим их:

Много конечных точек (URLs)

Каждый ресурс в REST представлен конечной точкой то есть URL. В реальных приложениях у нас как правило появляется много конечных точек для большого количества ресурсов. Если вы хотите сделать запрос GET, вам понадобится конечная точка, специфичная для этого запроса, с конкретными параметрами. Если вы хотите сделать запрос POST, вам понадобится другая конечная точка только для этого запроса.

GET     /posts
GET     /comments
POST    /post
POST    /user

Вы спросите, а в чем проблема? Давайте представим, что мы создаем огромное приложение типа социальная сеть, такое как Facebook. В итоге у нас будет много конечных точек (urls), что означает, что на разработку и поддержку всех этих API будет потрачено много времени разработчиков.

Избыточное извлечение или неполное извлечение информации

Реальная проблема, которая раздражает многих разработчиков, — это чрезмерная выборка или наоборот неполная выборка информации через REST API. Это потому, что REST API всегда возвращают заранее созданную фиксированную структуру. Мы не можем получить именно те данные, которые нам нужны в текущий момент, если мы не создадим для этого конкретную конечную точку то есть url.

Таким образом, если нам нужен только маленький кусочек данных, мы должны работать со всем объектом. Например, если нам нужно только получить firstName, lastName и age пользователя в REST API, мы не сможем получить именно эти данные без извлечения всего объекта.

нужно:

user {
    firstName,
    lastName,
    age
}
но вместо этого получаем целый объект:
user {
    firstName: 'firstName',
    lastName: 'lastName',
    age: 21,
    posts: [],
    comments: [],
    createAt: '01/12/2018'
}

Также существует проблема с неполной загрузкой информации. Если мы хотим получить данные из двух разных ресурсов, нам нужно сделать разные вызовы из двух разных конечных точек. В огромном приложении это не так хорошо масштабируется, так как будут случаи, когда нам нужно получить только определенный фрагмент данных, а не весь объект. Теперь представьте, что мы создаем приложение, которое будет иметь 100 конечных точек. Представьте объем работы и код, который нам нужно написать. Все это может стать сложнее со временем.

Версионирование

Еще одним из самых болезненных моментов в REST является версионирование. С REST API очень часто можно увидеть множество API с v1 или v2, но в GraphQL это не нужно, поскольку вы можете развивать свои API, добавляя новые типы или удаляя старые.

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

Таким образом, вы не увидите API-интерфейсы GraphQL с конечными точками, подобными следующим:

https://example.com/api/v1/users/
https://example.com/api/v2/users/

Почему за GraphQL будущее

Еще в 2012 году Facebook столкнулся с проблемой, когда разрабатывал свои мобильные приложения, что привело к созданию GraphQL. Эти проблемы очень распространены, особенно когда мы говорим о разработке RESTful API. Как уже говорилось, эти проблемы:

• Низкая производительность
• Множество конечных точек
• Избыточное извлечение или неполное извлечение данных
• Создание другой версии каждый раз, когда нам нужно изменить или удалить что-то
• Сложность поддержания API

Имея в виду множество концепций, разработчики из Facebook разработали лучший способ разработки API, а затем назвали его GraphQL. По сути, это замена REST, с большим количеством улучшений.

С GraphQL мы получаем много новых функций, которые дают вам суперспособности при создании ваших API. Давайте рассмотрим их один за другим:

Единственная конечная точка

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

С GraphQL вы получаете только те данные, которые вам нужны

Нет больше избытка или нехватки данных. Вы получаете только те данные, которые вам нужны. Помните проблемы с низкой производительностью, которые мы обсуждали изначально? У нас этого больше нет, так как GraphQL повышает производительность вашего API, особенно в случае медленного сетевого соединения.

если вам нужно это:

user {
    firstName,
    lastName,
    age
}
вы можете получить только это :
user {
    firstName: 'firstName',
    lastName: 'lastName',
    age: 21
}

GraphQL позволяет легко создавать API и быть последовательным

Многие люди думают, что GraphQL довольно сложен, потому что он включает в себя схему и одну конечную точку. Как только вы начнете разрабатывать API, вы обнаружите, что это проще, чем вы думали.

Если вы не используете JavaScript в качестве основного языка, это не проблема, так как GraphQL — это язык запросов, и он не зависит от используемого языка программирования, что означает, что вы можете использовать его с любым языком. На момент написания этой статьи GraphQL поддерживает более 12 языков.

Популярность GraphQL

Тот факт, что GraphQL является языком запросов с открытым исходным кодом, означает, что сообщество может внести в него свой вклад. Когда Facebook выпустил его для сообщества, он получил большую поддержку и одобрение со стороны разработчиков. Сейчас популярность GraphQL быстро растет, так как все больше и больше разработчиков начинают создавать API-интерфейсы с ним. Однако некоторые люди спрашивают, действительно ли это заменит REST или станет новым способом создания API для реальных приложений.

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

В ноябре 2018 года GraphQL в сотрудничестве с Linux Foundation создал фонд GraphQL Foundation, что означает, что разработчики будут создавать больше документации, инструментов и развивать дальше этот язык запросов. Этот фонд обеспечит стабильное и устойчивое будущее для GraphQL. Так что это еще одна причина считать GraphQL API будущим.

Конечно, он не заменит REST сразу, потому что многие приложения все еще используют его, и невозможно переписать их в одночасье. По мере того, как все больше и больше компаний будут использовать GraphQL улучшатся и UX, и DX.

Заключение

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

Статья написано на основе статьи Leonardo Maldonado
Why GraphQL is the Future of APIs