Interfaces - Tipo Monitor

Clase 18 de 25 • Curso Práctico de GraphQL con JavaScript

Resumen

Las interfaces son muy importantes y útiles cuando nos encontramos con tipos de datos similares. Una interfaz nos permite definir un tipo de dato padre que utilizando la palabra implements va a implementar los campos que tenga definidos dentro del tipo de dato que queramos.

Iván Darío Sánchez Jiménez

student•

Les recomiendo esta lectura para comprender mejor todo el potencial de las interfaces

Interfaces in GraphQL

Carlos Enrique Ramírez Flores

student•

Excelente! muchas gracias!

Cesar David Ramírez Dimaté

student•

También puedes visualizarlo en la documentación oficial.

Jecsham Castillo

student•

A pesar de haber implementado la interface, los campos deben seguir escritos en los types.

Cesar David Ramírez Dimaté

student•

Así es. Los campos definidos en la interfaz deben también estar definidos en las implementaciones (types), sino, se mostrará el error "Interface field Person.email expected but Student does not provide it."

jean pierre gabriel nieto acosta

student•

soy yo o esto se parece a little bit a typescript

Iraida Mercedes Barreto Díaz

student•

Que bien, funcionó. Implementé estas dos en mi proyecto.

interface Provider {
    _id: ID!
    title : String!
    country : String
}

type Company implements Provider {
    _id: ID!
    title : String!
    country : String
    logo: String
}

type Organization implements Provider {
    _id: ID!
    title : String!
    country : String
    webpage: String
}

!interfaces

Javier Fuentes Mora

teacher•

Aqui algo que le falto decir es que __resolveType es parte de graphQL no es algo que este el definiendo como en Course con people , aqui este ejemplo donde se entiende de una mejor manera https://www.apollographql.com/docs/apollo-server/schema/unions-interfaces/

Daniel Alberto Esquinazi

student•

Para consultar se puede hacer un fragment de una interface. No estoy seguro si es muy útil pero es posible.

fragment Person on Person{
	... on Student {
      avatar
    }
    ... on Monitor {
      phone
    }
}

query getPeople{
  getPeople {
    _id
    name
    email
    ...Person
  }
}

Cesar David Ramírez Dimaté

student•

No lo creo útil pero funciona jejeje

{
  people {
    ...personFields
    ...addFields
  }
}

fragment personFields on Person {
  _id
  name
  email
}

fragment addFields on Person {
  ... on Teacher {
    phone
  }
  ... on Student {
    avatar
  }
}

Carlos S. Aldazosa

student•

Creo que esta clase hubiera sido mas clara agregando un campo "role" con un enum que contenfa estudiante y monitor. A mi parecer es un ejemplo mas practico del trabajo comun, pero no se. Ustedes que opinan?

Miguel de la Rosa

student•

Me confundi, si el estudiante y monitor esta heredando los campos de persona? entonces para que se vuelven a repetir los campos. No deberia quedar asi?

interface Person {
  _id: ID!
  name: String!
  email: String!
}

type Student implements Person {
  avatar: String
}```

Luis Lira

student•

Hola!

Esto se debe a que con GraphQL no hay herencia, lo que está haciendo es implementar interface. Una interface solamente se encarga de generar un "contrato" que te obliga a que escribir esas propiedades dentro de los tipos que la implementen.

Miguel de la Rosa

student•

Ah ya, es como una interfaz de typescript. Gracias por tu comentario

Nery Alberto Cano Ortigoza

student•

¡Les facilito aquí la documentación para que puedan leer un poco más afondo sobre las interfaces!, siempre es bueno repasar la info desde distintas perspectivas ya que esto refuerzan en gran medida lo que estas aprendiendo!

jorge llanque

student•

A pesar de haber implementado la interface, los campos deben seguir escritos en los types.

Cesar David Ramírez Dimaté

student•

Así es. Los campos definidos en la interfaz deben también estar definidos en las implementaciones (types), sino, se mostrará el error “Interface field Person.email expected but Student does not provide it.”

José Antonio Sánchez Aguilar

student•

Si hago esto para conseguir solo los monitores me devuelve un array donde el primer elemento es un objeto vacío ¿por que?

Query

{
  getPersons {
    ... on Monitor {
      _id
    	name
    	email
      phone
    }
  }
}

Respuesta

{
  "data": {
    "getPeople": [
      {},
      {
        "_id": "62080cfff5500b8ff19d330f",
        "name": "Jiron",
        "email": "boko",
        "phone": "2342314"
      }
    ]
  }
}

Jorge Iván Otero Vargas

student•

Porque ese otro registro existe pero no tiene la propiedad "phone", tu estás usando los campos a mostrar dentro del fragment.

Alejandro González Reyes

student•

Si quiero recuperar solo los Monitores, como se haria la consulta

Jhon Manuel Angulo Moncada

student•

Hola, esta seria una forma de hacerlo:

{
  getPersons {
    ... on Monitor {
      _id
    	name
    	email
      phone
    }
  }
}

Nery Alberto Cano Ortigoza

student•

genial el aporte de jhon, tambien hay que tomar en cuenta que el primer elemento viene vacio.

Miguel Angel Reyes Moreno

student•

¿Qué es un monitor? 😅 Solamente puedo imaginarme una pantalla de computadora.

Alex Paul Chirino Caicedo

student•

Jajaja monitor hace referencia a una persona que supervisa o está a cargo en uno o varios estudiantes

Miguel Angel Reyes Moreno

student•

Me puse a pensar en eso 5 minutos después de haber hecho mi pregunta. Gracias por contestarla :)

Katherin Moscoso

student•

Se guardan todos los elementos Students y Monitor en la misma colección, esto es correcto? o igual habría que cambiarle el nombre a la colección por People

Nery Alberto Cano Ortigoza

student•

De hecho, si, deben estar en la misma colección, en diseño de bases de datos se conoce este comportamiento como herencia, ya que tanto estudiante como monitor son primeramente personas, pero con una pequeña particularidad que los diferencia, en este caso phone o avatar. De lo contrario estarías guardando la misma información en múltiples colecciones y perderías la posibilidad por ejemplo que un estudiante sea también un monitor, al menos sin tener que escribir la información repetida en dos colecciones, provocando redundancia y la perdida de conexión entre ambas al tener al final ids distintos. Por si mi explicación no es muy clara, te dejo aquí un artículo que lo explica más a detalle y una pequeña imagen ilustrativa.

Cesar David Ramírez Dimaté

student•

La verdad yo le cambié el nombre de la colección. No tiene sentido que se siga llamando students cuando ahora son people. En mongodb se hace de la siguiente forma:

db.students.renameCollection("people", false)

Con respecto a la gráfica no hay que crear otra colección para diferenciar entre estudiantes y monitores. Se hace en la misma y por eso se añaden campos adicionales, que diferencien, cuál es cual (por lo menos en este caso).

Rafael Molina

student•

no hubiera sido buena idea comenzar a crear todo el sistema con person en vez de students? llegado a este punto, al menos en mi caso que he estado generando tipos en typescript voy a tener que cambiar los students a person en todo el proyecto

Luis Felipe Carrasco Galindo

student•

y como lo hago cuando quiero obtener solo estudiantes o monitor? crear una función que solo llame a Student?

Cesar David Ramírez Dimaté

student•

Claramente tendrías que hacer un resolver que filtre por algún criterio si un Person es un Student o Monitor. Acá sólo se hizo de manera general con Person con __resolveType

leonardo Oteca

student•

No me queda muy claro al final que hace __resolveType

Leo Islas

student•

te recomiendo que cheques un poquito de herencia en programación orientada a objetos ya que lo que se hacia primero era retornar el Student al momento de que Person es el objeto base es el que se retorna pero los campos agregados que son phone y avatar es lo que usa para elegir entre un objeto u otro lo que quiere decir es que no retornas ya Student ni Monitor si no Person extendido de Student o Monitor con sus campos agregados

espero no confundirte mas te recomiendo que cheques un poquito de herencia y sobre escritura

saludos

Nery Alberto Cano Ortigoza

student•

Es una pequeña función que le dará a entender al código con que está trabajando si es un estudiante o es un monitor.

Francisco Garcia [C6]

student•

Muy bueno :-)

Creación de Persona

mutation createNewMonitor($monitorinput: PersonInput!){
  createPerson(input: $monitorinput){
    _id
    name
  }
}

Query Variables

{
	"monitorinput": {
		"name": "Monitor 1",
    "email": "monitor1@gmail.com",
    "phone": "1234567"
  }
}

getPeople

{
  getPeople {
    _id
    name
    email
    ... on Monitor {
      phone
    }
  }
}

Jorge Méndez Ortega

student•

no entiendo por qué genero una interfaces y en Students y Monitor al haver el implements de la interface tenggo que repetir los campos de nuevo

Cesar Eliezer Gomez Gutierrez

student•

¿Habría colisiones a la hora de usar la sintaxis "interface ___ { ... }" si uso Typescript con GraphQL? Ya que ambas usan la misma sintaxis para casi lo mismo

interface Provider {
    _id: ID!
    title : String!
    country : String
}

type Company implements Provider {
    _id: ID!
    title : String!
    country : String
    logo: String
}

type Organization implements Provider {
    _id: ID!
    title : String!
    country : String
    webpage: String
}

{
  people {
    ...personFields
    ...addFields
  }
}

fragment personFields on Person {
  _id
  name
  email
}

fragment addFields on Person {
  ... on Teacher {
    phone
  }
  ... on Student {
    avatar
  }
}

Interfaces - Tipo Monitor

Introducción

Introducción al curso y prerequisitos del curso

¿Qué es GraphQL?

Conceptos básicos

Schema y types

Queries y Resolvers

Sirviendo el API en la web

Custom Types

Argumentos

Configuración de base de datos

Integrando una base de datos

Mutations e Inputs

Repaso - Creando el tipo Estudiante

Nested Types

Resolver de tipos

Errores

Conceptos avanzados

Alias y fragments

Variables

Enums

Interfaces - Tipo Monitor

Directivas

Unions

Consumiendo el API

Preparando API para producción

HTTP requests

Clientes de GraphQL

Consumiendo el API desde un frontend simple

Cierre del curso