API Services

Relevant source files

The following files were used as context for generating this wiki page:

• services/apiService.ts
• services/supabaseService.ts
• components/api.ts
• constants/commons.ts
• utils/logger.ts
• VALIDACION-COMPLETA.md
• README.md

The API Services layer in the ElmecV2 application is responsible for all communication with backend services. The architecture includes two distinct patterns: a primary, modern service for interacting with Supabase, and a legacy structure for a traditional REST API. While the Supabase service is central to the application's functionality, the REST API services appear to be deprecated or are remnants of a previous architecture.

The main backend is provided by Supabase, which handles the database (PostgreSQL), authentication, real-time subscriptions, and storage. The application interacts with it via a dedicated Supabase client service.

Sources: README.md, VALIDACION-COMPLETA.md

Architecture Overview

The application's service layer is split into two potential paths for data retrieval and manipulation. The primary path uses the Supabase client directly, while a secondary, likely legacy path is structured around an Axios-based REST client.

This diagram illustrates the two API interaction patterns. The dashed lines indicate the legacy REST API path which may no longer be in active use.

Sources: services/supabaseService.ts, services/apiService.ts, VALIDACION-COMPLETA.md

Service File Summary

File	Role	Status
services/supabaseService.ts	Provides a singleton instance of the Supabase client for the entire application.	✅ Active
services/apiService.ts	A wrapper around Axios for making RESTful API calls (GET, POST, PUT, DELETE).	⚠️ Legacy/Deprecated
components/api.ts	An older, component-level Axios instance.	⚠️ Legacy/Deprecated
constants/commons.ts	Defines URL paths for the legacy REST API.	⚠️ Legacy-related
utils/logger.ts	Contains utility functions for logging API calls.	✅ Active

Sources: VALIDACION-COMPLETA.md, services/supabaseService.ts, services/apiService.ts

Supabase Service

The supabaseService.ts file is the cornerstone of the application's backend communication. It initializes and exports a single, shared instance of the Supabase client.

Sources: services/supabaseService.ts

Initialization

The client is created using environment variables for the Supabase URL and the anonymous key. This ensures that credentials are not hardcoded in the source. The service checks for the existence of these variables and throws an error if they are missing, preventing the app from running with an invalid configuration.

The following diagram shows the initialization flow for the Supabase client.

Legacy REST API Services

The repository contains files (apiService.ts, components/api.ts, constants/commons.ts) that define a classic REST API client using Axios. However, project validation reports suggest these are legacy and may contain errors, such as missing module dependencies (axios).

Sources: VALIDACION-COMPLETA.md, services/apiService.ts, components/api.ts

apiService.ts

This service defines a class ApiService that acts as a wrapper for Axios. It is designed to handle standard HTTP requests and manage authentication tokens automatically.

Key methods include:

• get(url, params)
• post(url, data)
• put(url, data)
• delete(url)

The service includes interceptors to inject an authentication token into the headers of outgoing requests and to handle token refresh logic on 401 Unauthorized responses.

The diagram below shows the sequence for a typical GET request using this legacy service.

constants/commons.ts

This file centralizes the endpoint paths for the REST API. It organizes URLs by feature, such as Authentication, User Management, Requests, and Chat. This structure indicates a well-defined REST API was planned or previously implemented.

Key API Endpoint Definitions

Module	Constant	Path
Authentication	LOGIN	/auth/login/
	LOGOUT	/auth/logout/
User Management	INFO_USER	/users/profile/
	USER_ADMIN_LIST	/users/
Requests	CUSTOMER_REQUEST_LIST	/requests/customer/
	AGENT_REQUEST_LIST	/requests/agent/
Chat	REQUEST_CHAT_LIST	/chat/rooms/
	REQUEST_CHAT_MESSAGE_CREATE	/chat/messages/create/

Sources: constants/commons.ts:2-36

API Call Logging

The utils/logger.ts file provides a Logger class with a static method logApiCall to standardize the logging of API interactions. This is a crucial utility for debugging and monitoring application behavior.

The logApiCall function records the HTTP method, URL, response status code, and request duration. It automatically sets the log level to ERROR for status codes 400 and above, and INFO otherwise.

// file: utils/logger.ts:200-207
  static logApiCall(method: string, url: string, status?: number, duration?: number) {
    const level = status && status >= 400 ? LogLevel.ERROR : LogLevel.INFO;
    this.log(level, `API ${method} ${url}`, 'api', {
      method,
      url,
      status,
      duration
    });
  }

Sources: utils/logger.ts:200-207

This functionality ensures that all network requests, successful or failed, can be tracked consistently.

Conclusion

The ElmecV2 application's API service layer is centered around the supabaseService.ts, which provides a direct and modern interface to the Supabase backend. While a comprehensive structure for a traditional REST API exists across apiService.ts and constants/commons.ts, evidence from project reports indicates this is a legacy implementation and is not the primary method of backend communication. The architecture is supported by a robust logging utility in utils/logger.ts that tracks all API calls for monitoring and debugging purposes. Developers should prioritize using the supabaseService for all new backend interactions.