หัดใช้ API Gateway กับ AWS Lambda กัน
สวัสดีครับ วันนี้เราจะมาหัดใช้ API Gateway กับ AWS Lambda กัน ยังไงก็มาลองทำกันได้เลย
ก่อนอื่นเลย สำหรับใครที่ยังไม่รู้จักกับ AWS Lambda แนะนำให้ไปดูที่นี่ และสามารถดูคลิปได้ที่นี่
ก่อนเริ่มใช้งานเราต้องมารู้จักกันก่อนว่า API Gateway คืออะไร
API Gateway เป็นผลิตภัณฑ์ของทาง AWS ที่เกี่ยวข้องกับ API หมดเลย ไม่ว่าจะเป็นการบำรุงรักษา ความปลอดภัย การทำ Document การจัดการ API ต่าง ๆ โดยตัว API Gateway สามารถใช้งานได้ทั้งแบบ HTTP API, RESTful API และ Web Socket เลย (ที่เข้าไปเล่นดูยังไม่มี GraphQL นะ) ยังสามารถทำ Document สำหรับ API ได้ง่าย และสามารถ Export ไปยังแอพอื่นได้ด้วย นับว่าสะดวกมาก
เอาล่ะ เกริ่นนำไปแล้ว เรามาเริ่มกันเลย โดยเราจะเอา API ที่ทำบน AWS Lambda มาใช้งานกัน
ไปที่ API Gateway กันก่อนเลย
ในนี้จะมีให้สร้างทั้งหมด 4 แบบ ประกอบด้วย
- HTTP API – เป็น REST APIs ที่ง่าย ๆ จะมีฟีเจอร์ในส่วนของ OIDC, OAuth2 และ CORS ด้วย
- WebSocket API – เป็น Web Socket นั่นแหละ ไว้ทำ API แชทหรือพวก Dashboard
- REST API – เป็น REST APIs ไว้จัดการ API แบบเต็มสูบเลย (มีหลายอย่างให้ใช้มาก เช่น Documents, Export API, Auth, Dashboard ก็คือเป็น API Management แบบเต็มตัว)
- REST API Private – เป็น REST APIs ไว้สำหรับใช้ในเครือข่ายเฉพาะหรือภายในเท่านั้น
โดยในทีนี้ เราจะเลือกใช้ HTTP API
หน้านี้เป็นหน้าสร้าง API เลือก Integrations เป็น Lambda, เลือก AWS Region เป็นโซนที่เราสร้าง Lambda, เลือก Lambda Function เป็น Lambda ที่เราสร้าง, API Name เป็นชื่อ API, คลิก Next
หน้านี้เป็นหน้าตั้งค่า Routes หรือเส้นทาง URL เลือก Method เป็น POST ในส่วนนี้ที่ตั้งเป็น POST เพราะว่า Line Message API นั้นให้ใช้งาน Webhook เป็น POST เพราะฉะนั้นเลยต้องตั้งตามที่เค้าบอกมา ตั้งเป็น Any ก็ได้ แต่การตั้งเป็น Any ต้องมั่นใจว่า Lambda ของเราสามารถทำงานได้ทุก Method ใน RESTful API และอาจจะเป็นการสิ้นเปลือง Method แต่มันอยู่ที่ Source Code เราด้วยนะ ว่าเขียนแบบไหน แต่ใน Function URL ของ AWS Lambda นั้น ถ้าทำตามตัวอย่างจากบทความที่แล้ว จะเป็นการตั้งแบบ Default คือจะเป็นแบบ Any เหมือนกัน เราสามารถไปตั้งค่าเป็น POST ทีหลังได้
Resource path เป็นชื่อ path ที่เราเรียกใช้ผ่าน url ตั้งเป็นอะไรก็ได้ ในทีนี้ตั้งเป็น /webhook, Integration target เป็น Lambda ที่เราเลือก (เลือกจากหน้าที่แล้วมา) แล้วเลือก Next
หน้านี้เป็นหน้าสร้าง Stage เอาไว้สำหรับทดสอบ หรือแยก Environments สำหรับ Deploy ไปยังที่ต่าง ๆ ทำการตั้ง Stage เป็น $default (เป็น Default ที่เค้าตั้งมาให้ สามารถเพิ่มหรือเปลี่ยนได้ตามที่เราต้องการ) แล้วกด Next
หน้านี้เป็นหน้าตรวจสอบตามสิ่งที่เราสร้างมา ทำการตรวจสอบให้เรียบร้อย ถ้าเสร็จแล้วก็กด Create ได้เลย
ตอนนี้เราจะได้ URL มาแล้ว Copy ในส่วนของ Invoke URL เอาไปใส่ใน Line Message API ได้เลย (อย่าลืมใส่ /webhook หรือตามชื่อ Resource path ที่เราตั้ง) ก็เป็นอันว่าเสร็จ
เราสามารถเข้าไปดู Routes หรือเส้นทาง URL เพิ่มเติมได้ที่เมนู Routes ทางซ้าย
หน้านี้เป็นรายละเอียดของ Routes โดยจะมี /webhook ที่เราสร้างไว้ เป็น Method POST
เปรียบเทียบระหว่าง Function URL ของ Lambda กับ API Gateway
- Function URL ยิงเทสและทดสอบได้ง่ายกว่า เพราะเราสามารถทำผ่าน UI ของทาง Lambda ได้เลย ส่วน API Gateway นั้นต้องแยกมาเทสผ่าน Browser ไม่ก็ใช้ Postman ในการเทส
- Function URL เขียน Test บน UI ที่เค้ามีให้ได้ยากกว่า เพราะเนื่องจากเป็น Invoke URL มันเลยมีส่วนที่มาครอบในส่วนของ Payloads ทุกครั้ง แนะนำว่าถ้าเขียนเทส ถ้าเอาให้ได้ทั้ง 2 แบบทั้ง Function URL กับ API Gateway ให้ใช้ Postman หรือ Client API จะง่ายกว่า
- การ Custom URL หรือใช้ Domain name กับ Invoke URL นั้น API Gateway ทำได้ดีกว่ามาก เพราะมันมีในส่วนของตั้งค่ามาให้ใน API Gateway เลย แต่ถ้าเป็น Function URL จากที่หาข้อมูลมาคร่าว ๆ ยังไม่เคยลองนะ เค้าบอกต้องไปใช้ AWS Cloudfront
- ถ้าเราทำ Public API ให้คนในทีมหรือคนอื่นใช้ แนะนำว่าให้ใช้ API Gateway เพราะมีฟีเจอร์ที่เยอะกว่า ตั้งค่าได้ง่ายกว่า อ่านง่ายกว่าด้วย แต่ถ้าใช้เป็น Private API หรือ Webhook หรือไว้ใช้ทดสอบ ก็แนะนำว่า Function URL จะสะดวกกว่ามาก
- Dashboard ของ API Gateway ดูได้ละเอียดกว่าทาง Function URL เพราะ API Gateway เป็นผลิตภัณฑ์ที่ออกแบบมาสำหรับ API โดยเฉพาะเลย เพราะฉะนั้นถ้าเราทำ API จริงจังก็แนะนำว่าให้ไปใช้ API Gateway ไปเลย ส่วน Function URL ก็มีให้ดูผ่าน Lambda นั่นแหละ ก็ถือว่าดูใช้งานได้พอสมควร แต่จะออกแนวดูแนวดูการทำงานของ Serverless ซะมากกว่า แต่ต้องบอกว่าถ้าเราจะดู Dashboard ทั้งระบบจริง ๆ มันจะมี AWS Cloudwatch ให้มา สามารถไปดูตรงนั้นแทนก็ได้
- ความยากง่ายในการใช้งาน แล้วแต่คนทำเลย ส่วนตัวแล้ว ทำแบบ API Gateway ง่ายกว่าเพราะมันไม่ต้องไปตั้งค่า IAM หรือจัดการสิทธิ์ให้ยุ่งยากเลย ไปสร้าง API ตามข้างบนก็สามารถใช้งานได้แล้ว แต่ถ้าเป็น Function URL มันจะติดมากับ Lambda ก็สะดวกในตรงนี้ แต่บางทีไปเผลอลบหรือลืมตั้งค่า IAM ให้กับ Function URL มันก็จะใช้งานไม่ได้
ตอนนี้เราเปรียบเทียบระหว่าง Function URL ของ Lambda กับ API Gateway เสร็จแล้ว เราไปดูกันว่าเราใช้อะไรไปบ้างแล้ว
- Lambda
- API Gateway
- Cloudwatch เวลาเราสร้าง API Gateway หรือ Lambda มันจะ Sync หรือเชื่อมต่อกันให้เลย
- Cloudfront เป็นส่วนเสริมถ้าเราต้องการ Custom Domain ของ Function URL ใน Lambda
เสร็จไปแล้วกับการหัดใช้ API Gateway กับ AWS Lambda ไม่ยากเลยใช่มั้ยครับ ถือว่าเป็นทางเลือกสำหรับคนใช้ AWS ละกันว่าจะใช้วิธีไหนระหว่าง AWS Lambda ที่มาพร้อมกับ Function URL กับ API Gateway ที่มีระบบจัดการ API มาให้เลย ส่วนตัวคิดว่าแล้วแต่การใช้งาน แต่ที่แน่ ๆ เราทำงานจบได้ใน AWS ที่เดียวเลย ก็ถือว่าเค้ามีอะไรให้เราใช้เยอะเลย แต่ก็อย่าลืมราคากันด้วยนะ สามารถเข้าไปดู Free Tier ได้ที่นี่ และรายละเอียดของแต่ละตัวได้ ถ้าเราใช้งานเล็ก ๆ หรือไม่ใหญ่มาก ดูใน Free Tier แล้วอยู่ในการใช้งานไม่เกิน แนะนำเลยให้ใช้ เพราะเหมือนเราได้ระบบการจัดการที่ดีฟรี ๆ มาใช้งาน แต่ถ้าเป็นระบบใหญ่ ๆ อันนี้แล้วแต่เลยสะดวกเลย ลองคิดดูดี ๆ นะ
สำหรับบทความนี้ก็พอแค่นี้ก่อนละกันครับ หากมีคำถามหรือข้อสงสัยสามารถสอบถามได้ทาง Email หรือทาง Social ที่ทางเว็บมีให้ครับ สำหรับวันนี้ สวัสดีครับ
ช่องทางการติดต่อ
Email: [email protected]
Website: https://blog.tichaky.com/
Facebook: https://www.facebook.com/tichaky
