ไขความลับ Fetch API vs Axios: Tips & Tricks ที่ Dev หลายคนอาจไม่เคยรู้

Photo by Daniil Komov on Pexels

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

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

ทำไมการเลือกเครื่องมือที่ใช่ ถึงส่งผลต่อประสิทธิภาพของแอปพลิเคชัน?

การเลือกใช้ Fetch หรือ Axios ไม่ใช่แค่เรื่องของความสวยงามของโค้ด (Syntax Sugar) เท่านั้น แต่มันส่งผลโดยตรงต่อขนาดของ Bundle Size, ความเร็วในการประมวลผล, การจัดการหน่วยความจำ (Memory Management) และความง่ายในการบำรุงรักษาโค้ดในระยะยาว การเข้าใจลึกถึงพฤติกรรมของเครื่องมือทั้งสองจะช่วยให้คุณเขียนโค้ดได้คลีนขึ้นและบั๊กน้อยลงอย่างเห็นได้ชัด

1. ดักจับ Error ที่มองไม่เห็น: ความจริงที่ Fetch API ปล่อยผ่าน แต่ Axios บล็อกทันที

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

ในทางกลับกัน Axios มีพฤติกรรมที่ตรงไปตรงมามากกว่า โดยมันจะทำการ Reject Promise ทันทีหาก HTTP Status Code อยู่นอกเหนือช่วง 2xx ทำให้เราสามารถดักจับ Error ทุกรูปแบบได้ในบล็อก catch เดียว ทริคสำคัญสำหรับ Fetch API คือการสร้าง Wrapper ฟังก์ชันขึ้นมาครอบเพื่อเลียนแบบพฤติกรรมนี้ ซึ่งช่วยลดความซ้ำซ้อนของโค้ดได้อย่างมหาศาล

Trick: การเขียน Wrapper สำหรับ Fetch API ให้ปลอดภัยเหมือน Axios

หากคุณต้องการใช้ Fetch API แต่ไม่อยากเขียน if (!response.ok) ทุกครั้ง คุณสามารถสร้าง Helper Function ส่วนตัวที่ทำการตรวจสอบสถานะการตอบกลับโดยอัตโนมัติ และทำการโยน Error ออกไปเพื่อให้บล็อก catch ทำงานได้อย่างถูกต้อง ช่วยให้โค้ดสะอาดขึ้นและป้องกันข้อผิดพลาดจากการลืมเช็คสถานะ

// ตัวอย่างการทำ Wrapper เพื่อจัดการ Error ใน Fetch API
async function customFetch(url, options = {}) {
  const response = await fetch(url, options);
  
  if (!response.ok) {
    const errorData = await response.json().catch(() => ({}));
    const error = new Error(errorData.message || 'เกิดข้อผิดพลาดในการเชื่อมต่อ');
    error.status = response.status;
    error.data = errorData;
    throw error;
  }
  
  return response.json();
}

// วิธีการใช้งานที่สั้นและปลอดภัยขึ้น
customFetch('https://api.example.com/data')
  .then(data => console.log('สำเร็จ:', data))
  .catch(err => console.error(`ผิดพลาด (${err.status}):`, err.message));

2. ถอดรหัส JSON อัตโนมัติ: ฟีเจอร์ลับที่ช่วยประหยัดบรรทัดโค้ด

เมื่อเราใช้ Fetch API ข้อมูลที่ส่งกลับมาจาก Server จะอยู่ในรูปของ Stream ซึ่งหมายความว่าเราไม่สามารถนำข้อมูลนั้นมาใช้งานได้ทันที เราจำเป็นต้องเรียกใช้เมธอด response.json() เพื่อแปลงข้อมูลให้อยู่ในรูปของ JavaScript Object เสียก่อน ซึ่งกระบวนการนี้เป็นแบบ Asynchronous ทำให้เราต้องใช้คีย์เวิร์ด await ซ้ำซ้อน และส่งผลให้ประสิทธิภาพตกลงเล็กน้อยหากจัดการไม่ดี

สำหรับ Axios นั้น แตกต่างออกไปอย่างสิ้นเชิง เพราะมันมาพร้อมกับระบบแปลงข้อมูลอัตโนมัติ (Automatic JSON Transformation) ทันทีที่ Response ถูกส่งกลับมา Axios จะตรวจสอบ Content-Type Header หากพบว่าเป็น application/json มันจะทำการ Parse ข้อมูลให้เราเสร็จสรรพและส่งกลับมาในพร็อพเพอร์ตี้ data ทันที ช่วยลดขั้นตอนและบรรทัดโค้ดลงได้อย่างน่าอัศจรรย์

ทริคการปรับแต่ง Transforms ใน Axios เพื่อประสิทธิภาพสูงสุด

คุณรู้หรือไม่ว่าเราสามารถแทรกแซงกระบวนการแปลงข้อมูลของ Axios ได้ผ่านทางคอนฟิก transformResponse ซึ่งมีประโยชน์มากเมื่อเราต้องการกรองข้อมูลหรือจัดฟอร์แมตข้อมูลใหม่ทันทีที่ได้รับจาก Server ก่อนที่มันจะถูกส่งต่อไปยังส่วนอื่นๆ ของแอปพลิเคชัน ช่วยลดภาระการประมวลผลในส่วนของ UI Component

3. การยกเลิก Request กลางคัน: ศึกสายเลือดระหว่าง AbortController และ CancelToken

ในแอปพลิเคชันที่ซับซ้อน เช่น ระบบค้นหาแบบพิมพ์ไปค้นไป (Search Auto-complete) หรือการเปลี่ยนหน้าเพจอย่างรวดเร็ว การยกเลิก HTTP Request ที่ยังทำงานไม่เสร็จสิ้นเป็นสิ่งจำเป็นอย่างยิ่งเพื่อป้องกันปัญหา Race Condition และการสิ้นเปลืองแบนด์วิดท์ ในอดีต Axios มีระบบ CancelToken ที่เป็นเอกลักษณ์ แต่ปัจจุบันมาตรฐานอุตสาหกรรมได้เปลี่ยนไปแล้ว

Fetch API ใช้มาตรฐาน AbortController ในการยกเลิก Request ซึ่งทำงานร่วมกับสัญญาณ (Signal) ได้อย่างมีประสิทธิภาพและเป็นมาตรฐานเว็บแท้ๆ ข่าวดีคือปัจจุบัน Axios ก็ได้หันมาสนับสนุน AbortController เช่นเดียวกัน ทำให้เราสามารถเขียนโค้ดควบคุมการยกเลิก Request ด้วยมาตรฐานเดียวกันได้แล้ว ไม่ว่าจะใช้เครื่องมือตัวใดก็ตาม

ตัวอย่างการใช้ AbortController เพื่อป้องกันปัญหา Race Condition

โค้ดตัวอย่างด้านล่างนี้จะแสดงวิธีการใช้ AbortController ร่วมกับ Fetch API เพื่อยกเลิก Request ก่อนหน้าเมื่อมีการเรียกใช้ฟังก์ชันเดิมซ้ำ ซึ่งเป็นเทคนิคสำคัญในการทำระบบค้นหาที่ดีและลื่นไหล

let currentController = null;

function searchProducts(query) {
  // หากมี Request ค้างอยู่ก่อนหน้า ให้ทำการยกเลิกทันที
  if (currentController) {
    currentController.abort();
  }

  // สร้าง Controller ตัวใหม่สำหรับ Request นี้
  currentController = new AbortController();
  const { signal } = currentController;

  fetch(`https://api.example.com/search?q=${query}`, { signal })
    .then(response => response.json())
    .then(results => {
      console.log('ผลการค้นหา:', results);
    })
    .catch(error => {
      if (error.name === 'AbortError') {
        console.log('Request เก่าถูกยกเลิกสำเร็จ');
      } else {
        console.error('เกิดข้อผิดพลาด:', error);
      }
    });
}

4. Interceptors ปะทะ Middleware: การควบคุม Request/Response แบบไร้รอยต่อ

จุดเด่นที่สุดที่ทำให้ Axios ครองใจนักพัฒนาทั่วโลกคือระบบ Interceptors มันเปรียบเสมือนด่านตรวจคนเข้าเมืองของ HTTP Request และ Response ที่เปิดโอกาสให้เราสามารถแทรกแซง แก้ไข หรือเพิ่มเติมข้อมูลลงใน Header ได้โดยอัตโนมัติ เช่น การแนบ JWT Token ไปกับทุกๆ Request หรือการดักจับสถานะ 401 Unauthorized เพื่อทำระบบ Refresh Token อัตโนมัติ

ในขณะที่ Fetch API ไม่มีระบบ Interceptors มาให้ในตัว หากต้องการทำระบบดังกล่าว นักพัฒนาจำเป็นต้องเขียน Wrapper Function ขึ้นมาครอบเอง หรือใช้วิธีการเขียนทับฟังก์ชัน window.fetch (Monkey Patching) ซึ่งเป็นวิธีที่ค่อนข้างอันตรายและอาจส่งผลกระทบกับไลบรารีตัวอื่นในระบบได้หากจัดการไม่รัดกุมพอ

เทคนิคลับ: การสร้าง “Interceptors” จำลองสำหรับ Fetch API

แม้จะไม่มีฟีเจอร์นี้มาให้แบบ Native แต่เราสามารถสร้างสถาปัตยกรรมแบบ Middleware ขึ้นมาใช้งานร่วมกับ Fetch API ได้ โดยการใช้แนวคิด Functional Programming ในการร้อยเรียงฟังก์ชัน (Function Composition) เพื่อประมวลผล Request Option ก่อนส่งจริง ซึ่งปลอดภัยกว่าการทำ Monkey Patching เป็นอย่างมาก

5. Bundle Size และความปลอดภัย: ปัจจัยสำคัญที่มักถูกละเลย

ในยุคที่ความเร็วในการโหลดหน้าเว็บมีผลต่อ SEO และประสบการณ์ผู้ใช้ (UX) ขนาดของไฟล์ JavaScript ที่ส่งไปยังเบราว์เซอร์ (Bundle Size) จึงเป็นเรื่องที่ต้องใส่ใจ Fetch API ได้เปรียบอย่างสมบูรณ์แบบในหัวข้อนี้เพราะมันมีขนาด “0 KB” เนื่องจากมันถูกติดตั้งมาพร้อมกับเบราว์เซอร์ยุคใหม่อยู่แล้ว ไม่ต้องเสียเวลาดาวน์โหลดเพิ่มเติม

ส่วน Axios จะเพิ่มขนาด Bundle Size ของคุณขึ้นมาประมาณ 4-30 KB ขึ้นอยู่กับการบีบอัดและการเลือกใช้เวอร์ชัน แม้จะดูเหมือนน้อย แต่สำหรับโปรเจกต์ที่เน้นความเร็วระดับมิลลิวินาที เช่น หน้า Landing Page การลดขนาดไฟล์ลงได้แม้เพียงเล็กน้อยก็มีความหมาย นอกจากนี้ Axios ยังมีระบบป้องกันการโจมตีแบบ CSRF (Cross-Site Request Forgery) มาให้ในตัว ซึ่งช่วยยกระดับความปลอดภัยให้แอปพลิเคชันของคุณได้ทันทีโดยไม่ต้องตั้งค่าเพิ่มเติม

ตารางเปรียบเทียบเชิงลึกสำหรับการตัดสินใจเลือกใช้งาน

• ขนาดไฟล์ (Bundle Size): Fetch ชนะขาดลอยด้วยขนาด 0 KB ส่วน Axios มีขนาดเพิ่มขึ้นตามไลบรารี
• การจัดการ Error: Axios สะดวกกว่าด้วยการพ่น Error ทันทีเมื่อเจอสถานะที่ไม่ใช่ 2xx ขณะที่ Fetch ต้องเช็คเอง
• การแปลงข้อมูล (JSON Parsing): Axios ทำให้อัตโนมัติ ส่วน Fetch ต้องเรียกใช้เมธอด .json() แบบ Asynchronous
• ระบบดักจับ (Interceptors): Axios มีระบบในตัวที่ทรงพลังมาก เหมาะสำหรับแอปพลิเคชันขนาดใหญ่ที่มีการจัดการ Token
• ความเข้ากันได้ (Compatibility): Fetch ทำงานได้ดีบนเบราว์เซอร์สมัยใหม่และสภาพแวดล้อม Serverless เช่น Cloudflare Workers

สรุป

ไม่มีผู้ชนะที่แท้จริงในศึกระหว่าง Fetch API และ Axios มีเพียงเครื่องมือที่ “เหมาะสมที่สุด” สำหรับบริบทของโปรเจกต์คุณเท่านั้น หากคุณกำลังพัฒนาเว็บแอปพลิเคชันขนาดเล็กถึงปานกลาง หน้า Landing Page ที่ต้องการความเร็วสูงสุด หรือทำงานบนสภาพแวดล้อม Serverless Edge การเลือกใช้ Fetch API ควบคู่ไปกับการเขียน Helper Function เล็กๆ จะช่วยให้แอปพลิเคชันของคุณเบาและโหลดได้รวดเร็วอย่างน่าทึ่ง

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