Какой подход используешь для организации слоя доступа к данным?

Архитектура слоя доступа к данным в Frontend приложениях

В современных сложных фронтенд-приложениях организация слоя доступа к данным — это не просто выбор между fetch и axios. Это вопрос архитектуры, который напрямую влияет на устойчивость кода, тестируемость и гибкость при изменениях. После многих проектов я остановился на комбинации нескольких подходов, которые образуют строгий, но адаптивный паттерн.

Основные принципы и архитектурный паттерн

Я строю этот слой на базе принципа разделения ответственности, часто реализуя вариант Repository Pattern или Service Layer, адаптированный для фронтенда.

Ключевая идея: бизнес-логика компонентов не должна знать, как и откуда поступают данные. Компоненты делают запросы к абстрактным сервисам или репозиториям, которые сами управляют источником данных (API, локальное хранилище, моковые данные).

1. Абстрактный сервисный слой (Service Layer)

Это центральная точка. Сервисы — это классы или модули, которые предоставляют методы для конкретных бизнес-операций над данными (getUserProfile, createOrder, fetchProductList). Они скрывают внутри себя все детали HTTP-запросов, преобразования данных и обработки ошибок.

// Пример: UserService.ts
export class UserService {
  private apiClient: ApiClient; // Абстрактный клиент для HTTP

  async getUserById(id: string): Promise<User> {
    // Сервис знает конкретный endpoint, параметры, формат данных
    const response = await this.apiClient.get<UserResponse>(`/users/${id}`);
    // Сервис может трансформировать ответ API в доменный объект
    return this.mapResponseToUser(response.data);
  }

  async updateUserProfile(id: string, profile: ProfileUpdateDto): Promise<void> {
    await this.apiClient.put(`/users/${id}/profile`, profile);
  }

  private mapResponseToUser(response: UserResponse): User {
    // Концентрация логики преобразования данных здесь
    return {
      id: response.id,
      fullName: `${response.firstName} ${response.lastName}`,
      email: response.emailAddress,
      // ... другие преобразования
    };
  }
}

2. Абстрактный HTTP-клиент (ApiClient)

Сервисы не используют fetch или axios напрямую. Они работают через общий абстрактный клиент (ApiClient). Этот клиент централизует:

• Конфигурацию базового URL, заголовков (Authorization).
• Интерцепторы для логирования, инжекции токенов, обработки ошибок.
• Повторяющиеся паттерны (например, обработку разных статусов ответа).

// Пример: абстрактный ApiClient с использованием Axios (или fetch)
export class ApiClient {
  private axiosInstance;

  constructor(baseURL: string) {
    this.axiosInstance = axios.create({ baseURL });
    this.setupInterceptors();
  }

  async get<T>(url: string, config?: RequestConfig): Promise<ApiResponse<T>> {
    try {
      const response = await this.axiosInstance.get<T>(url, config);
      return { data: response.data, status: response.status };
    } catch (error) {
      // Централизованная обработка ошибок сети или API
      this.handleError(error);
      throw error; // или трансформированная бизнес-ошибка
    }
  }

  private setupInterceptors() {
    // Интерцептор для добавления JWT токена в каждый запрос
    this.axiosInstance.interceptors.request.use((config) => {
      const token = localStorage.getItem('authToken');
      if (token) {
        config.headers.Authorization = `Bearer ${token}`;
      }
      return config;
    });
  }

  private handleError(error: AxiosError) {
    // Логирование, показ уведомлений пользователю (через отдельный механизм)
    console.error('API Request failed:', error.message);
  }
}

3. Интеграция с состоянием приложения (State Management)

Сервисы часто не управляют состоянием напрямую. Они предоставляют данные, которые затем попадают в централизованное хранилище (например, Redux, Pinia, React Context + useReducer). Это создает четкое разделение:

• Сервисы — получение и отправка данных.
• Стор — хранение, реактивные обновления UI.

// Пример: действие в Redux slice, использующее UserService
const fetchUser = createAsyncThunk(
  'user/fetchById',
  async (userId: string, { rejectWithValue }) => {
    try {
      const userService = new UserService(); // или через dependency injection
      const user = await userService.getUserById(userId);
      return user;
    } catch (error) {
      return rejectWithValue(error.message);
    }
  }
);

4. Адаптивность и мокирование (Mocking для тестов и разработки)

Крайне важный аспект — возможность легко заменять источник данных. Благодаря абстракциям (ApiClient, UserService), я могу:

• Для разработки: создать MockApiClient, который возвращает фиктивные данные из .json файлов, чтобы не зависеть от бэкенда.
• Для тестов (Unit, Integration): мокировать весь сервис или клиент, чтобы тестировать бизнес-логику компонентов в isolation.

// Пример: моковый клиент для тестов Jest/Vitest
const mockApiClient = {
  get: jest.fn(() => Promise.resolve({ data: mockUserResponse })),
};

// В тесте мы инжектируем мок вместо реального сервиса
const userService = new UserService(mockApiClient);
await userService.getUserById('123');
expect(mockApiClient.get).toHaveBeenCalledWith('/users/123');

Преимущества такого подхода

• Чистая архитектура: Компоненты становятся «глупыми», они только потребляют данные из стора и вызывают методы сервисов. Это резко снижает сложность.
• Тестируемость: Сервисы и клиенты легко мокируются. Можно тестировать логику преобразования данных отдельно от UI и сети.
• Гибкость к изменениям API: Если бэкенд меняет формат ответа или endpoint, все изменения локализованы в одном месте — внутри соответствующего сервиса.
• Общее управление ошибками: Все ошибки сети, авторизации, 5xx/4xx обрабатываются централизовано в ApiClient. Можно легко подключить механизм показа тостов (toast.error) или логирования в Sentry.
• Подготовка к SSR (Next.js) и мобильным приложениям (React Native): Абстрактный слой данных легко адаптируется под разные среды выполнения, где, например, fetch может иметь особенности.

Заключение

Мой подход — это создание «буфера» между сырым API мира и бизнес-логикой приложения. Этот буфер, реализованный как слой сервисов + абстрактный клиент, служит для защиты, преобразования и управления данными. Он требует больше кода на старте, но огромно экономит время и снижает риски на протяжении всей жизни проекта, особенно при работе в больших командах и частых изменениях требований.