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

В своей статье 1976 года «Как изобретают комитеты?» Мелвин Конвей писал: «Организации, использующие системы проектирования, вынуждены производить проекты, которые являются копиями их коммуникационной структуры». Всякий раз, когда информация должна пересекать границы команды, каждая из них может задержать, расставить приоритеты, а иногда даже исказить или изменить информацию. Имея это в виду, Сэм Ньюман в 2015 году описал шаблон, который он назвал «Бэкэнды для внешних интерфейсов» (BFF), который требует, чтобы команда фронтенда владела уровнем, который буферизует дизайн их кода от дизайна сервисного уровня. . Какое отношение все это имеет к GraphQL? GraphQL — это реализация шаблона BFF.

Мы обнаружили, что GraphQL облегчает жизнь не только фронтенд-командам, но и бэкэнд-командам или командам сервисного уровня. Например, наш экран отчета объединяет данные из нескольких разных микросервисов. Эти службы были созданы с учетом нормализации, что имеет смысл, если вы создаете слой службы, но кажется громоздким, если вы создаете слой пользовательского интерфейса. API возвращает определение отчета, но не фактические данные отчета. Итак, есть один запрос на получение определения, затем куча других запросов на вспомогательные данные, которые описываются определением. После того, как мы сделали все эти запросы, мы наконец можем сделать запросы (по 4 на плитку) для отображения фактических метрик на каждой плитке (см. рис. 1).

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

  • 1 запрос на получение определения отчета
  • 4 запроса на заполнение различных кешей, в которых нуждаются все наши файлы
  • 32 запроса (по 4 на тайл) для получения фактических метрических данных для каждого тайла

37 запросов на отчет, и когда вы помните, что кэширование не работает для данных, которые должны быть свежими, мы начинаем видеть, что экраны наших клиентов работают медленно, а батареи быстро разряжаются. Таким образом, мы могли бы:

  1. Общайтесь с сервисной командой, чтобы либо создавать новые сервисы, либо изменять существующие сервисы, чтобы удовлетворить потребности нашего приложения.
  2. Укусите пулю и просто делайте запросы от клиента

Если вы когда-нибудь пытались поговорить со своей командой обслуживания, чтобы убедить их, что вы на самом деле являетесь особенной снежинкой и что ваши изменения действительно необходимы, вы поймете почему мы не выбрали вариант А. Такие разговоры сталкивают различия между командами друг с другом и могут способствовать недопониманию между командами. Вариант B просто должен был бы работать, если бы не было лучшего способа. Но есть лучший способ. Так как же GraphQL помогает решить эту проблему? Возможно, вы в первую очередь слышали, что основное преимущество GraphQL заключается в том, чтобы формировать запрос так, как вы хотите, чтобы ваш ответ был сформирован так, чтобы каждый запрос соответствовал вашим потребностям, но это только часть преимущества, которое мы поняли. Давайте посмотрим, как будет выглядеть наш запрос GraphQL:

report(id: $id) {
  id
  name
  description
  owner {
    id
    name
  }
  dataBucket {
    bucketid
    name
  }
  filters {
    id
    name
  }
  metricTile {
    id
    name
    metric {
      id
      name
      type
    }
    data
    comparisonData
    }
}

Таким образом, вместо вызова одной службы для получения файла, другой службы для получения dataBucket, еще одной службы для получения фильтров, еще одной службы для получения metricTiles, еще одной службы для получения данных и той же службы снова для сравнения данных мы пишем один запрос, который GraphQL затем анализирует и пропускает через нашу иерархию распознавателей. Затем внутри каждого резолвера мы делаем все различные вызовы ко всем различным службам, которые нам нужны, и возвращаем один ответ. Не говоря уже о том, что в ответе нет лишней информации, которая в противном случае засорила бы наши интернет-каналы!!

Теперь наши back-end и front-end команды могут свободно сосредоточиться на своей работе: front-end команда может создавать пользовательские интерфейсы на основе данных, которые лучше соответствуют их потребностям, чем хорошо сшитый костюм, а back-end команда может создавать сервисы таким образом, чтобы данные передавались всем их клиентам без необходимости идти на одноразовые компромиссы, о которых они могут пожалеть позже. Использование GraphQL в качестве бэкенда. Для нашего внешнего интерфейса мы больше не боремся с законом Конвея: наши команды работают независимо, и предотвращается сбой большего количества задач из-за несоответствия приоритетов и сбоев связи.