GraphQL Ruby, использующий пространство имен

#ruby-on-rails #graphql #graphql-ruby

#ruby-on-rails #graphql #graphql-ruby

Вопрос:

Я использую graphql-ruby в своем приложении rails. В настоящее время структура каталогов моего приложения выглядит следующим образом.

 app 
 - controllers 
  - application_controller.rb
  - graphql_controller.rb
  - admin
    - application_controller.rb
    - graphql_controller.rb
- graphql
  - types
  - mutations
  - graphql_schema.rb
  

Я пытаюсь создать простую страницу администратора, но я не уверен, как мне следует управлять пространствами имен с помощью graphql-ruby.

Должен ли я также создать Admin каталог под graphql и types под ним для данных, которые я хочу использовать на странице администратора? mutations и не под ним??

Кроме того, должен ли я создать другую конечную точку для Admin , подобную приведенному ниже коду??

 Rails.application.routes.draw do
 namespace :admin do
   post :graphql, to: 'graphql#execute'
 end
 post :graphql, to: 'graphql#execute'
end
  

Не могли бы вы дать мне ссылку на проект, который делает то, что я пытаюсь сделать с graphql-ruby??? Это было бы огромной помощью.

Ответ №1:

Из https://graphql.org /

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

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

Предположим, у вас есть тип ProductType с парой полей. Вы можете использовать этот же тип как для запроса / отображения данных о продукте на вашем веб-сайте, так и для редактирования с изменением на странице администратора. Конечно, вам, возможно, придется иметь дело с авторизацией некоторых конкретных запросов и мутаций, но это не должно быть сложнее, чем иметь дело с авторизацией в REST.

Смотрите больше об авторизации GraphQL в Ruby.

Комментарии:

1. Спасибо за ваши советы и ссылки!

2. Вполне могут быть случаи, когда приложение имеет несколько различных типов участников (обычно «посетитель», «зарегистрированный пользователь», «администратор» и т.д.) И управление тем, что каждый из участников может запросить для некоторых ProductType в одном файле, может запутаться. Возможно, было бы чище предоставлять типы, предназначенные для разных участников, и просто отвечать 403, если есть несоответствие, YMMW.