Fetch API vs Axios: เลือกเครื่องมือทำ HTTP Request อย่างไรให้ได้ประสิทธิภาพสูงสุด

Photo by hitesh choudhary on Pexels

ในยุคที่เว็บแอปพลิเคชันต้องพึ่งพาการรับส่งข้อมูลผ่าน API เป็นหัวใจหลัก นักพัฒนาเว็บทุกคนต่างต้องเคยผ่านการตัดสินใจเลือกเครื่องมือสำหรับทำ HTTP Request สองตัวเลือกที่ทรงอิทธิพลที่สุดในระบบนิเวศของ JavaScript คือ Fetch API ซึ่งเป็นมาตรฐานที่ติดมากับเบราว์เซอร์ยุคใหม่ และ Axios ไลบรารียอดนิยมที่มีฟีเจอร์ครบครัน การเลือกใช้เครื่องมือที่เหมาะสมไม่เพียงแต่ช่วยให้โค้ดสะอาดและดูแลรักษาง่ายขึ้น แต่ยังส่งผลโดยตรงต่อประสิทธิภาพและความปลอดภัยของแอปพลิเคชันของคุณด้วย

บทความนี้จะพาคุณไปเจาะลึกเปรียบเทียบระหว่าง Fetch API และ Axios ในมุมมองของนักพัฒนาเทคโนโลยีมืออาชีพ โดยเน้นไปที่แนวทางปฏิบัติที่ดีที่สุด (Best Practices) สิ่งที่ควรทำ (Dos) และสิ่งที่ไม่ควรทำ (Don’ts) เพื่อให้คุณสามารถเลือกและใช้งานเครื่องมือทั้งสองได้อย่างเต็มประสิทธิภาพสูงสุดในโปรเจกต์ถัดไปของคุณ

1. ทำความรู้จักสถาปัตยกรรมและพื้นฐานการทำงาน

Fetch API คือมาตรฐานระดับเว็บ (Web Standard) ที่ถูกพัฒนาขึ้นมาเพื่อทดแทน XMLHttpRequest แบบดั้งเดิม มันทำงานบนพื้นฐานของ Promise ทำให้การเขียนโค้ดแบบ Asynchronous มีความลื่นไหลและเข้าใจง่าย ข้อดีที่สุดของ Fetch คือการเป็น “Native” ที่เบราว์เซอร์สมัยใหม่ทุกตัวรองรับโดยไม่ต้องติดตั้งโมดูลเพิ่มเติม ช่วยลดขนาดของ Bundle Size ของแอปพลิเคชันให้เบาบางที่สุด

ในทางกลับกัน Axios คือไลบรารีภายนอก (Third-party Library) ที่ทำงานได้ทั้งบนฝั่งไคลเอนต์ (Browser) และฝั่งเซิร์ฟเวอร์ (Node.js) โดยใช้ XMLHttpRequest ภายใต้เบราว์เซอร์ และใช้โมดูล http ของ Node.js เมื่อทำงานบนเซิร์ฟเวอร์ Axios มาพร้อมกับคุณสมบัติอำนวยความสะดวกมากมายที่ติดตั้งมาให้พร้อมใช้งานทันที เช่น การแปลงข้อมูล JSON อัตโนมัติ ระบบ Interceptors และการยกเลิก Request ที่ทำได้ง่าย

ความแตกต่างที่สำคัญในระดับโครงสร้าง

ความแตกต่างที่ชัดเจนที่สุดคือการจัดการกับข้อมูลรับส่ง Fetch API ต้องการขั้นตอนการแปลงข้อมูลเพิ่มเติม เช่น ต้องเรียกเมธอด .json() เพื่อแปลง Response Body ในขณะที่ Axios จะทำการแปลงข้อมูลเป็นออบเจกต์ JavaScript ให้โดยอัตโนมัติผ่านพร็อพเพอร์ตี้ data นอกจากนี้การจัดการกับข้อผิดพลาด (Error Handling) ของทั้งสองตัวยังมีพฤติกรรมที่แตกต่างกันอย่างสิ้นเชิง ซึ่งเป็นจุดที่นักพัฒนามักจะสับสนและทำผิดพลาดบ่อยครั้ง

2. แนวทางปฏิบัติที่ดีที่สุดในการใช้งาน Fetch API (Fetch Best Practices)

เมื่อตัดสินใจใช้งาน Fetch API สิ่งที่ควรทำเป็นอันดับแรกคือการสร้าง “Wrapper Function” หรือฟังก์ชันครอบส่วนกลาง เพื่อกำหนดค่าเริ่มต้น เช่น Base URL, Headers และการจัดการ Error ร่วมกัน การไม่เขียน Fetch ดิบๆ กระจัดกระจายไปทั่วทั้งแอปพลิเคชันจะช่วยให้โค้ดของคุณมีความยืดหยุ่นและบำรุงรักษาง่ายขึ้นเมื่อมีการเปลี่ยนแปลง API ในอนาคต

ข้อควรระวังที่สำคัญที่สุดของ Fetch API คือ มันจะไม่โยนข้อผิดพลาด (Reject Promise) เมื่อเซิร์ฟเวอร์ตอบกลับมาด้วย HTTP Status Code ที่เป็นความล้มเหลว เช่น 404 Not Found หรือ 500 Internal Server Error สัญญา Promise ของ Fetch จะยังคงสถานะ Resolved ตราบใดที่การเชื่อมต่อเครือข่ายสำเร็จ ดังนั้น คุณต้องตรวจสอบพร็อพเพอร์ตี้ response.ok ด้วยตัวเองเสมอ

ตัวอย่างการเขียน Fetch API ที่ถูกต้องตามมาตรฐาน

async function customFetch(endpoint, options = {}) {
  const BASE_URL = 'https://api.example.com/v1';
  const defaultHeaders = {
    'Content-Type': 'application/json',
  };

  const config = {
    ...options,
    headers: {
      ...defaultHeaders,
      ...options.headers,
    },
  };

  try {
    const response = await fetch(`${BASE_URL}${endpoint}`, config);
    
    // สิ่งที่ควรทำ: ตรวจสอบสถานะ response.ok เสมอ
    if (!response.ok) {
      const errorData = await response.json().catch(() => ({}));
      throw new Error(errorData.message || `HTTP error! status: ${response.status}`);
    }

    // แปลงข้อมูลเป็น JSON อัตโนมัติ
    return await response.json();
  } catch (error) {
    console.error('Fetch Error:', error.message);
    throw error;
  }
}

3. แนวทางปฏิบัติที่ดีที่สุดในการใช้งาน Axios (Axios Best Practices)

สำหรับ Axios แนวทางปฏิบัติที่ดีที่สุดคือการสร้าง “Axios Instance” แยกต่างหากสำหรับแต่ละบริการของ API วิธีนี้ช่วยให้คุณกำหนดค่าคอนฟิกูเรชันเฉพาะ เช่น timeout, baseURL และ headers ร่วมกันได้อย่างเป็นระเบียบ นอกจากนี้ คุณควรใช้ประโยชน์จากระบบ Interceptors ของ Axios เพื่อจัดการกับ Token Authentication และการทำ Global Error Handling อย่างเป็นระบบ

สิ่งที่ควรทำในการใช้ Axios คือการตั้งค่า timeout เสมอ เพราะค่าเริ่มต้นของ Axios จะไม่มีการจำกัดเวลา (No timeout) ซึ่งอาจส่งผลให้แอปพลิเคชันของคุณค้างหรือทำงานช้าลงอย่างมากหากเซิร์ฟเวอร์ปลายทางไม่มีการตอบสนอง การกำหนด timeout ที่เหมาะสมจะช่วยตัดการเชื่อมต่อและแจ้งเตือนผู้ใช้ได้อย่างรวดเร็ว

ตัวอย่างการสร้าง Axios Instance พร้อม Interceptors

import axios from 'axios';

// สิ่งที่ควรทำ: สร้าง Instance พร้อมกำหนด Timeout และ Base URL
const apiClient = axios.create({
  baseURL: 'https://api.example.com/v1',
  timeout: 10000, // 10 วินาที
  headers: {
    'Content-Type': 'application/json',
  },
});

// การใช้ Request Interceptor เพื่อแนบ Bearer Token
apiClient.interceptors.request.use(
  (config) => {
    const token = localStorage.getItem('authToken');
    if (token) {
      config.headers.Authorization = `Bearer ${token}`;
    }
    return config;
  },
  (error) => Promise.reject(error)
);

// การใช้ Response Interceptor สำหรับจัดการ Error ส่วนกลาง
apiClient.interceptors.response.use(
  (response) => response.data, // ส่งกลับเฉพาะข้อมูล data เพื่อความสะดวก
  (error) => {
    if (error.response && error.response.status === 401) {
      // จัดการกรณี Token หมดอายุ เช่น Redirect ไปหน้า Login
      console.warn('Unauthorized, redirecting...');
    }
    return Promise.reject(error);
  }
);

export default apiClient;

4. สิ่งที่ควรทำและไม่ควรทำ (Dos & Don’ts)

การเข้าใจถึงสิ่งที่ควรทำและไม่ควรทำในการเลือกใช้เครื่องมือทั้งสองนี้ จะช่วยป้องกันไม่ให้เกิดบั๊กที่หาสาเหตุได้ยากในระบบ และช่วยให้ประสิทธิภาพการทำงานของทีมดีขึ้นอย่างเห็นได้ชัด

ข้อผิดพลาดที่พบบ่อยในการใช้ Fetch คือการลืมจัดการกรณีที่เครือข่ายขัดข้อง (Network Failure) และการส่งข้อมูลแบบ POST โดยลืมแปลงออบเจกต์ให้เป็นสตริงด้วย JSON.stringify() ส่วนใน Axios ข้อผิดพลาดคือการติดตั้งไลบรารีขนาดใหญ่เข้ามาโดยไม่จำเป็นสำหรับโปรเจกต์ขนาดเล็กที่มีการเรียกใช้งาน API เพียงไม่กี่ครั้ง

ตารางเปรียบเทียบแนวทางปฏิบัติ

• Do (ควรทำ): ใช้ Axios เมื่อต้องการสร้างแอปพลิเคชันขนาดใหญ่ที่มีการเชื่อมต่อ API ซับซ้อน และต้องการระบบจัดเก็บ Token ที่ปลอดภัยผ่าน Interceptors
• Do (ควรทำ): ใช้ Fetch API สำหรับโปรเจกต์ขนาดเล็ก, Micro-frontends หรือแอปพลิเคชันที่ต้องการรีดประสิทธิภาพและความเร็วในการโหลดหน้าเว็บสูงสุด (Minimal Bundle Size)
• Don’t (ไม่ควรทำ): อย่าลืมเช็ค response.ok เมื่อใช้งาน Fetch API เพราะโค้ดจะทำงานต่อไปเสมือนว่าสำเร็จแม้จะเกิด Error 500 ก็ตาม
• Don’t (ไม่ควรทำ): อย่าละเลยการกำหนด timeout ใน Axios เพราะอาจทำให้แอปพลิเคชันของคุณค้างเมื่อเน็ตเวิร์กมีปัญหา
• Do (ควรทำ): ใช้ AbortController ในการยกเลิก Request ที่ค้างอยู่เมื่อ Component ใน React หรือ Vue ถูก Unmount เพื่อป้องกัน Memory Leak

5. การเลือกใช้ให้เหมาะกับสถาปัตยกรรมของโปรเจกต์

การตัดสินใจเลือกระหว่าง Fetch API และ Axios ไม่ใช่เรื่องของเครื่องมือใด “ดีกว่า” เครื่องมือใดอย่างสมบูรณ์แบบ แต่เป็นเรื่องของ “ความเหมาะสม” กับบริบทของโปรเจกต์ หากคุณกำลังพัฒนาเว็บแอปพลิเคชันด้วย Next.js หรือ Framework สมัยใหม่ที่เน้นการทำ Server-Side Rendering (SSR) การใช้ Fetch API มักจะได้รับการสนับสนุนที่ดีกว่า เนื่องจาก Next.js ได้ทำการขยายความสามารถ (Extend) ของ Fetch ดิบให้รองรับการทำ Caching และ Revalidation ในระดับเฟรมเวิร์กโดยอัตโนมัติ

อย่างไรก็ตาม หากทีมของคุณคุ้นเคยกับสถาปัตยกรรมดั้งเดิม หรือกำลังสร้างแอปพลิเคชันประเภท Single Page Application (SPA) ด้วย React หรือ Vue ที่ต้องมีการจัดการ State และการเชื่อมต่อ API หลายร้อย Endpoint การเลือกใช้ Axios จะช่วยลดภาระการเขียนโค้ดซ้ำซ้อน (Boilerplate Code) และช่วยให้มาตรฐานการจัดการ HTTP Request ของทั้งทีมมีความสม่ำเสมอและเป็นหนึ่งเดียวกันได้ง่ายกว่ามาก

สรุป

ทั้ง Fetch API และ Axios ต่างเป็นเครื่องมือระดับอุตสาหกรรมที่มีประสิทธิภาพสูง Fetch API โดดเด่นในเรื่องของความเบา ความเป็นมาตรฐานเว็บ และไม่ต้องพึ่งพาไลบรารีภายนอก เหมาะสำหรับโปรเจกต์ยุคใหม่ที่เน้นความเร็วและประสิทธิภาพ ในขณะที่ Axios มอบประสบการณ์การพัฒนาที่ราบรื่นด้วยฟีเจอร์ที่ครบครันตั้งแต่แกะกล่อง เหมาะสำหรับแอปพลิเคชันระดับองค์กรที่มีความซับซ้อนสูง

กุญแจสำคัญสู่ความสำเร็จไม่ใช่การเลือกเครื่องมือที่ดีที่สุด แต่คือการเข้าใจพฤติกรรมการทำงานของเครื่องมือที่คุณเลือกอย่างลึกซึ้ง ปฏิบัติตามแนวทาง Best Practices อย่างเคร่งครัด หลีกเลี่ยงข้อผิดพลาดทั่วไป และเขียนโค้ดที่มีการจัดการโครงสร้างที่ดี เพื่อให้แอปพลิเคชันของคุณมีความเสถียร ปลอดภัย และพร้อมสำหรับการขยายตัวในอนาคต