GraphQL vs API REST
HTML-код
- Опубликовано: 12 мар 2018
- Comparativa entre dos modelos para el desarrollo de API, como son REST, un modelo consolidado en la industria y GraphQL, una alternativa más nueva que se plantea como mejora y que viene a solucionar problemas tradicionales en el desarrollo de servicios web.
Veremos que las diferencias de GraphQL con respecto a REST son justamente las ventajas de GraphQL, ya que justamente esta tecnología surge para mejorar REST ahí donde se encuentran sus puntos más débiles.
Es una clase del curso de GraphQL escuela.it/cursos/curso-de-gr... de EscuelaIT. 
Наука
Un capo Wismichu!
Gracias Nico, super explicado. Ya no tengo dudas
Gracias a Desarrollo Web y a Nicolas por la explicación pudiendo aclarar un poco mas las dudas sobre estos conceptos.
esta buena la explicación, pero existen patrones de diseños...que pueden manejar los datos que responde la BD , osea si quiero de una entidad mostrar X datos solo los mapeo mediante un DTO y ya...
La restricciones de acceso al contenido de la BD como se manejan con GraphQL?
Se hacen de manera similar a como protegerías una API REST, generalmente usando la autenticación con usuario y clave, recibiendo el token de autenticación, que usas en las siguientes solicitudes para asegurar que la solicitud la hace un usuario con ciertos permisos.
me refiero a la restriccion de cierto contenido dentro del sistema, es posible realizar algún tipo de validación antes de que la petición acceda a los datos y los envíe?
Claro que sí, las validaciones o autorizaciones las puedes hacer antes de enviar la respuesta.
Gracias por el video, es muy buena explicación introductoria de GraphQL. ME pudieras decir por favor qué software usas para grabar tus videos?
pero no es un cambio de paradigma es solo una optimizan. el cliente solo puede moverse en el universo que le permite el back. hay q construir igual todo lo q se entrega. me parece muy bien eso de que puedes elegir q información necesito recibir. me gusta mucho el enfoque de graphQL. pero he vistos muchos explican como q el back no hace nada de lo q se hace en API y practicamente se tiene q hacer lo mismo. claro tengo q meterme mucho mas para en graphQL y espero ya el crecimiento.
Eso de la sobre carga de datos en un api rest, siento que no va, ya que solo puedes y debes poner los datos que ocupas, para que requieres otros datos que vas a usar, bueno al menos yo cuando hago apis solo regreso la data que requiero, es muy tonto poder data de mas
Si tienes una aplicación con 20 roles diferentes: Admin, Vendedor, Cajero, etc. Y tienes una entidad productos con 20 campos, cada perfil necesita ver los campos específicos de acuerdo a la labor que realizan, deberías colocar 20 condiciones dentro de ese Endpoint para no enviar data de más que es mucho código. Otro ejemplo si tienes una aplicación más avanzada que te permite crear campos nuevos desde el cliente y también manipularlos es decir ocultarlos con solo arrastrarlos a la sección de ocultos como (Salesforce, Sap, Dynamics) con esta tecnología armas el query de solo los campos visibles y los otros 50 campos que tienes ocultos no vendrán, cosa que sería más complicado de manejar con Rest aunque no sea imposible. Saludos
@@wilfredobc8611 Pero no sería contraproducente dejar del lado del cliente la decisión de selección de datos?, El cliente no debería conocer mucho de la lógica del negocio a mi parecer. Si la invocación del api graphql es desde javascript esto no daría pie a que alguien experto pueda consultar información no autorizada sabiendo únicamente cómo utilizar los querys ?
@ Tienes toda la razón, seria ideal en caso de que la data oculta en el query no sea sensible, sino que sea una data que a ese perfil no le interesa ver ya que no sirve para su trabajo o por espacio de la pantalla para un celular. Para el caso de la data sensible entiendo que graphql debe tener un manejo de roles, digo entiendo ya que mi experiencia hasta ahora ha sido trabajando con Rest más no con esta tecnología que es nueva para mi, pero muy bueno tu punto. Saludos!
Otro ejemplo aparte de los que han mencionado, es que por ejemplo las fotos o archivos similares que sean pesados sobrecargan una peticion (ya que se envian todos los datos y ademas las fotos o archivos)y eso hace caer la aplicacion o que salga algun error...en Rest habria que hacer un endpoint exclusivo para las imagenes mientras en GraphQL no haria falta ese nuevo endpoint
con lo que comprendí graphQL, el cliente es el que decide que datos quiere, pero tengo dudas GraphQL no sería lo mismo cuando utilizo angular con el método Map para filtar algunos datos ya que lo hago en el cliente, espero su respuesta, saludos.
Hola Alexander.
Para entender una de las ventajas de usar GraphQL en el caso que tu mencionas puedes ponerte en los zapatos de un usuario de tu aplicación el cual cuenta con un dispositivo móvil el cual podría tener una conexión lenta o de datos limitados.
Al usar GraphQL, tu diseñas las consultas a tu API a la medida de tu aplicación. Es decir, devuelves al usuario una respuesta del servidor la cual contiene *unicamente la información que el usuario necesita Y NADA MÁS*.
Al tu hacer esta transformación a la medida desde Angular, estás hablando de que obligas al usuario a descargar el contenido de la respuesta del servidor la cual contiene información que vas a terminar filtrando manualmente con el operador map. Aunque finalmente el usuario no ve está información porque tu la has filtrado, si la tuvo que descargar de igual forma. Esto se evita haciendo uso de GraphQL.
@@danielalexis2141 Muchas gracias por la duda, ahora sí me quedo muy claro el tema de GraphQL, saludos.
en REST si se pueden mostrar y ocultar datos, relaciones o datos embebidos, paginacion, etc.
Por supuesto que se puede, pero no lo decide generalmente el cliente, de manera arbitraria por medio de la consulta, sino que suele ser una decisión de quienes programan el backend
hay algo como oauth para graphql, se pudede restringir que se muestra (entidades)?
Alexandro Bazán Lo más parecido son las custom directives, algo así como hooks.
Imagino que es muy útil si tienes una sola base de datos corriendo un tu Raspberry, la neta no me convence, en especial porque no se mencionó en lo absoluto cómo se implementa.
voy en el minuto 35 y lo que manejas como un pro para grahpgl también es una contra, tener todo en una sola solcitud, si se cae el o falla el endpoint no muestras nada, o si tarda mucho descargar toda la información, yo podría manejar los datos de una persona en un endpoint y la fotografia en otro endpoint, si falla la fotografia como quiera funciona a la api, en el caso graphql no es asi
Ok, en ese caso podría ser una desventaja, sí, aunque si la app tiene un endpoint roto la experiencia de usuario se vería mermada en todo caso. ¿no?
rekes, odio al ingles en su maxima expresion
jajaja