การกำหนดเส้นทางตามภูมิศาสตร์ด้วย Frontend Edge Function: คู่มือการกระจายคำขอตามตำแหน่งที่ตั้ง

ในโลกที่เชื่อมต่อถึงกันในปัจจุบัน การสร้างแอปพลิเคชันสำหรับผู้ใช้ทั่วโลกไม่ใช่ทางเลือกอีกต่อไป แต่เป็นสิ่งจำเป็น อย่างไรก็ตาม ฐานผู้ใช้ทั่วโลกก็นำมาซึ่งความท้าทายที่ไม่เหมือนใคร: คุณจะส่งมอบเนื้อหาโดยมีความหน่วง (latency) น้อยที่สุดไปยังผู้ใช้ในโตเกียวและอีกคนในเบอร์ลินได้อย่างไร? คุณจะปฏิบัติตามกฎหมายคุ้มครองข้อมูลส่วนบุคคลในภูมิภาค เช่น GDPR ในยุโรปได้อย่างไร? คุณจะนำเสนอเนื้อหาที่ปรับให้เข้ากับท้องถิ่น เช่น สกุลเงินและภาษา ที่ให้ความรู้สึกเป็นธรรมชาติสำหรับผู้ใช้แต่ละคนได้อย่างไร? คำตอบอยู่ที่ขอบของเครือข่าย (edge of the network)

ยินดีต้อนรับสู่โลกของ การกำหนดเส้นทางตามภูมิศาสตร์ด้วย Frontend Edge Function กระบวนทัศน์อันทรงพลังนี้ผสมผสานการทำงานที่ความหน่วงต่ำของ edge functions เข้ากับความชาญฉลาดของตรรกะตามตำแหน่งที่ตั้ง เพื่อสร้างประสบการณ์ผู้ใช้ที่เร็วขึ้น สอดคล้องกับข้อกำหนดมากขึ้น และเป็นส่วนตัวอย่างสูง โดยการดักจับคำขอที่ขอบของเครือข่าย ซึ่งอยู่ใกล้กับผู้ใช้ทางกายภาพมากขึ้น นักพัฒนาสามารถตัดสินใจกำหนดเส้นทางแบบไดนามิกได้ก่อนที่คำขอจะไปถึงเซิร์ฟเวอร์ต้นทาง (origin server) ที่อยู่ส่วนกลาง

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

การกำหนดเส้นทางตามภูมิศาสตร์ (Geographic Routing) คืออะไร?

โดยแก่นแท้แล้ว Geographic Routing (หรือ geo-routing) คือการส่งทราฟฟิกเครือข่ายไปยังปลายทางต่างๆ โดยขึ้นอยู่กับตำแหน่งทางภูมิศาสตร์ของผู้ใช้ที่ส่งคำขอ เปรียบเสมือนผู้ควบคุมการจราจรอัจฉริยะสำหรับอินเทอร์เน็ต เพื่อให้แน่ใจว่าคำขอของผู้ใช้แต่ละคนจะถูกส่งไปยังเซิร์ฟเวอร์หรือบริการที่เหมาะสมที่สุดเพื่อดำเนินการให้สำเร็จ

แนวทางดั้งเดิมเทียบกับการปฏิวัติที่ Edge

ในอดีต การกำหนดเส้นทางตามภูมิศาสตร์ส่วนใหญ่จะถูกจัดการที่ระดับ DNS เทคนิคที่เรียกว่า GeoDNS จะแปลงชื่อโดเมนเป็นที่อยู่ IP ที่แตกต่างกัน ขึ้นอยู่กับว่าการสืบค้น DNS (DNS query) มาจากที่ใด ตัวอย่างเช่น ผู้ใช้ในเอเชียจะได้รับที่อยู่ IP ของเซิร์ฟเวอร์ในสิงคโปร์ ในขณะที่ผู้ใช้ในยุโรปจะถูกส่งไปยังเซิร์ฟเวอร์ในแฟรงก์เฟิร์ต

แม้ว่าจะมีประสิทธิภาพในการส่งทราฟฟิกไปยังศูนย์ข้อมูลระดับภูมิภาคต่างๆ แต่การกำหนดเส้นทางโดยใช้ DNS ก็มีข้อจำกัด:

• ขาดความละเอียด: DNS ทำงานในระดับสูง ไม่สามารถตรวจสอบ header ของคำขอแต่ละรายการหรือตัดสินใจโดยอิงจากสิ่งอื่นนอกเหนือจากแหล่งที่มาของ DNS query ได้
• ความล่าช้าจากการแคช: ระเบียน DNS ถูกแคชอย่างหนักทั่วทั้งอินเทอร์เน็ต การเปลี่ยนแปลงอาจใช้เวลาหลายนาทีหรือหลายชั่วโมงในการเผยแพร่ทั่วโลก ทำให้ไม่เหมาะสำหรับการกำหนดเส้นทางแบบไดนามิกแบบเรียลไทม์
• ความไม่แม่นยำ: ตำแหน่งจะขึ้นอยู่กับ DNS resolver ของผู้ใช้ ซึ่งอาจไม่สะท้อนตำแหน่งที่แท้จริงของผู้ใช้ (เช่น การใช้ DNS สาธารณะอย่าง 8.8.8.8 ของ Google)

Edge functions ปฏิวัติกระบวนการนี้ แทนที่จะกำหนดเส้นทางที่ระดับ DNS ตรรกะจะถูกดำเนินการกับทุกๆ คำขอ HTTP ที่ Point of Presence (PoP) ของ Content Delivery Network (CDN) สิ่งนี้ให้แนวทางที่มีประสิทธิภาพและยืดหยุ่นกว่ามาก ช่วยให้สามารถตัดสินใจแบบเรียลไทม์ต่อคำขอได้โดยอิงจากข้อมูลตำแหน่งที่แม่นยำซึ่งผู้ให้บริการจัดหาให้

พลังของ Edge: ทำไม Edge Functions จึงเป็นเครื่องมือที่สมบูรณ์แบบ

เพื่อที่จะเข้าใจว่าทำไม edge functions ถึงมีประสิทธิภาพ คุณต้องเข้าใจคำว่า "edge" ก่อน The edge คือเครือข่ายเซิร์ฟเวอร์ทั่วโลกที่ตั้งอยู่ในศูนย์ข้อมูลทั่วโลกอย่างมีกลยุทธ์ เมื่อผู้ใช้เข้าชมเว็บไซต์ของคุณ คำขอของพวกเขาจะถูกจัดการโดยเซิร์ฟเวอร์ที่อยู่ใกล้พวกเขามากที่สุด ไม่ใช่เซิร์ฟเวอร์ส่วนกลางที่อยู่ห่างไกล

Edge functions คือโค้ดชิ้นเล็กๆ แบบ serverless (มักเป็น JavaScript/TypeScript) ที่ทำงานบนเครือข่ายนี้ นี่คือเหตุผลว่าทำไมมันจึงเป็นเครื่องมือที่เหมาะสำหรับการกำหนดเส้นทางตามภูมิศาสตร์:

1. ความหน่วงต่ำเป็นพิเศษ (Ultra-Low Latency)

ฟิสิกส์คือคอขวดที่สำคัญที่สุดในประสิทธิภาพของเว็บ เวลาที่ข้อมูลใช้ในการเดินทางข้ามทวีปนั้นมีความสำคัญ การดำเนินการตรรกะการกำหนดเส้นทางที่ edge node ที่ใกล้ที่สุด ทำให้การตัดสินใจเกิดขึ้นในเวลาเพียงไม่กี่มิลลิวินาที ซึ่งหมายความว่าคุณสามารถเปลี่ยนเส้นทางผู้ใช้, rewrite คำขอไปยัง backend ระดับภูมิภาค หรือให้บริการเนื้อหาที่ปรับให้เข้ากับท้องถิ่นได้เกือบจะในทันที โดยไม่มีบทลงโทษจากการเดินทางไปกลับยังเซิร์ฟเวอร์ต้นทางก่อน

2. การควบคุมที่ละเอียดต่อคำขอ

ต่างจาก DNS, edge function สามารถตรวจสอบคำขอ HTTP ที่เข้ามาทั้งหมดได้ ซึ่งรวมถึง headers, cookies, query parameters และอื่นๆ แพลตฟอร์ม edge สมัยใหม่ยังแทรกข้อมูลทางภูมิศาสตร์ที่เชื่อถือได้เข้าไปในคำขอ เช่น ประเทศ ภูมิภาค และเมืองของผู้ใช้ สิ่งนี้ช่วยให้สามารถสร้างกฎที่มีความละเอียดสูงได้อย่างไม่น่าเชื่อ เช่น การกำหนดเส้นทางผู้ใช้จากเมืองที่ระบุไปยังฟีเจอร์เบต้า หรือการบล็อกทราฟฟิกจากภูมิภาคที่ถูกคว่ำบาตร

3. ลดภาระและต้นทุนของเซิร์ฟเวอร์ต้นทาง (Origin)

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

4. การผสานรวมอย่างราบรื่นกับเฟรมเวิร์กสมัยใหม่

แพลตฟอร์มอย่าง Vercel, Netlify และ Cloudflare ได้ผสานรวม edge functions เข้ากับเวิร์กโฟลว์การพัฒนาของพวกเขาอย่างแน่นหนา ด้วยเฟรมเวิร์กอย่าง Next.js, Nuxt หรือ SvelteKit การนำตรรกะของ edge มาใช้สามารถทำได้ง่ายเพียงแค่เพิ่มไฟล์ `middleware.ts` ลงในโปรเจกต์ของคุณ ทำให้เข้าถึงได้โดยนักพัฒนา frontend โดยไม่ต้องมีความเชี่ยวชาญด้าน DevOps อย่างลึกซึ้ง

การทำงานของการกำหนดเส้นทางตามภูมิศาสตร์ด้วย Edge Functions: การแจกแจงทีละขั้นตอน

ลองติดตามการเดินทางของคำขอของผู้ใช้เพื่อทำความเข้าใจกลไกของการกำหนดเส้นทางตามภูมิศาสตร์บน edge

1. ผู้ใช้เริ่มส่งคำขอ: ผู้ใช้ในลอนดอน สหราชอาณาจักร พิมพ์ URL เว็บไซต์ของคุณลงในเบราว์เซอร์
2. คำขอไปถึง Edge Node ที่ใกล้ที่สุด: คำขอไม่ได้เดินทางไปจนถึงเซิร์ฟเวอร์ในสหรัฐอเมริกา แต่จะถูกดักจับโดย Point of Presence (PoP) ที่ใกล้ที่สุด ซึ่งน่าจะอยู่ในลอนดอน
3. Edge Function ถูกเรียกใช้: แพลตฟอร์ม edge ตรวจพบว่าคุณได้กำหนดค่า edge function สำหรับ path นี้ โค้ดของฟังก์ชันจะถูกดำเนินการทันที
4. เข้าถึงข้อมูลตำแหน่งที่ตั้ง: แพลตฟอร์มจะให้ข้อมูลตำแหน่งของผู้ใช้แก่ฟังก์ชันโดยอัตโนมัติ โดยทั่วไปผ่าน request headers พิเศษ (เช่น `x-vercel-ip-country: 'GB'`, `cf-ipcountry: 'GB'`) หรืออ็อบเจ็กต์ `request.geo`
5. ตรรกะการกำหนดเส้นทางถูกนำไปใช้: โค้ดของคุณจะเริ่มทำงานตามตรรกะ มันจะตรวจสอบรหัสประเทศ ตัวอย่างเช่น:

               if (country === 'GB') { ... }
               
   
                 
                   Copy
                 
               
             

6. ดำเนินการ: ตามตรรกะ ฟังก์ชันสามารถดำเนินการได้หลายอย่าง:
   • Rewrite ไปยัง Backend ระดับภูมิภาค: ฟังก์ชันสามารถส่งต่อคำขอไปยังเซิร์ฟเวอร์อื่นอย่างเงียบๆ เช่น `https://api.eu.your-service.com` โดยไม่เปลี่ยน URL ในเบราว์เซอร์ของผู้ใช้ เหมาะอย่างยิ่งสำหรับการปฏิบัติตามข้อกำหนดด้านถิ่นที่อยู่ของข้อมูล (data residency)
   • Redirect ไปยัง URL ที่ปรับให้เข้ากับท้องถิ่น: ฟังก์ชันสามารถส่งคืน response เป็น 307 (Temporary Redirect) หรือ 308 (Permanent Redirect) เพื่อส่งผู้ใช้ไปยังเวอร์ชันของไซต์ที่ปรับให้เข้ากับท้องถิ่น เช่น `https://your-site.co.uk`
   • แก้ไข Response: ฟังก์ชันสามารถดึงเนื้อหาต้นฉบับจาก origin จากนั้นแก้ไขเนื้อหานั้นได้ทันทีเพื่อแทรกเนื้อหา ราคา หรือสตริงภาษาที่ปรับให้เข้ากับท้องถิ่นก่อนที่จะส่งไปยังผู้ใช้
   • บล็อกคำขอ: หากผู้ใช้มาจากภูมิภาคที่ถูกจำกัด ฟังก์ชันสามารถส่งคืน response เป็น 403 (Forbidden) เพื่อป้องกันการเข้าถึงทั้งหมด
   • ให้บริการจากแคช: หากเวอร์ชันของหน้าที่ปรับให้เข้ากับท้องถิ่นมีอยู่ในแคชของ edge แล้ว ก็สามารถให้บริการได้โดยตรง ซึ่งให้การตอบสนองที่เร็วที่สุดเท่าที่จะเป็นไปได้

กระบวนการทั้งหมดนี้เกิดขึ้นอย่างโปร่งใสสำหรับผู้ใช้และในเวลาเพียงเสี้ยววินาที ส่งผลให้เกิดประสบการณ์ที่ราบรื่นและมีประสิทธิภาพสูงสุด

กรณีการใช้งานจริงและตัวอย่างระหว่างประเทศ

พลังที่แท้จริงของการกำหนดเส้นทางตามภูมิศาสตร์จะเห็นได้ชัดเจนในการใช้งานจริง ลองสำรวจกรณีการใช้งานที่พบบ่อยและมีผลกระทบมากที่สุดสำหรับธุรกิจระดับโลก

กรณีศึกษาที่ 1: การปรับ E-commerce ให้เข้ากับท้องถิ่น

ความท้าทาย: ร้านค้าปลีกออนไลน์ระดับโลกต้องการมอบประสบการณ์การช็อปปิ้งที่ปรับให้เข้ากับท้องถิ่น ซึ่งรวมถึงการแสดงราคาในสกุลเงินท้องถิ่น การแสดงสินค้าที่เกี่ยวข้อง และการใช้ภาษาที่ถูกต้อง

โซลูชันด้วย Edge:

1. edge function จะตรวจสอบคุณสมบัติ `geo.country` ของคำขอที่เข้ามา
2. หากประเทศคือ 'JP' (ญี่ปุ่น) ระบบจะ redirect ผู้ใช้จาก `mystore.com` ไปยัง `mystore.com/jp`
3. หน้า `/jp` จะถูกเรนเดอร์ฝั่งเซิร์ฟเวอร์ (server-rendered) พร้อมราคาในสกุลเงินเยน (¥) และเนื้อหาเป็นภาษาญี่ปุ่น
4. หากประเทศคือ 'DE' (เยอรมนี) ฟังก์ชันจะ rewrite คำขอไปยังเวอร์ชันของหน้าที่ดึงข้อมูลผลิตภัณฑ์จากฐานข้อมูลสินค้าคงคลังของยุโรปและแสดงราคาเป็นยูโร (€) สิ่งนี้เกิดขึ้นโดยไม่มีการเปลี่ยนแปลง URL ที่มองเห็นได้ ทำให้ผู้ใช้ได้รับประสบการณ์ที่ราบรื่น

ผลลัพธ์: อัตราการแปลง (conversion rates) ที่สูงขึ้น ความไว้วางใจของผู้ใช้ที่เพิ่มขึ้น และการมีตัวตนในระดับโลกที่เป็นมืออาชีพมากขึ้น

กรณีศึกษาที่ 2: อธิปไตยทางข้อมูลและการปฏิบัติตาม GDPR

ความท้าทาย: บริษัท SaaS ให้บริการทั่วโลก แต่ต้องปฏิบัติตามกฎระเบียบคุ้มครองข้อมูลทั่วไปของสหภาพยุโรป (GDPR) ซึ่งมีกฎเกณฑ์ที่เข้มงวดเกี่ยวกับสถานที่จัดเก็บและประมวลผลข้อมูลของพลเมือง EU

โซลูชันด้วย Edge:

1. edge function จะตรวจสอบ `geo.country` ของทุกคำขอ API
2. มีการรักษารายชื่อประเทศในสหภาพยุโรป: `['FR', 'DE', 'ES', 'IE', ...]`
3. หากประเทศของผู้ใช้อยู่ในรายชื่อ EU ฟังก์ชันจะ rewrite URL ของคำขอภายในจาก `api.mysaas.com` เป็น `api.eu.mysaas.com`
4. endpoint `api.eu.mysaas.com` ถูกโฮสต์บนเซิร์ฟเวอร์ที่ตั้งอยู่จริงภายในสหภาพยุโรป (เช่น ในแฟรงก์เฟิร์ตหรือดับลิน)
5. คำขอจากภูมิภาคอื่นๆ ทั้งหมด (เช่น 'US', 'CA', 'AU') จะถูกส่งไปยัง backend ทั่วไปที่โฮสต์ในสหรัฐอเมริกา

ผลลัพธ์: บริษัทบรรลุการปฏิบัติตามกฎระเบียบ หลีกเลี่ยงค่าปรับจำนวนมาก และสร้างความไว้วางใจกับลูกค้าชาวยุโรปโดยแสดงให้เห็นถึงความมุ่งมั่นในการรักษาความเป็นส่วนตัวของข้อมูล

กรณีศึกษาที่ 3: การเพิ่มประสิทธิภาพสำหรับเกมออนไลน์

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

โซลูชันด้วย Edge:

1. เมื่อไคลเอนต์เกมเริ่มทำงาน จะมีการส่งคำขอ "matchmaking" ไปยัง API endpoint ระดับโลก
2. edge function จะดักจับคำขอนี้ และระบุตำแหน่งของผู้ใช้ (`geo.country` และ `geo.region`)
3. ฟังก์ชันจะรักษาการจับคู่ระหว่างภูมิภาคทางภูมิศาสตร์กับที่อยู่ IP ของเซิร์ฟเวอร์เกมที่ใกล้ที่สุด: `{'us-east': '1.2.3.4', 'eu-west': '5.6.7.8', 'ap-southeast': '9.10.11.12'}`
4. ฟังก์ชันจะตอบกลับคำขอ API ด้วยที่อยู่ IP ของเซิร์ฟเวอร์เกมที่เหมาะสมที่สุด
5. ไคลเอนต์เกมจะเชื่อมต่อโดยตรงกับเซิร์ฟเวอร์นั้น

ผลลัพธ์: ประสบการณ์ของผู้เล่นดีขึ้นอย่างมากด้วย lag ที่ลดลง นำไปสู่การรักษาผู้เล่นและความพึงพอใจที่สูงขึ้น

กรณีศึกษาที่ 4: การเปิดตัวแบบค่อยเป็นค่อยไป และ A/B Testing

ความท้าทาย: บริษัทเทคโนโลยีต้องการเปิดตัวฟีเจอร์ใหม่ที่สำคัญ แต่ต้องการทดสอบกับกลุ่มเป้าหมายขนาดเล็กก่อนที่จะเปิดตัวทั่วโลกเพื่อลดความเสี่ยง

โซลูชันด้วย Edge:

1. ฟีเจอร์ใหม่ถูกปรับใช้โดยอยู่เบื้องหลัง feature flag
2. edge function จะตรวจสอบทั้ง cookie (เพื่อดูว่าผู้ใช้ได้เลือกเข้าร่วมหรือไม่) และตำแหน่งของผู้ใช้
3. มีการตั้งค่าตรรกะเพื่อเปิดใช้งานฟีเจอร์สำหรับผู้ใช้ทุกคนในตลาดที่มีความเสี่ยงต่ำกว่า เช่น นิวซีแลนด์ ('NZ') `if (geo.country === 'NZ') { enableFeature(); }`
4. สำหรับผู้ใช้นอกนิวซีแลนด์ จะให้บริการเว็บไซต์เวอร์ชันเก่า
5. เมื่อความมั่นใจในฟีเจอร์เพิ่มขึ้น จะมีการเพิ่มประเทศต่างๆ เข้าไปใน allow-list ใน edge function เพื่อให้สามารถเปิดตัวแบบค่อยเป็นค่อยไปและควบคุมได้

ผลลัพธ์: ลดความเสี่ยงของการหยุดทำงานทั่วโลกจากฟีเจอร์ที่มีข้อบกพร่อง ได้รับข้อเสนอแนะอันมีค่าจากกลุ่มผู้ใช้จริง และการเปิดตัวทั่วโลกที่ราบรื่นยิ่งขึ้น

คู่มือการใช้งาน: ตัวอย่างโค้ด

ทฤษฎีนั้นยอดเยี่ยม แต่มาดูกันว่าในทางปฏิบัติจะเป็นอย่างไร เราจะใช้ไวยากรณ์สำหรับ Next.js Middleware ซึ่งทำงานบน Edge Functions ของ Vercel เนื่องจากเป็นการนำไปใช้ที่ได้รับความนิยมอย่างมาก แนวคิดเหล่านี้สามารถถ่ายทอดไปยังผู้ให้บริการรายอื่น เช่น Cloudflare Workers หรือ Netlify Edge Functions ได้อย่างง่ายดาย

สถานการณ์: เราต้องการสร้างระบบกำหนดเส้นทางที่:

1. Redirect ผู้ใช้ชาวแคนาดา (`/`) ไปยังเว็บไซต์เวอร์ชันแคนาดาโดยเฉพาะ (`/ca`)
2. ส่งต่อคำขอ API ไปยัง `/api/*` ทั้งหมดจากผู้ใช้ในเยอรมนีและฝรั่งเศสไปยัง backend เฉพาะของยุโรปอย่างเงียบๆ
3. บล็อกการเข้าถึงสำหรับผู้ใช้จากประเทศสมมติที่มีรหัส 'XX'

ในโปรเจกต์ Next.js ของคุณ คุณจะต้องสร้างไฟล์ชื่อ `middleware.ts` ที่ระดับราก (หรือภายใน `src/`)

// src/middleware.ts
import { NextRequest, NextResponse } from 'next/server';

// รายการนี้สามารถจัดการได้ในไฟล์ config แยกต่างหากหรือในฐานข้อมูลที่ edge
const EU_COUNTRIES = ['DE', 'FR'];

export const config = {
  // matcher จะระบุว่า middleware นี้จะทำงานบน path ใดบ้าง
  matcher: ['/', '/about', '/api/:path*'],
};

export function middleware(request: NextRequest) {
  // 1. ดึงข้อมูลทางภูมิศาสตร์จาก request
  // อ็อบเจ็กต์ `geo` จะถูกเติมข้อมูลโดยอัตโนมัติโดย Vercel Edge Network
  const { geo } = request;
  const country = geo?.country || 'US'; // กำหนดค่าเริ่มต้นเป็น 'US' หากไม่ทราบตำแหน่ง
  const pathname = request.nextUrl.pathname;

  // 2. LOGIC: บล็อกการเข้าถึงจากประเทศที่ระบุ
  if (country === 'XX') {
    // คืนค่า response เป็น 403 Forbidden
    return new NextResponse(null, { status: 403, statusText: "Forbidden" });
  }

  // 3. LOGIC: Redirect ผู้ใช้ชาวแคนาดาไปยัง sub-path /ca
  // เราตรวจสอบว่าไม่ได้อยู่ใน path /ca อยู่แล้ว เพื่อหลีกเลี่ยงการ redirect วนลูป
  if (country === 'CA' && !pathname.startsWith('/ca')) {
    const url = request.nextUrl.clone();
    url.pathname = `/ca${pathname}`;
    // คืนค่า response เป็น 307 Temporary Redirect
    return NextResponse.redirect(url);
  }

  // 4. LOGIC: Rewrite คำขอ API สำหรับผู้ใช้ใน EU ไปยัง backend ประจำภูมิภาค
  if (pathname.startsWith('/api') && EU_COUNTRIES.includes(country)) {
    const url = new URL(request.url);
    // เปลี่ยน hostname เพื่อชี้ไปยัง origin เฉพาะของ EU
    url.hostname = 'api.eu.your-service.com';
    console.log(`Rewriting API request for user in ${country} to ${url.hostname}`);
    // คืนค่า rewrite URL ในเบราว์เซอร์ของผู้ใช้จะไม่เปลี่ยนแปลง
    return NextResponse.rewrite(url);
  }

  // 5. หากไม่มีกฎใดตรงกัน ให้ส่งคำขอต่อไปยังหน้าเว็บหรือ API route
  return NextResponse.next();
}

การแจกแจงโค้ด:

• `config.matcher`: นี่คือการเพิ่มประสิทธิภาพที่สำคัญ มันบอกให้ edge network เรียกใช้ฟังก์ชันนี้สำหรับ path ที่ระบุเท่านั้น ซึ่งช่วยประหยัดค่าใช้จ่ายในการดำเนินการสำหรับ assets เช่น รูปภาพหรือไฟล์ CSS
• `request.geo`: อ็อบเจ็กต์นี้คือแหล่งข้อมูลความจริงสำหรับข้อมูลตำแหน่งที่ตั้งที่แพลตฟอร์มให้มา เราได้รับรหัส `country` และกำหนดค่าเริ่มต้นที่เหมาะสม
• ตรรกะการบล็อก: เราเพียงแค่คืนค่า `NextResponse` ที่มีสถานะ `403` เพื่อบล็อกคำขอที่ edge ทันที เซิร์ฟเวอร์ต้นทางจะไม่ถูกแตะต้องเลย
• ตรรกะการ Redirect: เราใช้ `NextResponse.redirect()` ซึ่งจะส่ง response 307 กลับไปยังเบราว์เซอร์ บอกให้เบราว์เซอร์ร้องขอ URL ใหม่ (`/ca`) ซึ่งผู้ใช้จะมองเห็นการเปลี่ยนแปลงนี้
• ตรรกะการ Rewrite: เราใช้ `NextResponse.rewrite()` นี่คือการกระทำที่ทรงพลังที่สุด มันบอกให้ edge network ดึงเนื้อหาจาก URL อื่น (`api.eu.your-service.com`) แต่ให้บริการภายใต้ URL เดิม (`/api/...`) ซึ่งโปร่งใสอย่างสมบูรณ์สำหรับผู้ใช้ปลายทาง

ความท้าทายและข้อควรพิจารณา

แม้ว่าจะมีประสิทธิภาพ แต่การนำการกำหนดเส้นทางตามภูมิศาสตร์ที่ edge มาใช้ก็ไม่ได้ปราศจากความซับซ้อน นี่คือปัจจัยสำคัญที่ควรพิจารณา:

1. ความแม่นยำของฐานข้อมูล GeoIP

ข้อมูลตำแหน่งที่ตั้งได้มาจากการจับคู่ที่อยู่ IP ของผู้ใช้กับฐานข้อมูล GeoIP ฐานข้อมูลเหล่านี้มีความแม่นยำสูงแต่ก็ไม่ได้ถูกต้องเสมอไป ผู้ใช้ที่ใช้ VPN, เครือข่ายมือถือ หรือเครือข่ายองค์กรบางแห่งอาจถูกระบุตำแหน่งผิดพลาด ดังนั้น คุณควรมีวิธีให้ผู้ใช้เลือกเปลี่ยนตำแหน่งที่ตรวจพบด้วยตนเองเสมอ (เช่น ตัวเลือกประเทศในส่วนท้ายของเว็บไซต์)

2. ความซับซ้อนของการแคช

หากคุณให้บริการเนื้อหาที่แตกต่างกันสำหรับภูมิภาคต่างๆ ใน URL เดียวกัน คุณมีความเสี่ยงที่ผู้ใช้ในประเทศหนึ่งจะเห็นเนื้อหาที่แคชไว้สำหรับอีกประเทศหนึ่ง เพื่อป้องกันปัญหานี้ คุณต้องสั่งให้ CDN แคชหน้าเว็บเวอร์ชันต่างๆ กัน โดยทั่วไปจะทำได้โดยการส่ง header `Vary` ใน response ตัวอย่างเช่น `Vary: x-vercel-ip-country` จะบอกให้ CDN สร้างรายการแคชแยกต่างหากสำหรับแต่ละประเทศ

3. การทดสอบและการดีบัก

คุณจะทดสอบได้อย่างไรว่าตรรกะการกำหนดเส้นทางสำหรับเยอรมนีทำงานถูกต้องโดยไม่ต้องบินไปเยอรมนี? นี่อาจเป็นเรื่องท้าทาย วิธีการต่างๆ ได้แก่:

• VPNs: การใช้ VPN เพื่อส่งทราฟฟิกของคุณผ่านเซิร์ฟเวอร์ในประเทศเป้าหมายเป็นแนวทางที่พบบ่อย
• การจำลองแพลตฟอร์ม: บางแพลตฟอร์ม เช่น Vercel อนุญาตให้คุณแก้ไขข้อมูล `request.geo` ในเครื่องระหว่างการพัฒนาเพื่อวัตถุประสงค์ในการทดสอบ
• Browser DevTools: เครื่องมือสำหรับนักพัฒนาในเบราว์เซอร์บางตัวมีฟีเจอร์สำหรับการปลอมตำแหน่ง แม้ว่าวิธีนี้อาจไม่ส่งผลต่อการตรวจจับตาม IP ที่ edge เสมอไป

4. การใช้งานเฉพาะของผู้ให้บริการ (Vendor-Specific)

แนวคิดหลักของการกำหนดเส้นทางที่ edge นั้นเป็นสากล แต่รายละเอียดการใช้งานจะแตกต่างกันไปในแต่ละผู้ให้บริการ Vercel ใช้ `request.geo`, Cloudflare ใช้คุณสมบัติบนอ็อบเจ็กต์ `request.cf` และอื่นๆ แม้ว่าการย้ายตรรกะจะเป็นไปได้ แต่โปรดทราบว่ามันไม่ใช่การคัดลอกและวางแบบง่ายๆ และมีการผูกมัดกับผู้ให้บริการ (vendor lock-in) อยู่บ้าง

อนาคตของ Edge คือภูมิศาสตร์

การกำหนดเส้นทางตามภูมิศาสตร์ด้วย edge functions เป็นมากกว่าเทคนิคที่ชาญฉลาด มันคือการเปลี่ยนแปลงพื้นฐานในวิธีที่เราสร้างแอปพลิเคชันระดับโลก ในขณะที่แพลตฟอร์ม edge มีประสิทธิภาพมากขึ้น เราสามารถคาดหวังความสามารถที่ซับซ้อนยิ่งขึ้นได้:

• ฐานข้อมูลที่ Edge (Edge Databases): ด้วยผลิตภัณฑ์อย่าง Cloudflare D1 และ Vercel KV ข้อมูลเองก็สามารถอยู่บน edge ได้ ซึ่งช่วยให้คุณสามารถกำหนดเส้นทางคำขอของผู้ใช้ไปยัง edge function ที่ใกล้ที่สุด ซึ่งจากนั้นสามารถอ่านและเขียนข้อมูลจากฐานข้อมูลในตำแหน่งทางกายภาพเดียวกัน ทำให้สามารถสืบค้นฐานข้อมูลได้ในระดับมิลลิวินาทีเดียว
• การผสานรวมที่ลึกซึ้งยิ่งขึ้น: คาดหวังการเชื่อมโยงที่แน่นแฟ้นยิ่งขึ้นระหว่างเฟรมเวิร์ก frontend และความสามารถของ edge ซึ่งจะช่วยลดความซับซ้อนและทำให้การพัฒนาแบบ global-first เป็นค่าเริ่มต้น
• การปรับให้เหมาะกับบุคคลที่ดียิ่งขึ้น: นอกเหนือจากประเทศแล้ว การตัดสินใจกำหนดเส้นทางจะขึ้นอยู่กับปัจจัยอื่นๆ ที่มีอยู่บน edge มากขึ้น เช่น ประเภทของอุปกรณ์ ความเร็วในการเชื่อมต่อ และแม้กระทั่งช่วงเวลาของวัน เพื่อมอบประสบการณ์ที่เป็นส่วนตัวอย่างยิ่งยวด

สรุป: สร้างเพื่อโลก จาก Edge

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

ความสามารถในการ rewrite, redirect และแก้ไขคำขอโดยอิงตามตำแหน่งของผู้ใช้ ทั้งหมดนี้มีความหน่วงน้อยที่สุด ปลดล็อกประสบการณ์ผู้ใช้ระดับใหม่ ตั้งแต่การเคารพอธิปไตยทางข้อมูลด้วยการกำหนดเส้นทางข้อมูลอย่างชาญฉลาด ไปจนถึงการสร้างความพึงพอใจให้ผู้ใช้ด้วยเนื้อหาที่ปรับให้เข้ากับท้องถิ่น ความเป็นไปได้นั้นมีอยู่มากมาย ในขณะที่คุณออกแบบแอปพลิเคชันถัดไป อย่าคิดแค่ว่าจะโฮสต์เซิร์ฟเวอร์ของคุณที่ไหน แต่ให้คิดว่าคุณจะใช้ประโยชน์จากเครือข่าย edge ทั่วโลกเพื่อตอบสนองผู้ใช้ของคุณในที่ที่พวกเขาอยู่ได้อย่างไร