可擴展性之路（如何管理前端服務。

簡介：正確管理前端服務的重要性

了解如何以可擴展和可讀的方式管理服務非常重要，不僅對於應用程式的效能，而且對於維護開發人員的健康和福祉。服務是應用程式中與外部通訊的部分，例如呼叫 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中文網其他相關文章！