reactjs - ¿Cuáles son algunas de las mejores prácticas para nombrar esquemas GraphQL?

apollo client

Question

Estoy comenzando el desarrollo en una aplicación no trivial para la cual estamos considerando GraphQL. Al trabajar en el borrador inicial de nuestro esquema, me he quedado un poco paralizado al tratar de establecer convenciones de nombres que se escalarán a medida que el producto madure. Realmente agradecería que alguien que haya tenido que hacer crecer un esquema y se haya encontrado, o haya evitado con éxito los callejones sin salida o las inconsistencias:

1. ¿Es generalmente útil / idiomático mantener el nombre "Interfaz" en el nombre de una interfaz? Por ejemplo, ¿sería preferible Profile o ProfileInterface en una aplicación grande?

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

2. ¿Es común especificar valores de enumeración única como "constantes"?

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

3. ¿Es una buena práctica declarar object todo o nada como scalar o type , y dónde se traza la línea entre los dos? Imagina un tipo de Point que normalmente se representaría como una matriz [x,y] ; ¿Cuál sería más idiomádico?

   scalar Point
   type Point {
   x: Float
   y: Float
   }

4. Cualquier otra práctica recomendada relacionada específicamente con las convenciones de nombres o declaraciones de tipos en GraphQL que sería difícil de conocer sin experiencia.

¡Gracias por adelantado!

Esta pregunta no ha ganado el impulso que me hubiera gustado, así que comenzaré a publicar fragmentos útiles a medida que los encuentre, lo que puede evolucionar en una especie de respuesta.

Nombrar tipos de entrada con Entrada al final es una convención útil, porque a menudo querrá tanto un tipo de entrada como un tipo de salida que sean ligeramente diferentes para un solo objeto conceptual.

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

Answer 1

Reflexioné sobre estas mismas preguntas y espero que esto les sea útil.

1. No creo que agregar Interfaz al final de cada interfaz sea idiomático. Es mucho mejor tener un nombre descriptivo en su lugar. Considere el ejemplo provisto en la especificación GraphQL relativa a las interfaces. No añaden interfaz a ninguno de sus tipos.

2. Las enumeraciones solo son ventajosas cuando hay varios valores relacionados. No veo que la inclusión de tipos sea útil cuando solo hay un valor posible. Los valores de Enum también se nombran con mayúsculas y guiones bajos según la Especificación de GraphQL relacionada con Enums.

3. Si decidió implementar un tipo escalar, entonces es su responsabilidad validar el campo. En este caso específico, proporcionar Punto como un tipo tiene más sentido ya que un Punto podría ser 2-D o 3-D. Definirlo como un tipo es más declarativo.

Valores como Fecha, Correo electrónico y URL son ejemplos comunes para tipos escalares. Proporcionan valor semántico y los clientes sabrán qué esperar de estos campos.

Aquí está la section relevante para los escalares personalizados. Aquí hay un example .

4. Encontrará útil this artículo de Lee Byron.