Camino hacia la escalabilidad (1): Cómo Gestionar Servicios en Frontend.

Introducción: La importancia del correcto manejo de los servicios en Frontend

Saber manejar los servicios de manera de escalable y legible es muy importante, no solo para el rendimiento de la aplicación, sino también para mantener la salud y el bienestar de los desarrolladores. Los servicios son la parte de la aplicación que se comunica con el exterior, como llamadas a APIs, interacción con bases de datos, o incluso la gestión de permisos del teléfono, como el acceso a los contactos. Una buena gestión de estos servicios asegura que tu aplicación pueda ser escalable y no traiga dolores de cabeza en el futuro.

En este artículo, vamos a explorar cómo gestionar los servicios en frontend de forma escalable utilizando el patrón respository. Este enfoque permite el acceso a los servicios de manera controlada y clara, encapsulando las llamadas a las APIs y facilitando la reutilización del código, así como su mantenibilidad.

A lo largo de éste artículo, veremos cómo implementar esta solución, las buenas prácticas a seguir y cómo puede ayudarte a asegurar que tu código sea escalable y fácil de mantener.

Conceptos Fundamentales para Gestionar Servicios: DTOs y Adaptadores

En una arquitectura bien organizada, es importante entender cómo se estructuran las distintas capas de una aplicación. Una de las capas fundamentales es la capa de infraestructura, que es donde se gestionan los servicios que interactúan con el exterior.

Dentro de esta capa de infraestructura, dos conceptos clave que suelen aparecer son los DTO (Data Transfer Objects) y los adaptadores.

• DTO (Data Transfer Object): Los DTOs son interfaces que representan los datos en las respuestas de las APIs o bases de datos. Sirven para asegura que la información que recibimos de los servicios externos se ajuste a un formato específico que nuestra aplicación pueda manejar fácilmente. Por ejemplo, un DTO podría definir la estructura de un objeto de usuario que recibimos de una API.

• Adaptadores: Los adaptadores son funciones responsables de traducir los datos de los DTOs a las interfaces de dominio de la aplicación, o viceversa. Es decir, pueden ser para traducir la data que recibimos o para traducir la data que enviamos. De esta manera, si en un futuro la información que recibimos cambia, solo deberemos focalizarnos en el adapter, y no a lo largo de la aplicación.

La utilización de DTOs y adaptadores permite que la capa de infraestructura sea flexible y fácilmente adaptable a cambios en los servicios externos sin afectar la lógica de la aplicación. Además, mantiene una separación clara entre las capas y que cada una cumple con sus responsabilidades específicas.

Ejemplo de data que recibimos:

// getUserProfile.adapter.ts

const userProfileAdapter = (data: UserProfileDto): UserProfile => ({
    username: data.user_username,
    profilePicture: data.profile_picture,
    about: data.user_about_me,
})

export deafult userProfileAdapter;

Ejemplo de data que enviamos:

El Patrón Repository
El patrón repository está basado en la idea de tener la lógica de tu acceso a datos separado de tu aplicación o lógica de negocio. Este provee una forma de tener de manera centralizada y encapsulada los métodos que posea una entidad en tu aplicación.

Inicialmente deberemos crear la interfaz de nuestro repositorio con la definción de los métodos que contará esta entidad.

// UserProfileRepository.model.ts

export interface IUserProfileRepository {
   getUserProfile: (id: string) => Promise<UserProfile>;
   createUserProfile: (payload: UserProfile) => Promise<void>;
}

Y continuamos con la creación de nuestro repositorio.

// userProfile.repository.ts

export default function userProfileRepository(): IUserProfileRepository {
  const url = `${BASE_URL}/profile`;

  return {
     getUserProfile: getProfileById(id: string) {
          try {
            const res = await axios.get<UserProfileDto>(`${url}/${id}`);             
            return userProfileAdapter (userDto);
          } catch(error){
            throw error;
          }           
     },
     createUserProfile: create(payload: UserProfile) {
          try {
            const body = createUserProfilAdapter(payload);
            await axios.post(`${url}/create`, payload);
          } catch(error) {
            throw error;
          }
     }
  }
}

Este enfoque nos permite encapsular las llamadas a la API y realizar la conversión de los datos que recibimos en el formato de los DTOs a nuestro formato interno a través del adaptador.

A continuación verás un diagrama de la arquitectura o estructura que seguimos, donde la capa de infraestructura incluye los servicios, DTOs y adaptadores. Esta estructura nos permite tener una separación clara entre la lógica de negocio y los datos externos.

Manejo de errores
Podemos mejorar aún mas nuestro código creando un manejador de errores.

// errorHandler.ts

export function errorHandler(error: unknown): void {
  if (axios.isAxiosError(error)) {
    if (error.response) {
      throw Error(`Error: ${error.response.status} - ${error.response.data}`);
    } else if (error.request) {
     throw Error("Error: No response received from server");
    } else {
      throw Error(`Error: ${error.message}`);
    }
  } else {
    throw Error("Error: An unexpected error occurred");
  }
}

// userProfile.repository.ts

import { errorHandler } from './errorHandler';

export default function userProfileRepository(): IUserProfileRepository {
  const url = `${BASE_URL}/profile`;

  return {
    async getUserProfile(id: string) {
      try {
        const res = await axios.get<UserProfileDto>(`${url}/${id}`);
        return userProfileAdapter(res.data);
      } catch (error) {
        errorHandler(error);
      }
    },
    async createUserProfile(payload: UserProfile) {
      try {
        const body = createUserProfileAdapter(payload);
        await axios.post(`${url}/create`, body);
      } catch (error) {
        errorHandler(error);
      }
    }
  }
}

Esto nos permite desacoplar la lógica de presentación de la lógica de negocio, asegurando que la capa de UI solo se encargue de manejar las respuestas y actualizar el estado de la aplicación.


Implementación de los servicios
Una vez que hemos encapsulado la lógica de acceso a datos dentro de nuestro repositorio, el siguiente paso es integrarlo con la interfaz de usuario (UI).

Es importante mencionar que no hay una única forma de implementar el patrón Repository. La elección de la implementación dependerá mucho de la arquitectura de tu aplicación y de qué tan fiel quieras a las definiciones de la misma. En mi experiencia, una de las formas más útiles y prácticas de integrarlo ha sido mediante el uso de hooks, el cual desarrollaremos a continuación.

export function useGetUserProfile(id: string) {
  const [data, setData] = useState<UserProfile | null>(null);
  const [loading, setLoading] = useState<boolean>(true);
  const [error, setError] = useState<string | null>(null);
  const repository = userProfileRepository();

  useEffect(() => {
    const fetchData = async () => {
      setLoading(true);
      try {
        const userProfile = await repository.getUserProfile(id);
        setData(userProfile);
      } catch (err) {
        setError((err as Error).message);
      } finally {
        setLoading(false);
      }
    };

    fetchData();
  }, [id]);

  return { data, loading, error };
}

interface UserProfileProps {
  id: string;
}

export function UserProfile({ id }: UserProfileProps) {
  const { data, loading, error } = useUserProfile(id);

  if (loading) return <Skeleton />;
  if (error) {
      toast({
        variant: "destructive",
        title: "Uh oh! Something went wrong.",
        description: error, 
      });
  }


  return (
    <div>
      <h1>{data?.username}</h1>
      <img src={data?.profilePicture} alt={`${data?.username}'s profile`} />
      <p>{data?.about}</p>
    </div>
  );
}

Ahora, el componente UserProfile no necesita saber nada sobre cómo se obtienen los datos del perfil, solo se encarga de mostrar los resultados o mensajes de error.

Esto se puede mejorar aún más si las necesidades lo requieren, por ejemplo con la utilizacion de react query dentro del hook para tener un mayor control sobre el cacheo y actualización de datos.

export function useGetUserProfile(id: string) {
  const repository = userProfileRepository();

  return useQuery({
    queryKey: ['userProfile', id], 
    queryFn: () => repository.getUserProfile(id), 
  });
 }

Conclusión

En este artículo, hemos explorado cómo implementar el patrón Repository en frontend, encapsulando las llamadas a las APIs y manteniendo una separación clara de responsabilidades mediante el uso de DTOs y adaptadores. Este enfoque no solo mejora la escalabilidad y el mantenimiento del código, sino que también facilita la actualización de la lógica de negocio sin tener que preocuparse por los detalles de la comunicación con los servicios externos. Además, al integrar React Query, obtenemos una capa extra de eficiencia en la gestión de datos, como el cacheo y la actualización automática.

Recuerda que no existe una manera única del manejo de servicios (por ejemplo también existe el patrón sagas para el manejo de side-effects). Lo importante es aplicar las buenas prácticas para asegurarnos de que nuestro código siga siendo flexible, limpio y fácil de mantener en el tiempo.

Espero que esta guía te haya sido útil para mejorar la manera en la que gestionas los servicios en tus proyectos frontend. Si te ha gustado, no dudes en dejar un comentario, darle me gusta o compartir el artículo para que más desarrolladores puedan beneficiarse. ¡Gracias por leer!