Какие схемы GraphQL называя лучшие практики?

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

  1. вообще полезно / идиоматично держать имя "Интерфейс" во имя интерфейса? Например,Profile или ProfileInterface предпочтительнее в большом приложении?

    interface ProfileInterface {
  # fields here...
}

type UserProfile implements ProfileInterface {
  # implemented fields here...
}

  2. часто ли указывать значения одного перечисления как "константы"?

    enum GeoJSONFeatureTypeConstant {
  feature
}

interface GeoJSONFeatureInterface {
  id: ID
  type: GeoJSONFeatureTypeConstant!
  geometry: GeoJSONGeometryInterface!
  properties: GeoJSONProperties
}

  3. это лучшая практика, чтобы объявить все или ничего objectкак scalar или type, и где проводится линия между ними? Представьте себе Point тип, который обычно представляется в виде массива [x,y]; что было бы больше idiomadic?

    scalar Point

type Point {
  x: Float
  y: Float
}
  4. любые другие рекомендации, конкретно связанные с соглашениями об именах или объявлениями типов в GraphQL, которые было бы трудно узнать без опыта.

спасибо заранее!

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

именование типов ввода с Вклад в конце-полезное соглашение, потому что вам часто понадобится как тип ввода, так и тип вывода, который несколько отличаются для одного концептуального объекта.

http://graphql.org/graphql-js/mutations-and-input-types/

21
graphql idioms reactjs schema

1 ответов

Я размышлял над этими же вопросами, и я надеюсь, что это будет полезно для вас.

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

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

3. если вы решили реализовать скалярный тип, то это до вас, чтобы проверить поле. В этом конкретном случае предоставление точки как типа имеет наибольший смысл, поскольку точка может быть 2-D или 3-D. определение ее как типа является более декларативным.

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

вот раздел для пользовательских скаляры. Вот это пример.

4. вы найдете этой статья ли Байрона полезна.

6