Hola Lucas, muy buena introducción además creo que es lo que más se usa de esta librería ya que normalmente son casos de uso muy típicos. Yo también la he empezado a usar en una app que tengo y la verdad es que es una maravilla, porque no solo te ahorra código si no añade una estructura y forma de hacer las llamadas y como tampoco tiene muchas formas distintas de hacerlas, al final la consistencia es brutal. En mi caso tengo un servicio por cada feature digamos y estoy pensando en quitarlos y hacer la llamada directamente desde la query, lo que supondría también hacer alguna lógica dentro de la query, pero es que los servicios que tengo casi todos tienen nada más que la llamada al típico servicio api que gestiona los errores, success etc.... Qué opinas al respecto?
👋Hola Olek!
Pues la verdad es que no hay ningún problema en hacer la query directamente. Creo que el meterlo o no, dependerá de esa encapsulación que comentas a la hora de hacer la request. Hacer un wrap en un "servicio" de un fetch concreto + un parseo por defecto puede aumentar la mantenibilidad a futuro (imagina que en un futuro quieres agregar una cabecera, cambiar el parseo por defecto porque Backend devuelve ahora los datos encapsulados, etc).
En principio si tienes un servicio ya funcionando, la idea que implica menos esfuerzo sería simplemente utilizar esas funciones dentro de las queries/mutaciones. Además, si el día de mañana quieres utilizar una solución diferente, sigues teniendo tu servicio funcionando.
Espero que te ayude.
Un saludo!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hola Lucas, muy buena introducción además creo que es lo que más se usa de esta librería ya que normalmente son casos de uso muy típicos. Yo también la he empezado a usar en una app que tengo y la verdad es que es una maravilla, porque no solo te ahorra código si no añade una estructura y forma de hacer las llamadas y como tampoco tiene muchas formas distintas de hacerlas, al final la consistencia es brutal. En mi caso tengo un servicio por cada feature digamos y estoy pensando en quitarlos y hacer la llamada directamente desde la query, lo que supondría también hacer alguna lógica dentro de la query, pero es que los servicios que tengo casi todos tienen nada más que la llamada al típico servicio api que gestiona los errores, success etc.... Qué opinas al respecto?
👋Hola Olek!
Pues la verdad es que no hay ningún problema en hacer la query directamente. Creo que el meterlo o no, dependerá de esa encapsulación que comentas a la hora de hacer la request. Hacer un wrap en un "servicio" de un fetch concreto + un parseo por defecto puede aumentar la mantenibilidad a futuro (imagina que en un futuro quieres agregar una cabecera, cambiar el parseo por defecto porque Backend devuelve ahora los datos encapsulados, etc).
En principio si tienes un servicio ya funcionando, la idea que implica menos esfuerzo sería simplemente utilizar esas funciones dentro de las queries/mutaciones. Además, si el día de mañana quieres utilizar una solución diferente, sigues teniendo tu servicio funcionando.
Espero que te ayude.
Un saludo!