Что это за вещь GraphQL и почему вам должно быть дело до того, являетесь ли вы фронтенд-разработчиком или бэкэнд-разработчиком.

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

Если вы разработчик, имеющий некоторый опыт работы с динамическими приложениями, управляемыми данными (конечно, да), вы наверняка слышали волшебные слова - «REST API». Теперь REST - настоящий золотой стандарт в разработке API, который давным-давно превзошел SOAP. Когда REST ворвался на сцену, были некоторые сильные спецификации, чтобы поддержать его, некоторые правила, которые нужно было соблюдать и поддерживать, чтобы служба API называлась RESTful, но это пошло не так хорошо, и теперь мы видим, что любой другой API утверждает, что является службой RESTful, независимо от того, следует ли он заповедям или нет. У RESTful API есть много преимуществ: они обычно надежны, поддерживают модульность и чрезвычайно гибки.

Так в чем проблема? Если это все радуги и бабочки с REST API, тогда зачем беспокоиться. Ну, потому что это НЕ. С REST API все не в порядке. Позвольте мне пролить свет на это на красивом, наивном примере. Предположим, вы приступили к созданию приложения с веб-клиентами и мобильными клиентами, что сегодня довольно распространено. Давайте продолжим создавать лучшую в мире социальную сеть -

Чтобы загрузить эту единственную страницу, нам потребуются следующие вызовы API (возможно, больше или меньше):

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

Это не все наши страдания. Давайте посмотрим на некоторые ответы нашего API.

API-интерфейсы REST, как правило, выделяют больше данных, чем фактически требуется, время от времени, а иногда и наоборот, когда вы должны использовать ответ API в качестве аргумента для вызова другого API. Рассмотрим ответ API / id / followers, который выдает всех подписчиков определенного пользователя. Проблема здесь в том, что наш пользовательский интерфейс на мобильном устройстве требует отображения только трех последних подписчиков. Предположим, у нашего отважного пользователя Spongebob тысячи подписчиков, информация об этих тысячах подписчиков берется из API подписчиков - просто чтобы показать последние 3. Даже если 100 объектов информации о подписчиках занимают 1 КБ, мы загружаем 10 КБ данных, чтобы получить последних 3 подписчиков. Но мы можем разработать другой API, который выдает в ответ только трех последних подписчиков! вы видите, что обновление API-интерфейсов и добавление новых API-интерфейсов только для того, чтобы получить данные в той или иной форме для определенного интерфейса, значительно снизят скорость разработки. Это всего лишь один интерфейс (мобильный), о котором мы говорим. Допустим, ваша организация завтра планирует запустить свое приложение для Android с другим пользовательским интерфейсом для просмотра профиля, веб-сайта или чего-то еще для смарт-телевизоров или Apple Watch, поэтому, если вы являетесь внутренним разработчиком, у вас, мой друг, всегда будут большие проблемы. что-то меняется. Хотя если вы являетесь разработчиком внешнего интерфейса и ваш код разбросан вызовами API и кодом сопоставления данных, что часто приводит к неоптимальной производительности, ваш босс не будет очень доволен, и конечный пользователь не будет испытывать нестандартную производительность. Забудьте о смартфонах за 1000 долларов, которые они купили.

Итак, вкратце, следующие недостатки старых добрых REST API делают их неэффективным механизмом для передачи данных / обмена данными через Интернет.

  1. Приложения стали довольно сложными и управляются данными по своей природе, и, поскольку мы живем в эпоху первых мобильных устройств, когда мы начинаем проектировать вещи с нуля, используя так называемый подход, ориентированный на мобильные устройства, потребление данных / энергии с помощью REST API может быть значительно выше. .
  2. Современная разработка приложений является многоплатформенной с множеством различных интерфейсов для приложения с различными представлениями и набором функций. Это часто приводит к проблемам с избыточной и недостаточной выборкой в ​​приложении. Некоторые приложения имеют разные REST API для разных клиентов, но действительно ли это то, что вам нужно?
  3. Сегодняшний процесс разработки программного обеспечения является быстрым и требует быстрых итераций, обновлений, и все, как правило, или желательно, чтобы двигаться быстрее. Разработка или настройка REST API каждый раз, когда вы хотите добавить новую функцию или обновить существующую в своем приложении, может быть довольно обременительным и может снизить скорость разработки.

Итак, что это за GraphQL и как он здесь подходит? 🤷🏻‍♂️

Прежде чем вы начнете ломать голову над потенциальным бременем изучения другого фреймворка / библиотеки javascript, позвольте мне прояснить ситуацию, сказав, что GraphQL не является ни языком, ни фреймворком (в его реальном значении), все это - - это спецификация, стандарт API, за всеми наворотами это всего лишь синтаксис, который берет свое начало в Facebook, точно так же, как React и несколько других замечательных вещей с открытым исходным кодом. Итак, следующий вопрос: для чего нужна эта спецификация? Хороший приятель, это спецификация, синтаксис, описывающий, как вы должны запрашивать данные для ваших приложений, управляемых данными, с сервера / базы данных у ваших клиентов. С гигантскими приложениями, управляемыми данными, повсюду - Netflix, Twitter и Facebook, среди многих других, REST API - это просто не путь в будущее, поскольку в масштабе вышеупомянутые проблемы с REST API стали серьезной головной болью.

Facebook разработал GraphQL и начал использовать его в своих клиентах с 2012 года. Они публично рассказали о GraphQL на конференции React Conf 2015, а также открыли исходный код несколько дней спустя ❤️. К этому времени некоторые другие игроки, такие как Netflix, также разработали свои собственные решения, такие как Falcor, исходный код которого также был позже открыт. Таким образом, одно остается в стороне: GraphQL не нов, и он стал популярным стандартом для получения данных с использованием производственного уровня на некоторых из крупнейших платформ, таких как Twitter, Pinterest, GitHub и других. В первые дни Facebook говорил о GraphQL в синергии с React, но, будучи независимой от языка спецификацией, GraphQL потребовалось некоторое время, чтобы начать использовать с другими интерфейсными технологиями, такими как Angular и другими.

Facebook запустил собственную реализацию GraphQL и связанных с ней утилит под названием Relay. Relay - это сильно оптимизированная платформа Javascript Framework, которая уже давно используется Facebook вместе с React. Великолепное сообщество GraphQL придумало собственную реализацию под названием Apollo. Популярность Apollo растет не по дням, а по часам, так как у него более легкая кривая обучения и в нем много полезного, чтобы сделать опыт разработки GraphQL качественным. Давайте узнаем больше о GraphQL и о том, как он работает.

Традиционный поток данных

Итак, как это происходит сейчас? Просто у вас есть интерфейс, который вызывает множество API, получает данные и отображает страницу. В нашей социальной сети это можно увидеть как вызов user_info / id, за которым следуют вклады и вызовы API / followers. В вашем случае это может быть сложно с вложением и цепочкой вызовов API. Один ответ API является аргументом для других вызовов и так далее. Предположим, вам нужно выполнить несколько дел по дому, например, убрать вещи, купить вещи для дома в супермаркете и приготовить еду. Теперь вам нужно выполнить эти 3 задачи на своем, и в некотором предопределенном порядке в соответствии с требованиями.

Как это работает GraphQL?

Итак, достаточно разговоров о REST API, как GraphQL решает эти проблемы?

GraphQL является промежуточным звеном между REST API и интерфейсами. По сути, происходит то, что вы делаете один декларативный вызов необходимых данных из БД, и все. GraphQL обработает запросы и предоставит данные, необходимые для вашей страницы, в описанном формате. Возвращаясь к нашей бытовой метафоре. Это как с Альфредом. Просто спросите Альфреда, и он позаботится обо всех задачах и просто ответит вам окончательным результатом.

Позвольте мне объяснить, насколько легко и без проблем с GraphQL делать запросы и получать данные с сервера.

Этот интуитивно простой запрос GraphQL даст нам следующий ответ:

Разве это не волшебно? Нет избыточной выборки, поскольку вы просто получаете данные, которые запрашиваете в своем запросе, с точно такими же полями. Теперь, завтра, если вам также нужно показать страну подписчиков в пользовательском интерфейсе, не нужно играть с API. Просто добавьте новое поле «страна» в свой запрос GraphQL, и все. Выполнено. То, насколько этот тип механизма декларативных запросов может помочь более крупным и сложным приложениям, управляемым данными, просто вдохновляет. Как насчет той проблемы, когда у нас была тысяча подписчиков, в то время как пользовательскому интерфейсу требовались только последние 3? Нет, вам не нужно писать дополнительный API или даже новый запрос. Просто добавьте новый параметр в запрос и исправьте свой преобразователь (? *), Чтобы оценить то же самое. Нравится -

Разве это не слишком круто? запросы данных в лучшем виде с помощью GraphQL. Но это еще не все, что GraphQL может показать ... Мы только поцарапали поверхность ... есть еще много всего, и перед этим нам нужно понять основные компоненты GraphQL, которые составят большую часть следующей части этой серии. Следите за обновлениями, чтобы узнать больше о GraphQL и о том, как с его помощью создавать потрясающие вещи. Я закончу этот пост хорошим обзором того, что предлагает GraphQL -

  1. GraphQL - это типобезопасный механизм запросов, который также открывает путь для агрегации данных из нескольких источников данных в приложении.
  2. Эффективный способ запроса вашей базы данных, позволяющий интерфейсам запрашивать именно те данные, которые им нужны.
  3. Более высокая скорость разработки благодаря быстрому и простому внесению изменений в данные, необходимые в приложении.

Итак, все, ребята, в следующей части мы рассмотрим основные строительные блоки GraphQL. Увидимся там. 👋🏻

Спасибо.

* Резольверы будут обсуждены в следующей части