[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"academy-blogs-th-1-1-all-what-is-api-gateway-all--*":3,"academy-blog-faqs-pnc822055yw3k99-th":95,"academy-blog-translations-pnc822055yw3k99":120},{"data":4,"page":94,"perPage":94,"totalItems":94,"totalPages":94},[5],{"alt":6,"collectionId":7,"collectionName":8,"content":9,"cover_image":10,"cover_image_l_url":11,"cover_image_m_url":12,"cover_image_path":13,"cover_image_s_url":14,"created":15,"created_by":16,"expand":17,"id":87,"keywords":88,"locale":58,"published_at":89,"scheduled_at":74,"school_blog":83,"short_description":90,"status":81,"title":91,"updated":92,"updated_by":93,"slug":84,"views":86},"รางรถไฟยามพลบค่ำที่แตกออกจากจุดเดียวไกลออกไปเป็นหลายราง สื่อถึง API Gateway ที่รับ request ทางเดียวแล้วส่งต่อไปหลาย service พร้อมการ์ดสรุป: ประตูทางเข้าเดียว, \u002Fusers ไป users-service, \u002Forders ไป orders-service และ 429 Too Many Requests","sclblg987654321","school_blog_translations","\u003Cp>ลองนึกภาพแอปสั่งอาหารที่เริ่มต้นจาก backend ตัวเดียว ทุกอย่างอยู่ในเซิร์ฟเวอร์เดียว หน้าแอปเรียก URL เดียวจบ พอแอปโตขึ้น ทีมก็แยกระบบออกเป็นห้า service: ข้อมูลผู้ใช้ ร้านอาหาร คำสั่งซื้อ การชำระเงิน และการติดตามไรเดอร์ วันหนึ่งคนเขียนหน้าแอปเปิดไฟล์ config แล้วเจอ URL ห้าชุด แต่ละ service ตรวจ login เองคนละแบบ บางตัวกันการยิงถี่ บางตัวไม่กัน และทุกครั้งที่ทีม backend ย้ายหรือแยก service ใหม่ หน้าแอปต้องแก้ตามทุกครั้ง\u003C\u002Fp>\n\u003Cp>คำถามที่ตามมาคือ จะมีจุดเดียวไหมที่ให้หน้าแอปคุยด้วย แล้วจุดนั้นค่อยส่งต่อให้ service ที่ถูกตัว สั้นๆ: \u003Cstrong>API Gateway คือประตูทางเข้าเดียวที่ตั้งอยู่หน้า backend หลาย service รับทุก request จาก client ตรวจสิทธิ์ จำกัดจำนวนครั้ง แล้วส่งต่อไปยัง service ที่ถูกต้อง\u003C\u002Fstrong> วันนี้ Superdev Academy จะพาไปดูว่ามันทำงานอย่างไร มีหน้าที่อะไรบ้าง ต่างจาก Load Balancer และ Reverse Proxy ตรงไหน และจะลองเขียน gateway ตัวเล็กๆ ด้วย Node.js ให้เห็นกับตาว่ามันตอบ 429 เมื่อถูกยิงถี่เกินไปจริง\u003C\u002Fp>\n\u003Cp>ถ้ายังไม่คุ้นกับคำว่า API หรือ Endpoint แนะนำให้อ่าน \u003Ca href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002Fwhat-is-api-beginners-guide\" target=\"_blank\" rel=\"noopener noreferrer\">API คืออะไร\u003C\u002Fa> ก่อน แล้วค่อยกลับมาต่อ บทความนี้จะง่ายขึ้นมาก\u003C\u002Fp>\n\n\u003Ch2>API Gateway คืออะไร\u003C\u002Fh2>\n\u003Cp>API Gateway คือเซิร์ฟเวอร์ตัวกลางที่ client ทุกตัว (แอปมือถือ เว็บ หรือระบบของพาร์ตเนอร์) ส่ง request มาหาที่เดียว แล้วตัว gateway เป็นคนตัดสินว่า request นั้นควรไปหา service ไหนข้างหลัง\u003C\u002Fp>\n\u003Cp>Microsoft อธิบายไว้ในเอกสาร Azure Architecture Center ว่า API Gateway เป็น \u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Farchitecture\u002Fmicroservices\u002Fdesign\u002Fgateway\" target=\"_blank\" rel=\"noopener noreferrer\">จุดเข้าแบบรวมศูนย์ (centralized entry point)\u003C\u002Fa> ที่ทำหน้าที่เป็น Reverse Proxy ส่ง request ไปยัง service ที่เหมาะสม และรับงานที่ทุก service ต้องทำซ้ำกัน เช่น authentication, SSL termination และ rate limiting ส่วน AWS เรียก Amazon API Gateway ว่าเป็น \"front door\" ของแอปพลิเคชันที่เข้าถึงข้อมูลและ business logic ใน backend\u003C\u002Fp>\n\u003Cp>พูดง่ายๆ คือมันเหมือนเคาน์เตอร์ต้อนรับของตึก คนมาติดต่อไม่ต้องรู้ว่าแผนกไหนอยู่ชั้นไหน แค่บอกเคาน์เตอร์ว่ามาทำอะไร เคาน์เตอร์ตรวจบัตร แล้วชี้ทางให้ถูกห้อง\u003C\u002Fp>\n\n\u003Ch2>API Gateway ทำงานอย่างไร\u003C\u002Fh2>\n\u003Cp>ถ้าเอาแอปสั่งอาหารเมื่อกี้มาใส่ gateway ไว้ข้างหน้า เส้นทางของ request หนึ่งตัวจะเป็นแบบนี้\u003C\u002Fp>\n\u003Col>\n\u003Cli>หน้าแอปส่ง \u003Ccode>GET \u002Forders\u003C\u002Fcode> ไปที่ URL เดียว คือ URL ของ gateway\u003C\u002Fli>\n\u003Cli>gateway ตรวจว่า request นี้มี token หรือ API Key ที่ถูกต้องไหม ถ้าไม่มีก็ตอบ 401 กลับไปเลย ไม่ต้องรบกวน service ข้างหลัง\u003C\u002Fli>\n\u003Cli>gateway เช็กว่า client รายนี้ยิงมาเกินโควตาหรือยัง ถ้าเกินก็ตอบ 429\u003C\u002Fli>\n\u003Cli>gateway ดู path แล้วจับคู่กับกฎ routing ว่า \u003Ccode>\u002Forders\u003C\u002Fcode> ต้องไปที่ orders-service\u003C\u002Fli>\n\u003Cli>service ตอบกลับมา gateway จดลง log แล้วส่งคำตอบคืนให้หน้าแอป\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>สิ่งที่เปลี่ยนไปคือหน้าแอปรู้จักแค่ URL เดียว ส่วนการย้าย แยก หรือรวม service ข้างหลังกลายเป็นเรื่องของการแก้กฎใน gateway ไม่ใช่การปล่อยแอปเวอร์ชันใหม่\u003C\u002Fp>\n\n\u003Ch2>API Gateway มีหน้าที่อะไรบ้าง\u003C\u002Fh2>\n\u003Cp>หน้าที่ด้านล่างนี้เป็นหน้าที่หลักที่เอกสารของ Microsoft และ AWS พูดถึงตรงกัน ไม่ใช่ทุก gateway จะเปิดใช้ทุกข้อ และแต่ละผลิตภัณฑ์รองรับแต่ละข้อไม่เท่ากัน\u003C\u002Fp>\n\n\u003Ch3>Routing: ส่ง request ไปให้ถูก service\u003C\u002Fh3>\n\u003Cp>หน้าที่พื้นฐานที่สุด gateway ดู path, header หรือ host แล้วส่งต่อตามกฎ เช่น \u003Ccode>\u002Fusers\u003C\u002Fcode> ไป users-service และ \u003Ccode>\u002Forders\u003C\u002Fcode> ไป orders-service เอกสาร Gateway Routing pattern ของ Microsoft ระบุว่าการ routing แบบนี้ทำงานที่ Layer 7 (ชั้นของ HTTP) จึงตัดสินจาก URL หรือ header ได้\u003C\u002Fp>\n\n\u003Ch3>Authentication: ตรวจตัวตนครั้งเดียวที่หน้าประตู\u003C\u002Fh3>\n\u003Cp>แทนที่ทุก service จะเขียนโค้ดตรวจ token เอง gateway ตรวจให้ที่จุดเดียว Amazon API Gateway รองรับการตรวจสิทธิ์ผ่าน IAM policy, Lambda authorizer และ Amazon Cognito user pools ส่วนเรื่องการเก็บ API Key ฝั่งเซิร์ฟเวอร์ให้ปลอดภัย เรามีอธิบายไว้แยกใน \u003Ca href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002Fapi-key-env-keep-secrets-safe\" target=\"_blank\" rel=\"noopener noreferrer\">บทความเรื่องเก็บ API Key ด้วย .env\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch3>Rate Limiting: กันการยิงถี่ แล้วตอบ 429\u003C\u002Fh3>\n\u003Cp>Rate Limiting (การจำกัดจำนวนครั้งที่เรียกได้ในช่วงเวลาหนึ่ง) ช่วยไม่ให้ client รายเดียวกินทรัพยากรทั้งระบบ สถานะที่ใช้บอกว่าโดนจำกัดคือ \u003Cstrong>429 Too Many Requests\u003C\u002Fstrong> ซึ่งนิยามไว้ใน RFC 6585 และ RFC ฉบับนี้บอกว่าคำตอบอาจแนบ header \u003Ccode>Retry-After\u003C\u002Fcode> เพื่อบอก client ว่าควรรออีกนานเท่าไร\u003C\u002Fp>\n\u003Cp>แต่ละเจ้าใช้วิธีนับต่างกัน AWS ระบุว่า \u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fapigateway\u002Flatest\u002Fdeveloperguide\u002Fapi-gateway-request-throttling.html\" target=\"_blank\" rel=\"noopener noreferrer\">Amazon API Gateway ใช้อัลกอริทึม token bucket\u003C\u002Fa> และเมื่อ request เกินทั้งอัตราปกติและค่า burst ที่ตั้งไว้ client อาจได้รับ 429 กลับไป ส่วน NGINX ใช้ \u003Ca href=\"https:\u002F\u002Fnginx.org\u002Fen\u002Fdocs\u002Fhttp\u002Fngx_http_limit_req_module.html\" target=\"_blank\" rel=\"noopener noreferrer\">โมดูล limit_req ที่ทำงานแบบ leaky bucket\u003C\u002Fa> และจุดที่หลายคนพลาดคือค่าเริ่มต้นของ \u003Ccode>limit_req_status\u003C\u002Fcode> คือ \u003Cstrong>503\u003C\u002Fstrong> ไม่ใช่ 429 ถ้าอยากให้ตอบ 429 ต้องตั้งเอง\u003C\u002Fp>\n\u003Cblockquote>\u003Cp>Fun Fact: ความหมายของสถานะ 4xx\u002F5xx อื่นๆ ที่ gateway ชอบตอบ เช่น 401, 502, 503 อ่านต่อได้ใน \u003Ca href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002Fhttp-status-codes-explained\" target=\"_blank\" rel=\"noopener noreferrer\">HTTP Status Code คืออะไร\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fblockquote>\n\n\u003Ch3>TLS Termination: ถอดรหัส HTTPS ที่หน้าประตู\u003C\u002Fh3>\n\u003Cp>TLS Termination (หรือ SSL termination) คือให้ gateway เป็นคนจัดการใบรับรองและถอดรหัส HTTPS จาก client แล้วค่อยคุยกับ service ข้างหลังในเครือข่ายภายใน ข้อดีคือจัดการใบรับรองที่จุดเดียว ไม่ต้องติดตั้งในทุก service ถ้าต้องการให้ภายในเข้ารหัสด้วย ก็ใช้ Mutual TLS ซึ่ง Microsoft ระบุว่าเป็นอีกงานที่ย้ายมาไว้ที่ gateway ได้\u003C\u002Fp>\n\n\u003Ch3>Request\u002FResponse Transformation: ปรับหน้าตาข้อมูลระหว่างทาง\u003C\u002Fh3>\n\u003Cp>gateway บางตัวแก้ header, เปลี่ยน path หรือแปลงรูปแบบข้อมูลก่อนส่งต่อได้ เช่น เติม header ระบุตัวผู้ใช้ให้ service ข้างหลัง หรือรวมคำตอบจากหลาย service เป็นคำตอบเดียว ซึ่ง Microsoft เรียกแบบหลังว่า Gateway Aggregation pattern ช่วยลดจำนวน request ที่แอปต้องยิง\u003C\u002Fp>\n\n\u003Ch3>Logging และ Monitoring: เห็นทุก request ในที่เดียว\u003C\u002Fh3>\n\u003Cp>เพราะทุก request ผ่าน gateway มันจึงเป็นจุดที่ดีที่สุดในการเก็บ log และวัดผล Amazon API Gateway ส่ง access log และ execution log ไปที่ CloudWatch ได้ และตั้ง alarm ได้ ทำให้เห็นภาพรวมว่า endpoint ไหนช้า ใครโดน 429 บ่อย\u003C\u002Fp>\n\n\u003Ch2>ตัวอย่าง API Gateway: เขียนเองด้วย Node.js\u003C\u002Fh2>\n\u003Cp>อ่านทฤษฎีมาพอแล้ว มาลองของจริงกัน ตัวอย่างนี้ใช้แค่โมดูล \u003Ccode>node:http\u003C\u002Fcode> ที่มากับ Node.js ไม่ต้องติดตั้งแพ็กเกจเพิ่ม เราทดสอบบน Node.js v26.7.0, curl 8.4.0, macOS 14.3.1 เมื่อวันที่ 1 ตุลาคม 2026\u003C\u002Fp>\n\u003Cp>ไฟล์แรกคือ service จำลองสองตัว ตัวหนึ่งตอบข้อมูลผู้ใช้ อีกตัวตอบคำสั่งซื้อ\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-javascript\">\u002F\u002F services.js — two tiny backend services\nconst http = require('node:http');\n\nfunction service(name, port, payload) {\n  http.createServer((req, res) => {\n    res.writeHead(200, { 'Content-Type': 'application\u002Fjson' });\n    res.end(JSON.stringify({ service: name, path: req.url, data: payload }));\n  }).listen(port, () => console.log(`${name} on :${port}`));\n}\n\nservice('users-service', 4001, [{ id: 1, name: 'Nok' }]);\nservice('orders-service', 4002, [{ id: 101, item: 'Pad Thai' }]);\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>ไฟล์ที่สองคือตัว gateway ทำสี่อย่าง: ตรวจ API Key, จำกัด 3 request ต่อ 10 วินาที, routing ตาม path และเขียน log\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-javascript\">\u002F\u002F gateway.js — one entry point in front of two services\nconst http = require('node:http');\n\nconst routes = {\n  '\u002Fusers': 'http:\u002F\u002Flocalhost:4001',\n  '\u002Forders': 'http:\u002F\u002Flocalhost:4002',\n};\n\nconst LIMIT = 3;            \u002F\u002F requests allowed...\nconst WINDOW_MS = 10_000;   \u002F\u002F ...per 10 seconds, per client\nconst hits = new Map();     \u002F\u002F client -> { count, start }\n\nfunction rateLimited(client) {\n  const now = Date.now();\n  const entry = hits.get(client);\n  if (!entry || now - entry.start >= WINDOW_MS) {\n    hits.set(client, { count: 1, start: now });\n    return false;\n  }\n  entry.count += 1;\n  return entry.count > LIMIT;\n}\n\nhttp.createServer((req, res) => {\n  \u002F\u002F 1) authentication: one check, for every service behind the gateway\n  const key = req.headers['x-api-key'];\n  if (key !== 'demo-key') {\n    res.writeHead(401, { 'Content-Type': 'application\u002Fjson' });\n    return res.end(JSON.stringify({ error: 'missing or wrong x-api-key' }));\n  }\n\n  \u002F\u002F 2) rate limiting: per API key\n  if (rateLimited(key)) {\n    res.writeHead(429, { 'Content-Type': 'application\u002Fjson', 'Retry-After': '10' });\n    return res.end(JSON.stringify({ error: 'Too Many Requests' }));\n  }\n\n  \u002F\u002F 3) routing: match the path prefix, forward to the right service\n  const prefix = Object.keys(routes).find((p) => req.url.startsWith(p));\n  if (!prefix) {\n    res.writeHead(404, { 'Content-Type': 'application\u002Fjson' });\n    return res.end(JSON.stringify({ error: 'no route' }));\n  }\n\n  const upstream = new URL(req.url, routes[prefix]);\n  const proxyReq = http.request(upstream, { method: req.method, headers: req.headers }, (up) => {\n    \u002F\u002F 4) logging: one line per request, in one place\n    console.log(`${req.method} ${req.url} -> ${routes[prefix]} ${up.statusCode}`);\n    res.writeHead(up.statusCode, up.headers);\n    up.pipe(res);\n  });\n  proxyReq.on('error', () => {\n    res.writeHead(502, { 'Content-Type': 'application\u002Fjson' });\n    res.end(JSON.stringify({ error: 'Bad Gateway' }));\n  });\n  req.pipe(proxyReq);\n}).listen(8080, () => console.log('gateway on :8080'));\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>เปิดสอง terminal รัน \u003Ccode>node services.js\u003C\u002Fcode> กับ \u003Ccode>node gateway.js\u003C\u002Fcode> แล้วลองยิงด้วย curl ผลที่ได้จริงจากเครื่องเราเป็นแบบนี้\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">$ curl -s localhost:8080\u002Fusers -H \"x-api-key: demo-key\"\n{\"service\":\"users-service\",\"path\":\"\u002Fusers\",\"data\":[{\"id\":1,\"name\":\"Nok\"}]}\n\n$ curl -s localhost:8080\u002Forders -H \"x-api-key: demo-key\"\n{\"service\":\"orders-service\",\"path\":\"\u002Forders\",\"data\":[{\"id\":101,\"item\":\"Pad Thai\"}]}\n\n$ curl -s -w ' %{http_code}\\n' localhost:8080\u002Fusers\n{\"error\":\"missing or wrong x-api-key\"} 401\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>URL เดียวคือ \u003Ccode>localhost:8080\u003C\u002Fcode> แต่ \u003Ccode>\u002Fusers\u003C\u002Fcode> กับ \u003Ccode>\u002Forders\u003C\u002Fcode> ไปถึงคนละ service และ request ที่ไม่มี key โดนตีกลับที่ gateway โดยไม่ถึง service เลย ต่อไปรอให้ครบ 10 วินาทีแล้วยิงรัวห้าครั้ง\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">$ for i in 1 2 3 4 5; do curl -s -o \u002Fdev\u002Fnull -w \"call $i: %{http_code}\\n\" localhost:8080\u002Forders -H \"x-api-key: demo-key\"; done\ncall 1: 200\ncall 2: 200\ncall 3: 200\ncall 4: 429\ncall 5: 429\n\n$ curl -si localhost:8080\u002Forders -H \"x-api-key: demo-key\" | grep -E \"HTTP|Retry\"\nHTTP\u002F1.1 429 Too Many Requests\nRetry-After: 10\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>สามครั้งแรกผ่าน ครั้งที่สี่เป็นต้นไปได้ 429 พร้อม \u003Ccode>Retry-After: 10\u003C\u002Fcode> ตามที่ RFC 6585 แนะนำ ส่วน log ฝั่ง gateway มีครบห้าบรรทัดของ request ที่ส่งต่อสำเร็จ (สองครั้งแรก บวกสามครั้งที่ผ่านในลูป) ส่วน request ที่โดน 401 หรือ 429 ไม่ถึง service เลยจึงไม่มีในบรรทัดเหล่านี้\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">gateway on :8080\nGET \u002Fusers -> http:\u002F\u002Flocalhost:4001 200\nGET \u002Forders -> http:\u002F\u002Flocalhost:4002 200\nGET \u002Forders -> http:\u002F\u002Flocalhost:4002 200\nGET \u002Forders -> http:\u002F\u002Flocalhost:4002 200\nGET \u002Forders -> http:\u002F\u002Flocalhost:4002 200\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>ต้องบอกตรงๆ ว่าโค้ดนี้มีไว้ให้เห็นกลไก ไม่ใช่ให้เอาขึ้น production ตัวนับ rate limit เก็บในหน่วยความจำของ process เดียว ถ้ารัน gateway สองเครื่อง แต่ละเครื่องจะนับแยกกัน ระบบจริงจึงมักเก็บตัวนับไว้ในที่กลางอย่าง Redis หรือใช้ gateway สำเร็จรูป ถ้าอยากเห็นการทำ rate limiting แบบละเอียดขึ้นในภาษา Go อ่านต่อได้ที่ \u003Ca href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002Fgolang-rate-limiting-ai-requests\" target=\"_blank\" rel=\"noopener noreferrer\">Golang The Series EP.164: Rate Limiting AI Requests\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>API Gateway มีตัวไหนบ้าง\u003C\u002Fh2>\n\u003Cp>ในงานจริงแทบไม่มีใครเขียน gateway เองตั้งแต่ศูนย์ ตัวที่เจอบ่อยมีทั้งแบบติดตั้งเองและแบบบริการบนคลาวด์\u003C\u002Fp>\n\n\u003Ch3>Kong API Gateway คืออะไร\u003C\u002Fh3>\n\u003Cp>Kong ระบุใน \u003Ca href=\"https:\u002F\u002Fdeveloper.konghq.com\u002Fgateway\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">เอกสารของ Kong Gateway\u003C\u002Fa> ว่าเป็น API gateway แบบ cloud-native ที่ตั้งอยู่หน้า RESTful API ใดก็ได้ และขยายความสามารถผ่านโมดูลและ plugin เช่น rate limiting หรือ authentication ติดตั้งได้ทั้งบนเครื่องของเราเองและใช้แบบ managed ผ่าน Konnect\u003C\u002Fp>\n\n\u003Ch3>AWS API Gateway คืออะไร\u003C\u002Fh3>\n\u003Cp>Amazon API Gateway คือบริการของ AWS สำหรับสร้าง เผยแพร่ ดูแล และป้องกัน API แบบ REST, HTTP และ WebSocket ใช้คู่กับ AWS Lambda บ่อยมาก จุดที่ควรรู้คือ REST API มี integration timeout ตั้งได้ตั้งแต่ 50 มิลลิวินาทีถึง 29 วินาที ถ้า service ข้างหลังตอบไม่ทัน gateway จะตอบกลับด้วยสถานะ \u003Cstrong>504\u003C\u002Fstrong> (ประเภท INTEGRATION_TIMEOUT ในเอกสาร AWS)\u003C\u002Fp>\n\n\u003Ch3>NGINX และ Reverse Proxy ทั่วไป\u003C\u002Fh3>\n\u003Cp>Microsoft จัด NGINX และ HAProxy ไว้ในกลุ่ม Reverse Proxy แบบ open source ที่เอามาทำหน้าที่ API Gateway ได้ เพราะรองรับ load balancing, SSL termination และ routing แบบ Layer 7 อยู่แล้ว ส่วนฝั่ง Azure มี Azure API Management และ Azure Application Gateway ให้เลือกตามงาน\u003C\u002Fp>\n\n\u003Ch2>API Gateway vs Load Balancer vs Reverse Proxy ต่างกันอย่างไร\u003C\u002Fh2>\n\u003Cp>สามคำนี้สับสนกันบ่อยที่สุด เพราะทั้งสามอย่างนั่งอยู่ระหว่าง client กับเซิร์ฟเวอร์เหมือนกัน วิธีแยกที่แม่นที่สุดคือดูว่าแต่ละตัวถูกออกแบบมาเพื่อตอบคำถามอะไร\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Reverse Proxy:\u003C\u002Fstrong> กลไกพื้นฐาน คือเซิร์ฟเวอร์ที่รับ request แทน backend แล้วส่งต่อ เอกสาร NGINX บอกว่า proxy มักใช้เพื่อกระจายโหลดไปหลายเซิร์ฟเวอร์ แสดงเนื้อหาจากหลายเว็บ หรือส่ง request ต่อให้ application server ผ่านโปรโตคอลอื่นนอกจาก HTTP\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Load Balancer:\u003C\u002Fstrong> ตอบคำถามว่า \"เครื่องไหนว่าง\" AWS อธิบาย Elastic Load Balancing ว่ากระจาย traffic ไปยังหลายเป้าหมาย ตรวจ health check และส่ง traffic ไปเฉพาะเป้าหมายที่ยังปกติ ปกติใช้กับ service เดียวกันที่รันหลายสำเนา\u003C\u002Fli>\n\u003Cli>\u003Cstrong>API Gateway:\u003C\u002Fstrong> ตอบคำถามว่า \"request นี้คือใคร ได้สิทธิ์ไหม และต้องไป service ไหน\" Kong เขียนไว้ตรงๆ ว่า API gateway คือ Reverse Proxy ที่ให้เราจัดการ ตั้งค่า และ route request ไปยัง API ได้ คือเป็น Reverse Proxy ที่เพิ่มงานระดับ API เข้าไป\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>สรุปความสัมพันธ์คือ API Gateway เป็น Reverse Proxy ชนิดหนึ่งเสมอ แต่ Reverse Proxy ไม่จำเป็นต้องเป็น API Gateway และสองหน้าที่นี้ซ้อนกันได้ เช่น Microsoft ระบุว่า Azure API Management ไม่ทำ load balancing เอง จึงควรใช้คู่กับ load balancer อย่าง Azure Application Gateway ในระบบจริงจึงเห็นได้ทั้งแบบ load balancer อยู่หน้า gateway หลายตัว และแบบ gateway ส่งต่อไปยัง load balancer ของแต่ละ service ลำดับไม่ได้ตายตัว ขึ้นกับสถาปัตยกรรม ถ้าอยากเห็นฝั่ง load balancing ลงมือจริงด้วย Go มีอธิบายไว้ใน Golang The Series EP.165 เช่นกัน\u003C\u002Fp>\n\n\u003Ch2>ระบบเล็กจำเป็นต้องมี API Gateway ไหม\u003C\u002Fh2>\n\u003Cp>จริงๆ แล้วยังไม่จำเป็น และหลายกรณีไม่ควรมีด้วย\u003C\u002Fp>\n\u003Cp>ถ้าแอปของคุณมี backend ตัวเดียว หน้าแอปเรียก URL เดียวอยู่แล้ว การใส่ gateway เพิ่มคือการเพิ่มอีกหนึ่ง hop เพิ่มอีกหนึ่งระบบที่ต้องดูแล โดยไม่ได้แก้ปัญหาอะไร Microsoft เองเขียนไว้ใน Gateway Routing pattern ว่ารูปแบบนี้อาจไม่เหมาะเมื่อแอปเรียบง่ายและใช้แค่หนึ่งหรือสอง service\u003C\u002Fp>\n\u003Cp>แต่ต้องรู้ด้วยว่า gateway มีราคาของมัน เอกสารเดียวกันเตือนว่า gateway อาจกลายเป็น single point of failure (จุดที่ถ้าล่มแล้วทั้งระบบล่ม) และอาจกลายเป็นคอขวดถ้ารับโหลดไม่ไหว ทางแก้คือรัน gateway หลายตัว ทำ load test และจำกัดไม่ให้ service ข้างหลังเปิดรับ request จากภายนอกโดยตรง ให้ทุกอย่างต้องผ่าน gateway เท่านั้น\u003C\u002Fp>\n\u003Cp>สัญญาณที่บอกว่าถึงเวลาแล้วคือสิ่งที่เห็นในแอปสั่งอาหารตอนต้น: หน้าแอปต้องจำหลาย URL, ทุก service เขียนโค้ดตรวจ login ซ้ำกัน, และการย้าย service ทีหนึ่งต้องแก้หน้าแอปตาม\u003C\u002Fp>\n\n\u003Chr>\n\u003Ch2>สรุป: API Gateway คืออะไร และควรเริ่มใช้เมื่อไหร่\u003C\u002Fh2>\n\u003Cp>API Gateway คือประตูทางเข้าเดียวหน้า backend หลาย service ทำหน้าที่ routing, ตรวจตัวตน, จำกัดจำนวนครั้งด้วย 429, ถอดรหัส TLS, ปรับข้อมูลระหว่างทาง และเก็บ log ไว้ในที่เดียว มันเป็น Reverse Proxy ชนิดหนึ่งที่เพิ่มงานระดับ API เข้าไป และทำงานคนละโจทย์กับ Load Balancer ที่ดูแลการกระจายโหลดไปหลายเครื่อง\u003C\u002Fp>\n\u003Cp>ถ้าวันนี้ระบบของคุณยังมี backend ตัวเดียว ยังไม่ต้องรีบ แต่ลองเอาโค้ด gateway 57 บรรทัดข้างบนไปรันเล่น เพิ่ม route ที่สาม เปลี่ยนเพดาน rate limit แล้วดูว่า 429 เปลี่ยนตามยังไง พอวันที่แอปของคุณแตกเป็นหลาย service จริง คุณจะรู้ทันทีว่า gateway ตัวจริงอย่าง Kong หรือ Amazon API Gateway กำลังทำอะไรให้อยู่\u003C\u002Fp>\n\u003Cp>ติดตามบทความและเทคนิคสำหรับคนเริ่มต้นสายโปรแกรมเมอร์ได้ที่ช่องทางของเรา\u003C\u002Fp>\u003Cp>Facebook: \u003Cstrong>Superdev Academy Thailand\u003C\u002Fstrong> (\u003Ca href=\"https:\u002F\u002Fwww.facebook.com\u002Fsuperdev.academy.th\" target=\"_blank\" rel=\"noopener noreferrer\">https:\u002F\u002Fwww.facebook.com\u002Fsuperdev.academy.th\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>YouTube: \u003Cstrong>Superdev Academy Channel\u003C\u002Fstrong> (\u003Ca href=\"https:\u002F\u002Fwww.youtube.com\u002F@SuperdevAcademy\" target=\"_blank\" rel=\"noopener noreferrer\">https:\u002F\u002Fwww.youtube.com\u002F@SuperdevAcademy\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>Instagram: \u003Cstrong>@superdevacademy\u003C\u002Fstrong> (\u003Ca href=\"https:\u002F\u002Fwww.instagram.com\u002Fsuperdevacademy\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">https:\u002F\u002Fwww.instagram.com\u002Fsuperdevacademy\u002F\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>TikTok: \u003Cstrong>@superdevacademy\u003C\u002Fstrong> (\u003Ca href=\"https:\u002F\u002Fwww.tiktok.com\u002F@superdevacademy?lang=th-TH\" target=\"_blank\" rel=\"noopener noreferrer\">https:\u002F\u002Fwww.tiktok.com\u002F@superdevacademy?lang=th-TH\u003C\u002Fa>)\u003C\u002Fp>\n","cover_cover_1iglh3zj00.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002F1qb51d8fsukjrf4\u002Fl\u002Fcover_cover_1iglh3zj00.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002F1qb51d8fsukjrf4\u002Fm\u002Fcover_cover_1iglh3zj00.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002F1qb51d8fsukjrf4\u002Fcover_cover_1iglh3zj00.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002F1qb51d8fsukjrf4\u002Fs\u002Fcover_cover_1iglh3zj00.webp","2026-10-01 06:31:29.672Z","wfztm6bp9384v3u",{"keywords":18,"locale":52,"school_blog":62},[19,27,31,35,39,43,47],{"collectionId":20,"collectionName":21,"created":22,"created_by":23,"id":24,"name":25,"updated":26,"updated_by":23},"sclkey987654321","school_keywords","2026-03-04 08:51:21.416Z","76qprkevbgfdps8","t0608colrvvnvt5","API Gateway","2026-06-07 06:48:49.331Z",{"collectionId":20,"collectionName":21,"created":28,"created_by":16,"id":29,"name":30,"updated":28,"updated_by":16},"2026-10-01 06:31:29.659Z","dkvi2x7jruwbrev","API Gateway คืออะไร",{"collectionId":20,"collectionName":21,"created":32,"created_by":16,"id":33,"name":34,"updated":32,"updated_by":16},"2026-10-01 06:31:29.663Z","pihyfgqf68pg52b","Kong API Gateway",{"collectionId":20,"collectionName":21,"created":36,"created_by":16,"id":37,"name":38,"updated":36,"updated_by":16},"2026-10-01 06:31:29.664Z","muuvwomr7fl8qyf","AWS API Gateway",{"collectionId":20,"collectionName":21,"created":40,"created_by":16,"id":41,"name":42,"updated":40,"updated_by":16},"2026-10-01 06:31:29.665Z","y703hm3gfg5bk88","API Gateway vs Load Balancer",{"collectionId":20,"collectionName":21,"created":44,"created_by":16,"id":45,"name":46,"updated":44,"updated_by":16},"2026-10-01 06:31:29.666Z","fiu33iuo39fbp6j","Reverse Proxy",{"collectionId":20,"collectionName":21,"created":48,"created_by":23,"id":49,"name":50,"updated":51,"updated_by":23},"2026-03-04 08:34:07.915Z","921nl48h9in67sw","Rate Limiting","2026-06-07 06:45:58.705Z",{"code":53,"collectionId":54,"collectionName":55,"created":56,"flag":57,"id":58,"is_default":59,"label":60,"updated":61},"th","pbc_1989393366","locales","2026-01-22 10:59:55.832Z","twemoji:flag-thailand","s8wri3bt4vgg2ji",true,"Thai","2026-04-10 15:42:46.614Z",{"category":63,"collectionId":64,"collectionName":65,"created":66,"expand":67,"id":83,"slug":84,"updated":85,"views":86},"rfxf19ot4iq992c","pbc_2105096300","school_blogs","2026-10-01 06:31:29.667Z",{"category":68},{"blogIds":69,"collectionId":70,"collectionName":71,"created":72,"created_by":23,"id":63,"image":73,"image_alt":74,"image_path":75,"image_s_url":76,"label":77,"name":78,"priority":79,"publish_at":80,"scheduled_at":74,"status":81,"updated":82,"updated_by":23},[],"sclcatblg987654321","school_category_blogs","2026-03-04 08:32:03.969Z","7acfigk1qkd_lv1k6bkji3_7h89h9h63a.webp","","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclcatblg987654321\u002Frfxf19ot4iq992c\u002F7acfigk1qkd_lv1k6bkji3_7h89h9h63a.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclcatblg987654321\u002Frfxf19ot4iq992c\u002Fs\u002F7acfigk1qkd_lv1k6bkji3_7h89h9h63a.webp",{"en":78,"th":78},"Web Development",0,"2025-01-21 03:43:00.282Z","published","2026-08-18 14:48:42.218Z","pnc822055yw3k99","what-is-api-gateway","2026-10-30 08:55:25.687Z",117,"1qb51d8fsukjrf4",[24,29,33,37,41,45,49],"2026-10-30 06:29:49.075Z","API Gateway คืออะไร มีหน้าที่อะไรบ้าง ต่างจาก Load Balancer และ Reverse Proxy ยังไง พร้อมตัวอย่าง gateway ด้วย Node.js ที่ routing \u002Fusers, \u002Forders และตอบ 429","API Gateway คืออะไร มีอะไรบ้าง ต่างจาก Load Balancer ยังไง","2026-10-30 06:29:49.077Z","ebkf8ra4nd55ual",1,[96,100,104,108,112,116],{"answer":97,"id":98,"question":99},"API Gateway คือเซิร์ฟเวอร์ตัวกลางที่เป็นประตูทางเข้าเดียวหน้า backend หลาย service ทุก request จากแอปหรือเว็บวิ่งมาที่ gateway ก่อน gateway ตรวจตัวตน จำกัดจำนวนครั้ง แล้วส่งต่อตาม path เช่น \u002Fusers ไป users-service และ \u002Forders ไป orders-service ตัวที่ใช้กันบ่อยในงานจริงคือ Kong Gateway, Amazon API Gateway และ NGINX","56umm24wv70a1vt","API Gateway คืออะไร อธิบายแบบง่ายๆ",{"answer":101,"id":102,"question":103},"API Gateway มีหน้าที่หลัก 6 อย่าง คือ routing ส่ง request ไปให้ถูก service, authentication ตรวจ token หรือ API Key, rate limiting ตอบ 429 Too Many Requests เมื่อยิงเกินโควตา, TLS termination ถอดรหัส HTTPS ที่หน้าประตู, request\u002Fresponse transformation และ logging แต่ละผลิตภัณฑ์รองรับแต่ละข้อไม่เท่ากัน ควรเช็กเอกสารของตัวที่เลือกก่อนใช้งาน","wd41bwa800swmpc","API Gateway มีหน้าที่อะไรบ้าง",{"answer":105,"id":106,"question":107},"Load Balancer กระจาย traffic ไปหลายเครื่องที่รัน service เดียวกัน และส่งไปเฉพาะเครื่องที่ผ่าน health check ส่วน API Gateway ตัดสินว่า request นี้คือใคร มีสิทธิ์ไหม และต้องไป service ไหน ทั้งสองใช้ร่วมกันได้ เช่น Microsoft แนะนำให้ใช้ Azure API Management คู่กับ load balancer เพราะ Azure API Management ไม่ทำ load balancing เอง","bfio18h67sge91f","API Gateway กับ Load Balancer ต่างกันยังไง",{"answer":109,"id":110,"question":111},"API Gateway คือ Reverse Proxy ชนิดหนึ่งที่เพิ่มงานระดับ API เข้าไป เอกสาร Kong Gateway นิยามว่า API gateway คือ reverse proxy ที่ใช้จัดการ ตั้งค่า และ route request ไปยัง API ส่วน Reverse Proxy ทั่วไปอย่าง NGINX ทำหน้าที่รับ request แทน backend แล้วส่งต่อ และจะทำงานแบบ gateway ได้เมื่อตั้งค่าการตรวจตัวตนและ rate limiting เพิ่มเข้าไป","sskl7zjbeh6o8d8","API Gateway กับ Reverse Proxy ต่างกันยังไง",{"answer":113,"id":114,"question":115},"Kong Gateway คือ API gateway แบบ cloud-native ที่วางไว้หน้า RESTful API ใดก็ได้ ตามคำอธิบายในเอกสารของ Kong ความสามารถส่วนใหญ่เพิ่มผ่าน plugin เช่น Rate Limiting และ Key Auth ติดตั้งบนเซิร์ฟเวอร์ของเราเองได้ หรือใช้แบบ managed ผ่าน Kong Konnect และ Kong ระบุว่าออกแบบมาให้รันได้ทั้งแบบ hybrid-cloud และ multi-cloud","b699esk381rdi7r","Kong API Gateway คืออะไร",{"answer":117,"id":118,"question":119},"API Gateway timeout คือกรณีที่ gateway รอคำตอบจาก service ข้างหลังนานเกินเวลาที่ตั้งไว้ แล้วตอบ client ด้วยสถานะ 504 Gateway Timeout ตามความหมายใน RFC 9110 สำหรับ Amazon API Gateway แบบ REST API ค่า integration timeout ตั้งได้ตั้งแต่ 50 มิลลิวินาทีถึง 29 วินาที ถ้าเจอบ่อยให้หาก่อนว่า service ข้างหลังช้าตรงไหน แทนการเพิ่ม timeout อย่างเดียว","i0o1kfdbuvd7psc","API Gateway timeout คืออะไร",{"th":84,"en":84}]