#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:
API GraphQL организованы в терминах типов и полей, а не конечных точек. Получите доступ ко всем возможностям ваших данных с одной конечной точки.
Следовательно, создание двух конечных точек, как вы предложили, противоречило бы этому принципу. Вероятно, вам не следует этого делать, но, что наиболее важно, в этом нет необходимости.
Предположим, у вас есть тип ProductType
с парой полей. Вы можете использовать этот же тип как для запроса / отображения данных о продукте на вашем веб-сайте, так и для редактирования с изменением на странице администратора. Конечно, вам, возможно, придется иметь дело с авторизацией некоторых конкретных запросов и мутаций, но это не должно быть сложнее, чем иметь дело с авторизацией в REST.
Смотрите больше об авторизации GraphQL в Ruby.
Комментарии:
1. Спасибо за ваши советы и ссылки!
2. Вполне могут быть случаи, когда приложение имеет несколько различных типов участников (обычно «посетитель», «зарегистрированный пользователь», «администратор» и т.д.) И управление тем, что каждый из участников может запросить для некоторых
ProductType
в одном файле, может запутаться. Возможно, было бы чище предоставлять типы, предназначенные для разных участников, и просто отвечать 403, если есть несоответствие, YMMW.