Проекты, где REST больше подходит для GraphQL? [закрытый]

основываясь на статьях, которые я читал, GraphQL более ресурсоэффективен с точки зрения roundtrips, и он также может делать то, что может предоставить REST. Каковы причины, по которым software architect & developers могут решить остаться с REST над GraphQL, учитывая, что веб-приложение будет просто запущено с нуля? Также учитывая, что это непрерывный проект, будет потребляться из интернета и мобильного и openID connect является требованием.

7
architecture graphql rest web-applications

3 ответов

на мой взгляд, это – среди прочего – еще и вопрос варианты использования:

  • Если у вас есть что-то вроде приложения или другого интерфейса с медленным подключением и/или высокой задержкой (типичный пример: мобильное приложение), "минимизация обратного хода" GraphQL может быть большим плюсом. И это может быть довольно удобно, чтобы дать клиенту контроль над структурой данных, тем самым часто уменьшая количество необходимых конечных точек API.
  • Если это скорее обмен данными между серверами тот факт, что API RESTful сильно связаны с HTTP, имеет такие преимущества, как семантика глаголов (которые GraphQL не может предложить, поскольку вы выполняете несколько операций с одним запросом GraphQL) и коды состояния. Плюс: вы получаете все функции кэширования HTTP бесплатно, что может быть очень важно в сильно управляемых данными приложениях/службах. Кроме того, REST вездесущ (хотя, вероятно, большинство API, рекламируемых как "RESTful", часто из-за отсутствия поддержки гипермедиа.)
4

Это довольно широкий вопрос, но я попробую ответить исходя из собственного опыта.

REST предоставляет доступ к определенному ресурсу, например пользователю или продукту. Результатом запроса, скорее всего, будет предположение каких данных вы хотите или используете, т. е. это, вероятно, все об этом ресурсе независимо от того, используете ли вы все данные или нет.

существует также проблема N+1. В качестве примера возьмем пользователя has и принадлежит многим сценарий отношений; с RESTful API вы бы сделали запрос пользователю, например /users/:id затем сделайте запрос ко всем их отношениям, например /users/:id/relationships, Так что это уже две просьбы. Там может быть предположение конечной точки отношений, чтобы включить как отношения (друг, член семьи и т. д.) и пользователь в результирующем массиве, но если API этого не делает предположение, вам придется сделать запрос к каждой конечной точке пользователя, чтобы получить данные о каждом пользователе в каждой связи.

этот пример также может пойти глубже; что, если вы хотите все отношения второго уровня (например, друзья друзей)?

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

query myQuery($userId: ID!) {
  user(id: $userID) {
    id
    name
    relationships {
      id
      type
      user {
        id
        name
        relationships {
          id
          type
          user {
            id
            name
          }
        }
      }
    }
  }
}

фрагменты могут немного очистить это, и могут возникнуть рекурсивные проблемы, но вы должны получить идею; один запрос получает все вложенные данные, которые вы необходимость.

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

однако одним из самых больших преимуществ, которые я нашел в GraphQL, является его расширяемость и самостоятельная документация.

4

там может быть несколько причин. Это очень субъективно, я считаю, но для меня это основано на:

отдых-это старый и устойчивый путь. Он используется большинством и обеспечивает простой интерфейс для потребителей API. Потому что это старая (отнюдь не плохая вещь), большинство разработчиков знают о ней и знают, как ее потреблять.

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

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

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

1