Интенсивное чтение «Как выбрать REST, GraphQL, Webhooks и gRPC»

внешний интерфейс API gRPC GraphQL

1. Введение

Всякий раз, когда проект входит в стадию совместной отладки или интерфейс согласовывается заранее, фронтенд и бэкенд собираются вместе и ведут жаркое обсуждение. Возможно, 99% сценариев соглашаются с Http-интерфейсом, обсуждают, что такое URL-адрес, каковы входные параметры и каковы выходные параметры.

Некоторые команды имеют более эффективные соглашения об интерфейсе внешнего и внутреннего интерфейса: серверная часть сама создает код определения интерфейса, а клиентская часть преобразует (или автоматически преобразует) файл определения Typescript.

Но эти работы для интерфейса Http, который сегодня переданwhen-to-use-what-rest-graphql-webhooks-grpcВ этой статье, помимо Http-интерфейса, который всегда один и тот же во время совместной отладки, давайте посмотрим, как можно согласовать интерфейс, какие сценарии применимы друг к другу и в каком сценарии вы сейчас находитесь.

2 Обзор

В этой статье в основном рассказывается о четырех схемах проектирования интерфейса, а именно: REST, gRPC, GraphQL и Webhooks, которые будут представлены ниже.

REST

REST — это, пожалуй, самое общее и наиболее часто используемое решение для дизайна интерфейса.лица без гражданства, с ресурсом в качестве ядра, определяет ряд соглашений URL о том, как работать с ресурсом, а тип операции определяетсяGET POST PUT DELETEи т. д. HTTP-методы сказали.

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

В будущем REST может лучше подходить для предоставления API микросервисов.

Пример использования:

curl -v -X GET https://api.sandbox.paypal.com/v1/activities/activities?start_time=2012-01-01T00:00:01.000Z&end_time=2014-10-01T23:59:59.999Z&page_size=10 \
-H "Content-Type: application/json" \
-H "Authorization: Bearer Access-Token"

gRPC

gRPC — это новая попытка RPC, самая большая особенность — использование языка protobufs для форматирования данных.

RPC в основном используется для вызовов методов между серверами, и наиболее важным фактором, влияющим на его производительность, является эффективность сериализации/десериализации. Целью RPC является создание высокоэффективного метода вызова службы с низким потреблением, поэтому он больше подходит для Интернета вещей и других сценариев, чувствительных к ресурсам, пропускной способности и производительности. А gRPC использует protobuf для дальнейшего повышения скорости сериализации и уменьшения размера пакетов.

Пример использования:

gRPC в основном используется для передачи между сервисами, вот пример Nodejs:

  1. Определите интерфейс. Поскольку gRPC использует protobufs, файл определения интерфейсаhelloword.proto:
// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
  // Sends another greeting
  rpc SayHelloAgain (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

услуга определяется здесьGreeter, имеет два метода:SayHelloа такжеSayHelloAgain,пройти черезmessageКлючевые слова определяют структуру входных и выходных параметров.

На самом деле с protobufs при передаче данных передается лишь небольшое количество контента.В качестве цены обе стороны должны знать правила определения интерфейса для сериализации/десериализации.

  1. Определите сервер:
function sayHello(call, callback) {
  callback(null, { message: "Hello " + call.request.name });
}

function sayHelloAgain(call, callback) {
  callback(null, { message: "Hello again, " + call.request.name });
}

function main() {
  var server = new grpc.Server();
  server.addProtoService(hello_proto.Greeter.service, {
    sayHello: sayHello,
    sayHelloAgain: sayHelloAgain
  });
  server.bind("0.0.0.0:50051", grpc.ServerCredentials.createInsecure());
  server.start();
}

мы в50051Порт поддерживает службу gRPC, и служба зарегистрированаGreeter, и кsayHello sayHelloAgainМетод выполняет некоторую бизнес-обработку и возвращает некоторые данные вызывающей стороне.

  1. Определите клиента:
function main() {
  var client = new hello_proto.Greeter(
    "localhost:50051",
    grpc.credentials.createInsecure()
  );
  client.sayHello({ name: "you" }, function(err, response) {
    console.log("Greeting:", response.message);
  });
  client.sayHelloAgain({ name: "you" }, function(err, response) {
    console.log("Greeting:", response.message);
  });
}

Видно, что клиент и сервер должны получить структуру прототипа одновременно, и передача данных клиента также зависит от методов, предоставляемых пакетом proto.Фреймворк выполнит встроенную работу по сериализации/десериализации.

Существуют также некоторые дополнительные средства для преобразования gRPC в службу http, чтобы веб-страница также могла пользоваться преимуществами ее высокой эффективности и низкого потребления. Но не забывайте, что наиболее часто используемые сценарии для RPC относятся к аппаратному обеспечению, такому как Интернет вещей, а сценарии веб-страниц могут не заботиться об экономии нескольких КБ трафика.

GraphQL

GraphQL — это не замена REST, а еще одна форма взаимодействия: передняя часть решает, что возвращает задняя часть.

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

Опять же, по сравнению с REST и gRPC, GraphQL — это анти-шаблон, где внешний интерфейс решает, что возвращать.

Пример использования:

Оригинальная рекомендуемая ссылкаGitHub GraphQL API

Например, для запроса членов организации интерфейс REST может быть:

curl -v https://api.github.com/orgs/:org/members

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

query {
  organization(login: "github") {
    members(first: 100) {
      edges {
        node {
          name
          avatarUrl
        }
      }
    }
  }
}

Возвращаемый результат соответствует согласованному формату и структуре, и лишних полей не будет:

{
  "data": {
    "organization": {
      "members": {
        "edges": [
          {
            "node": {
              "name": "Chris Wanstrath",
              "avatarUrl": "https://avatars0.githubusercontent.com/u/2?v=4"
            }
          },
          {
            "node": {
              "name": "Justin Palmer",
              "avatarUrl": "https://avatars3.githubusercontent.com/u/25?v=4"
            }
          }
        ]
      }
    }
  }
}

Но видно, что для этого требуется система, которая поможет вам написатьquery, многие фреймворки предоставляют эту функцию, напримерapollo-client.

Webhooks

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

Это лучше всего подходит для решения проблем с опросом. Или опрос — это компромиссное поведение, когда бэкенд не поддерживает режим Webhooks.

Пример использования:

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

В итоге автор сделал вывод, что эти четыре сценария имеют разные сценарии использования и не могут быть заменены друг другом:

  • REST: структура передачи данных без сохранения состояния, подходящая для общих сценариев быстрой итерации и стандартизированной семантики.
  • gRPC: упрощенный метод передачи, особенно подходящий для сценариев с высокими требованиями к производительности или неблагоприятных условий, таких как Интернет вещей.
  • GraphQL: запрашивающая сторона может настроить формат возврата, что может в некоторой степени снизить затраты на совместную отладку интерфейсной и серверной частей.
  • Webhooks: Служба push, в основном используемая в сценариях, когда сервер активно обновляет клиентские ресурсы.

3 Интенсивное чтение

REST подходит не для всех сценариев

Эта статья дает нам более широкое представление о проблеме интерфейса в повседневной разработке.Для фронтенд-студентов, которые сражаются на передовой, 90% интерфейсов являются интерфейсами Http, которые не являются правилами REST.На самом деле очень мало команд, которые могут действительно реализовать REST. На самом деле это поднимает важный вопрос: насколько преимущества REST учитываются во всем бизнес-процессе?

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

gRPC — лучший выбор для взаимодействия на стороне сервера

Когда студенты, изучающие внешний интерфейс, переключаются на разработку узлов, им нравится использовать Http для связи между серверами, но они могут задаться вопросом, почему внутренние службы Java или C++ компании не предоставляют вызовы Http, а используют другое имя. После понимания gRPC вы можете понять, что все эти платформы являются инкапсуляцией методов RPC.Обмен данными между серверами имеет очень высокие требования к производительности и задержке, поэтому он больше подходит для таких служб, как gRPC, которые оптимизированы для производительности.

GraphQL требует компаньона

GraphQL не является заменой REST, поэтому не ожидайте, что команды перейдут с Http на GraphQL, чтобы повысить эффективность разработки на X%. Решение GraphQL представляет собой новое соглашение о взаимодействии между интерфейсом и сервером, поэтому стоимость начала работы будет относительно высокой. часть внутренней рабочей нагрузки на внешний интерфейс.Если в настоящее время нет простой в использовании платформы Быстро просмотрите, сгенерируйте и поддерживайте эти определения, и эффективность разработки может не увеличиться, а уменьшиться.

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

Веб-хуки для решения особых проблем со сценами

Для проверки сторонней платформы, входа в систему и т. д.Нет внешнего интерфейса для сценариев перевода или сценариев оплаты с высокими требованиями к безопасности и т. д., подходит для активной отправки данных с помощью веб-перехватчиков. Грубо говоря, когда интерфейс не может участвовать или не подходит для участия из-за проблем с безопасностью интерфейса, это сценарий вебхуков. Очевидно, что Webhooks не является заменой Http, но это действительно новый способ взаимодействия между интерфейсом и сервером.

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

4 Резюме

Наконец, в приведенном выше содержании должно быть много упущений, которые можно добавить.

еще 5 обсуждений

Адрес обсуждения:Интенсивное чтение «Как выбрать REST, GraphQL, Webhooks и gRPC» · Выпуск №102 · dt-fe/weekly

Если вы хотите принять участие в обсуждении, пожалуйста,кликните сюда, с новыми темами каждую неделю, выходящими по выходным или понедельникам.

Категории