확장성을 향한 길(프런트엔드에서 서비스를 관리하는 방법.

소개: 프론트엔드에서 올바른 서비스 관리의 중요성

확장 가능하고 읽기 쉬운 방식으로 서비스를 관리하는 방법을 아는 것은 애플리케이션 성능뿐만 아니라 개발자의 건강과 복지를 유지하는 데에도 매우 중요합니다. 서비스는 API 호출, 데이터베이스와의 상호 작용, 연락처 액세스와 같은 전화 권한 관리 등 외부와 통신하는 애플리케이션의 일부입니다. 이러한 서비스를 잘 관리하면 애플리케이션을 확장할 수 있고 향후 문제를 일으키지 않을 것입니다.

이 글에서는 저장소 패턴을 사용하여 확장 가능한 방식으로 프런트엔드 서비스를 관리하는 방법을 살펴보겠습니다. 이 접근 방식을 사용하면 제어되고 명확한 방식으로 서비스에 액세스할 수 있으며, API 호출을 캡슐화하고 코드 재사용 및 유지 관리가 용이해집니다.

이 기사 전체에서는 이 솔루션을 구현하는 방법, 따라야 할 모범 사례, 코드 확장성과 유지 관리 용이성을 보장하는 데 어떻게 도움이 되는지 살펴보겠습니다.

서비스 관리의 기본 개념: DTO 및 어댑터

잘 구성된 아키텍처에서는 애플리케이션의 다양한 계층이 어떻게 구성되어 있는지 이해하는 것이 중요합니다. 기본 레이어 중 하나는 외부와 상호 작용하는 서비스를 관리하는 인프라 레이어입니다.

이 인프라 계층 내에서 자주 나타나는 두 가지 주요 개념은 DTO(데이터 전송 개체)와 어댑터입니다.

• DTO(데이터 전송 개체): DTO는 API 또는 데이터베이스의 응답에서 데이터를 나타내는 인터페이스입니다. 이는 외부 서비스로부터 받은 정보가 애플리케이션이 쉽게 처리할 수 있는 특정 형식을 준수하는지 확인하는 역할을 합니다. 예를 들어 DTO는 API에서 수신하는 사용자 개체의 구조를 정의할 수 있습니다.

• 어댑터: 어댑터는 DTO에서 애플리케이션 도메인 인터페이스로 또는 그 반대로 데이터를 변환하는 기능을 담당합니다. 즉, 우리가 받은 데이터를 번역하거나 우리가 보내는 데이터를 번역할 수 있습니다. 이렇게 하면 나중에 수신하는 정보가 변경되면 애플리케이션 전체가 아닌 어댑터에만 집중하면 됩니다.

DTO 및 어댑터를 사용하면 인프라 계층이 애플리케이션 로직에 영향을 주지 않고 외부 서비스의 변경 사항에 유연하고 쉽게 적응할 수 있습니다. 또한 계층 간의 명확한 분리를 유지하고 각 계층이 특정 책임을 수행합니다.

수신되는 데이터의 예:

// getUserProfile.adapter.ts

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

export deafult userProfileAdapter;

우리가 보내는 데이터의 예:

저장소 패턴
리포지토리 패턴은 데이터 액세스 로직을 애플리케이션이나 비즈니스 로직과 분리한다는 아이디어를 기반으로 합니다. 이는 엔터티가 애플리케이션에 있는 메서드를 중앙 집중화되고 캡슐화된 방식으로 가질 수 있는 방법을 제공합니다.

처음에는 이 엔터티가 갖게 될 메소드 정의를 사용하여 저장소의 인터페이스를 만들어야 합니다.

// UserProfileRepository.model.ts

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

그리고 우리는 저장소 생성을 계속합니다.

// 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;
          }
     }
  }
}

이 접근 방식을 사용하면 API 호출을 캡슐화하고 DTO 형식으로 수신한 데이터를 어댑터를 통해 내부 형식으로 변환할 수 있습니다.

아래에서는 인프라 계층에 서비스, DTO 및 어댑터가 포함된 아키텍처 또는 구조의 다이어그램이 표시됩니다. 이 구조를 통해 비즈니스 로직과 외부 데이터를 명확하게 구분할 수 있습니다.

오류 처리
오류 핸들러를 생성하면 코드를 더욱 개선할 수 있습니다.

// 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!

위 내용은 확장성을 향한 길(프런트엔드에서 서비스를 관리하는 방법.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!