¿Qué hace diferente a Apollo Client?
Contenido del curso
¿Qué hace diferente a Apollo Client?
Contenido del curso
Andrés Esteban Rodríguez Jiménez
Chris X
Leiwis Bernal
Jair Neri
Daniel Felipe Merchan Fuquen
Jonathan 🦑 Alvarez
Profesor
Francisco Ponce
Jonathan 🦑 Alvarez
Profesor
Andrew Duran
David Prado
Diego Reyes Cabrera
Giancarlo Culcay
¿Qué hace diferente a Apollo Client?
EL cliente de apollo nos permite tener un soporte relativamente sencillo a lao hora de hacer cache de los datos de una consulta a diferencia que con otras librerías, que a pesar de que se puede hacer, es muy difícil de hacer.
Si volvemos al **_app.tsx**, y vamos al cliente que hemos creado, veremos que podemos configurar nuestra instancia de **InMemoryCache** y enviar una serie de configuraciones:
const client = new ApolloClient({ // ... cache: new InMemoryCache({ typePolicies: { Query: { // en este campo de acá, podemos configurar que tipo de consultas guardamos en caché fields: { // en este caso, será un producto product: { read(_, { args, toReference }) { // retornamos la referencia a este producto return toReference({ // para obtener un producto en el caché __typename: 'Product', // lo hacemos en base a un argumento id, que será como lo encontremos id: args?.id, }) } } } } } }), })
Con esto podemos tener una configuración inicial que nos va a permitir ejecutar consultas en caché, sin tener que realizar consultas innecesarias.
La combinación de graphql y react query puede ser un poco ambiguo, como bien dice Jonathan react query esta pensado para soluciones mas genericas de REST.
Quizas seria util armar custom hooks para remplazarlo, y quedarse solo con Apollo.
Entonces recomiendas usar GraphQL con Apollo client en lugar de react-query?
la integracion es mas rapida por su enfoque nato en GraphQl. En caso de que necesites el otro, solo necesitarias configuraciones extra acorde a la doc.
Si trabajar con el cache es la segunda cosa más difícil en ingeniería, ¿qué ocupa el primer lugar?
Nombrar variables correctamente 😄
Tenía entendido que toda configuración al caché que maneje Apollo tiene costos importantes, ¿Alguien ha tenido que lidiar con estos costos en específicos, si recomiendan en configurar mucho el cliente de Apollo para el manejo del caché?
También me encantaría leer más experiencias de otros estudiantes 😄
Si alguno está usando Next.js 15, por acá yo consideré lo siguiente:
Al estar trabajando con server components, yo decidí aislar las consultas de graphql a través de unas apis hechas con el mismo Next.js; para consultar dichas apis, seguí usando Axios.
Dejo por acá tanto la instancia Axios, como el cliente Apollo que use en las apis:
// app/utils/axios.ts import axios from "axios"; // NEXT_PUBLIC_API_URL viene del .env.local recuerda declararlo const clientAxios = axios.create({ baseURL: process.env.NEXT_PUBLIC_API_URL, headers: { "Content-Type": "application/json", }, }); export { clientAxios }; ``````js // app/utils/apolloServer.ts import { ApolloClient, InMemoryCache } from "@apollo/client"; //PLATZI_GRAPHQL_URL = https://api.escuelajs.co function createApolloClient() { return new ApolloClient({ uri: `${process.env.PLATZI_GRAPHQL_URL}/graphql`, cache: new InMemoryCache({ typePolicies: { Query: { // en este campo de acá, podemos configurar que tipo de consultas guardamos en caché fields: { // en este caso, será un producto product: { read(_, { args, toReference }) { // retornamos la referencia a este producto return toReference({ // para obtener un producto en el caché __typename: "Product", // lo hacemos en base a un argumento id, que será como lo encontremos id: args?.id, }); }, }, }, }, }, }), }); } export { createApolloClient }; ```Hay que crear un cliente aparte del provider, ya que las apis están en el servidor y no entra en el contexto del provider.
En lugar de utilizar la memoria en cache, creen que seria mejor utilizar getStaticProps o combinarlo con getStaticPaths de Next.js para tenerlo en memoria?.
Claro, ya siendo paginas estaticas no se hace ningun otro request por parte del usuario. Pero creo que esta utilidad funciona de parte del servidor, en el build time. Para una pagina con ISR o que hace builds frecuentemente, en build time haría requests quizás innecesarios. . Y bueno, siendo ese el caso de páginas estaticas. Pero también existen las dinamicas, y esto no aplicaría. Por ejemplo, Facebook fue quien creó GraphQL por necesidad, y ellos son bastante dinamicos en sus apps.
Genial siempre me preguntaba cómo hacer esas consultas más optimas a nivel de cache.
