Clean API Client

The main rule of reliable architecture: the request layer must be an independent module. It should know nothing about components, pages, or UI frameworks.

The Problem: Chaos in Components

When requests are made directly inside components, the project quickly accumulates technical debt. You will inevitably face the following issues:

• Duplication: the same endpoint is called in several different files.
• Inconsistency: different error handling and header settings everywhere.
• Refactoring Pain: when the API changes, you have to rewrite half of the UI components.
• Reusability Difficulty: the logic cannot be moved to another project.

I avoid this using a simple and flat structure that strictly separates transport, domains, and the entry point.

Request Layer Architecture

Basic Directory Structure

import * as products from "@/services/requests/products/index"
import * as users from "@/services/requests/users/index"

export const ApiClient = {
  products,
  users
}

Each element of this structure solves exactly one task:

Request Layer (Transport)

Inside request.ts lies a universal wrapper that constructs URLs with query parameters, sets timeouts, and parses responses.

Implementation example:

export const request = {
  get: <T>(url: string, options?: Omit<ApiRequestOptions, "method">) =>
    apiRequest<T>(url, { ...options, method: "GET" }),

  post: <T>(url: string, body?: unknown, options?: Omit<ApiRequestOptions, "method" | "body">) =>
    apiRequest<T>(url, { ...options, method: "POST", body }),

  put: <T>(url: string, body?: unknown, options?: Omit<ApiRequestOptions, "method" | "body">) =>
    apiRequest<T>(url, { ...options, method: "PUT", body })
}

Domain Modules

Each data source lives in its own folder. For example, products are in products/. We separate the requests themselves from their paths so that URLs aren't scattered throughout the code.

export const routes = {
  list: () => `/products`,
  byId: (id: number) => `/products/${id}`
}

In index.ts, we use these routes and our base transport, wrapping everything in strict types:

import { request } from "@/services/request"
import { routes } from "./routes"
import type { Product } from "./types"

export const getProducts = async (): Promise<Product[]> => {
  try {
    return await request.get<Product[]>(routes.list())
  } catch (error) {
    // Централизованная обработка или фоллбэк
    return []
  }
}

export const getProduct = async (id: number): Promise<Product | null> => {
  try {
    return await request.get<Product>(routes.byId(id))
  } catch (error) {
    return null
  }
}

Unified API Client

When there are many modules, importing each one individually becomes inconvenient. I gather them into a common client:

import * as products from "@/services/requests/products/index"
import * as users from "@/services/requests/users/index"

export const ApiClient = {
  products,
  users
}

Now the application has a predictable and convenient interface for data access: ApiClient.<domain>.<method>.

How It's Used in the UI

See how much cleaner the component's code becomes. It no longer knows about URLs, headers, tokens, or fetch details.

<script setup lang="ts">
import { onMounted, ref } from "vue"
import { ApiClient } from "@/services/client"

const products = ref([])
const loading = ref(true)

onMounted(async () => {
  try {
    products.value = await ApiClient.products.getProducts()
  } finally {
    loading.value = false
  }
})
</script>

The component focuses only on its direct task — state management and data display.

Summary

This separation prevents business logic and presentation from getting mixed up. A basic set consisting of a common request, domain folders, and a unified ApiClient is more than enough to keep the code from spreading and to ensure it remains readable even as the project scales significantly.