Repository files navigation

1. Esquema GraphQL
2. Scalar Types
3. Object Types
4. Enum Types
5. Type Modifiers
6. Interfaces
7. Root Types
8. Input Types
9. Comentarios
10. Merge, alias y fragment
11. Query Variables
12. Include y skip

• Centro de cualquier implementación del servidor del GraphQL.
• Sin el esquema no podemos contruir la API.
• Es la parte más compleja de un proyecto GraphQL.
• Nos alejamos de la filosofía de las API REST.

• Definido por los tipos y directivas que admite.
• Tipos de operación que admite:
  • Query.
  • Mutation.
  • Subscription.

• Nombres únicos en tipos.
• Nombres de directivas únicos.
• Tipos y directivas no pueden comenzar con dos guiones bajos.

• Nombres de campos en camelCase.
• Nombres de tipos en PascalCase.
• Enums:
  • Nombres de tipo en PascalCase.
  • Valores en ALL_CAPS.

• Datos primitivos que pueden almacenar un solo valor.
• Con los tipos de objeto y tipo de raíz imprescindible.
• Define la mayoría de las propiedades de las entidades.

• Int: números enteros.
• Float: números con decimales.
• String: cadena de caracteres.
• Boolean: Verdadero/falso.
• ID: Identificador único (Int o String).

• Se define en el schema.graphql
• Añadir en elresolver de tipos.
• Implementar con elGraphQLScalarType.
• Definir las propiedadesparseValue, serialize y parseLiteral.

• Entidades con las que modelamos y estructuramos los servicios.
• Objetos personalizados que definen cómo se verá en la API.
• Se pueden definir tantos tipos como se desee.
• Todos los tipos deben de tener campos.

• schema.graphql

typeProfesor {nombre:Stringapellidos:Stringexperiencia:Int}typeAsignatura {id:IDnombre:StringhorasLectivas:Intprofesor:Profesor}

• Similar a un tipo scalar.
• Útiles para trabajar con una lista de valores predefinidos.
• Para crear un enum dentro del schema usar "enum" en lugar de "type".

typeProfesor {nombre:Stringapellidos:Stringexperiencia:Intcurso:Cursos=NPM}enumCursos {    GRAPHQL_DE_CERO    NPM    COMPODOC}

• Sirven para modificar el comportamiento cuando usamos un tipo.
• !: Indica valor obligatorio.
• []: Lista de valores con un elemento o más.

typeProfesor {nombre:String!cursos1: [String] //Listacursos2: [String]! //Listanopuedesernullcursos3: [String!] //Listapuedesernull, pero sus valores no pueden ser nullcursos4: [String!]! //Nilalistanilosvalorespuedensernull}

• Definiciones abstractas de atributos comunes.
• Útiles para retornar obhetos de diferentes tipos.
• Necesarias cuando buscamos acceder a cierto grupo de objetos que deben cumplir con las propiedades definidas por la interfaz.
• Abstraemos grupos de tipos sobre ellos como una entidad.

interfacePerfil {nombre:String!email:String!edad:Int!}typeAlumnoimplementsPerfil {nombre:String!email:String!edad:Int!curso:String}

• Son puntos de entrada.Sirven para comunicar al cliente con el servidor a través de ellos.
• Tipos
  • Query: Consulta (en REST => GET).
  • Mutation: Modificación (en REST => POST, PATCH, PUT, DELETE).
  • Subscription: Suscripción. Interacción de info en tiempo real.

• Punto de entrada para realizar las consultas.
• Similar a pedir un recurso en la API basada en REST.
• Tipo de consulta desde cliente a servidor.
• Escrito en lenguaje SDL para definir la consulta.
• Es el único tipo de raiz que es obligatorio.
• Es la única forma en que podemos obtener datos en GraphQL.

• Punto de entrada para realizar las operaciones de modificación.
• Equivalente en REST a POST, PUT, PATCH Y DELETE.
• Similar a una función.
• Es la única forma en que podemos modificar datos en GraphQL.

• Punto de entrada para obtener información en tiempo real.
• Utiliza la conexión mediante Web Sockets para obtener cambios.
• Notifica al que se suscribe y mantiene interacción en tiempo real.

• Elementos que permiten pasar valores a Queries/Mutations.
• Se pueden pasar valores simples (escalares) u objetos complejos.
• Se comporta como los argumentos ante cualquier operación.

• Podemos documentar nuestras APIs añadiendo comentarios en el schema.
• GrapQL admite markdown dentro del schema para comentarios.
• Tipos
  • Una línea: Comillas dobles.
  • Varias líneas: Triples comillas dobles.
• Facilita la generación de SDL.

Si realizamos dos consultas en paralelo sobre la misma instancia el resultado será una mezcla de ambas consultas.

Para poder realizar dos consultas en paralelo sobre la misma instancia con distintos argumentos, es necesario el uso de alias.

Es posible separar partes comunes a varias consultas mediante fragments, de forma que no repitamos código.

Es posible parametrizar argumentos utilizando query variables.

Estas directivas permiten incluir o excluir campos en una consulta de forma parametrizada.