Почему GraphQL и в чем его преимущества??

Почему GraphQL и в чем его преимущества??

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

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

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

ОТДЫХ

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

Тем не менее, REST предлагает свой собственный способ реализации, и иногда он усложняется в определенных случаях использования. Давайте посмотрим, что они из себя представляют:

Несколько конечных точек

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

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

Излишнее и недостаточное получение информации

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

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

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

Версии

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

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

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

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

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

Чем полезен GraphQL

Как уже говорилось, GraphQL более гибок и эффективен для реализации определенных вариантов использования, где мы можем столкнуться с некоторыми проблемами:

• Плохая работа
• • Множество конечных точек
• • Излишняя или недостаточная выборка данных
• • Отправка новой версии каждый раз, когда нам нужно что-то добавить или удалить.
• По сути, это замена REST в определенных случаях использования с множеством гибких возможностей.
• С GraphQL мы получаем множество новых функций, которые дают вам супервозможности при создании своих API. Давайте рассмотрим их один за другим:
• Единая конечная точка
• Нет необходимости создавать много конечных точек! С GraphQL мы получаем только одну конечную точку, и с ее помощью мы можем получить столько данных, сколько захотим, в одном запросе. По сути, GraphQL объединяет все ваши запросы, изменения и подписки в одну конечную точку и делает ее доступной для вас. Это улучшает ваш цикл разработки, поскольку вам не нужно делать два запроса для получения данных из двух разных ресурсов. Кроме того, представьте, что мы создаем огромное приложение, у нас не будет много конечных точек и тонны кода, как с REST. Мы получим одну конечную точку, и с помощью этой конечной точки мы можем делать столько запросов, сколько захотим.

Кроме того, как я сказал выше, подход «только для конечной точки» делает ваш API самодокументированным, поскольку вам не нужно создавать документацию, потому что ваши разработчики уже знают, как ее использовать. Они могут понять API, просто взглянув на код или взглянув на игровую площадку.

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

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

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

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

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

Вывод

В нашем дизайне для предстоящей работы мы абстрагировали реализацию репозитория в служебном микросервисе «Мост данных», где мы будем управлять несколькими источниками данных. У нас также есть абстрактный уровень обработки данных, отдельный как «Сборщик данных», и этот уровень будет подключаться к Data Bridge для извлечения данных.

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