Programming

Grpc vs Rest Api Comparison

📅 2026-02-09 | โดย อ.บอม กิตติทัศน์ เจริญพนาสิทธิ์ — SiamCafe.net Since 1997

Grpc vs Rest Api Comparison คืออะไร / ทำไมถึงสำคัญ

น้องๆ เคยสงสัยมั้ยว่าเวลาเราเรียกข้อมูลจาก Server เนี่ย มันมีวิธีไหนบ้าง? สมัยผมทำร้านเน็ต SiamCafe ใหม่ๆ (ตั้งแต่ปี 97 เลยนะนั่น!) ตอนนั้นแทบจะไม่มีใครรู้จัก API เลยด้วยซ้ำ แต่พอโลกมันเปลี่ยนไป การสื่อสารระหว่างเครื่องมันซับซ้อนขึ้น ก็เลยมีทางเลือกให้เราเยอะแยะ อย่าง Grpc กับ Rest API เนี่ยแหละ

Grpc กับ Rest API คือวิธีการที่ Client (เช่น แอปมือถือ, เว็บไซต์) คุยกับ Server เพื่อขอข้อมูล หรือสั่งให้ Server ทำงานบางอย่างให้ Grpc เนี่ยมันเน้นเรื่องความเร็วและประสิทธิภาพ ส่วน Rest API มันเน้นเรื่องความง่ายในการใช้งานและความยืดหยุ่น แล้วทำไมต้องรู้เรื่องนี้? เพราะการเลือกใช้เทคโนโลยีให้เหมาะสมกับงาน จะช่วยให้ระบบของเราทำงานได้ดีขึ้น เร็วขึ้น และประหยัดทรัพยากรมากขึ้นไงล่ะ

พื้นฐานที่ต้องรู้: Protocol Buffers

ถ้าจะพูดถึง Grpc ก็ต้องพูดถึง Protocol Buffers หรือ Protobuf ก่อนเลย น้องๆ ลองนึกภาพว่าเรามี object ที่ซับซ้อน แล้วเราอยากส่ง object นี้ข้าม network ไปให้เครื่องอื่น สิ่งที่ต้องทำคือแปลง object นี้ให้เป็น byte stream ก่อน แล้วเครื่องปลายทางค่อยแปลง byte stream กลับมาเป็น object เดิม Protobuf เนี่ยแหละคือตัวช่วยแปลง object ให้เป็น byte stream ที่เร็วและมีประสิทธิภาพมากๆ

สมัยก่อนตอนที่ผมเริ่มเขียนโปรแกรมใหม่ๆ พวก serialization format ที่ฮิตๆ ก็จะมี XML กับ JSON แต่ Protobuf มันเร็วกว่าและกินทรัพยากรน้อยกว่าเยอะ เพราะมันเป็น binary format ไม่ใช่ text-based format เหมือน XML หรือ JSON

// ตัวอย่าง Protobuf definition
syntax = "proto3";

package example;

message Person {
  string name = 1;
  int32 id = 2;
  bool has_ponytail = 3;
}

พื้นฐานที่ต้องรู้: HTTP/2

Grpc ใช้ HTTP/2 เป็น transport protocol ซึ่ง HTTP/2 มันดีกว่า HTTP/1.1 ยังไง? HTTP/2 มันรองรับ multiplexing คือสามารถส่ง request หลายๆ อันพร้อมกันได้ใน connection เดียว แถมยังรองรับ header compression ทำให้ header มีขนาดเล็กลง และยังรองรับ server push คือ server สามารถส่งข้อมูลให้ client ก่อนที่ client จะ request ได้ด้วย

HTTP/1.1 เนี่ยมันเป็นอะไรที่ classic มากๆ สมัยก่อนผมทำเว็บ SiamCafe ก็ใช้ HTTP/1.1 นี่แหละ แต่พอมี HTTP/2 เข้ามา มันก็เหมือนเราเปลี่ยนจากรถเข็นเป็นรถแข่งเลย ความเร็วและความสามารถในการจัดการ connection มันต่างกันเยอะ

วิธีใช้งาน / เริ่มต้นยังไง

การใช้งาน Grpc อาจจะดูยากกว่า Rest API ในตอนแรก เพราะต้อง define Protobuf ก่อน แต่พอทำไปสักพักก็จะเริ่มชินเองแหละ

ขั้นตอนปฏิบัติจริง: Define Protobuf

อย่างแรกเลยคือเราต้อง define Protobuf file ก่อน Protobuf file เนี่ยจะเป็นตัวบอกว่า message ที่เราจะส่งกันมีหน้าตาเป็นยังไง มี field อะไรบ้าง มี type อะไรบ้าง ตัวอย่าง Protobuf file ที่ผมยกมาข้างบนก็คือ `Person` message ที่มี field `name`, `id`, และ `has_ponytail`

// ตัวอย่าง Grpc service definition
service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

ขั้นตอนปฏิบัติจริง: Generate Code

หลังจากที่เรา define Protobuf เสร็จแล้ว เราก็ต้อง generate code จาก Protobuf file โดยใช้ Protobuf compiler Protobuf compiler จะ generate code ให้เราตามภาษาที่เราต้องการ เช่น Java, Python, Go, C++ Code ที่ generate ออกมาก็จะเป็น class หรือ struct ที่เราสามารถใช้ในการ serialize และ deserialize message ได้

สมัยก่อนผมต้องเขียน serialization/deserialization เองทั้งหมด ซึ่งมันเสียเวลามากๆ แถมยังมีโอกาสผิดพลาดเยอะ แต่พอมี Protobuf compiler ชีวิตมันง่ายขึ้นเยอะเลย

ขั้นตอนปฏิบัติจริง: Implement Server and Client

หลังจากที่เรา generate code แล้ว เราก็ต้อง implement server และ client server ก็คือตัวที่รับ request จาก client แล้วประมวลผล ส่วน client ก็คือตัวที่ส่ง request ไปให้ server

การ implement server และ client ด้วย Grpc อาจจะซับซ้อนกว่า Rest API นิดหน่อย เพราะเราต้องจัดการเรื่อง stub generation และ channel management แต่ถ้าเราใช้ framework ที่ support Grpc อย่างดี เช่น Spring Boot Grpc หรือ gRPC Python มันก็จะง่ายขึ้นเยอะ

เปรียบเทียบกับทางเลือกอื่น + ตาราง

Rest API ก็เป็นทางเลือกที่ได้รับความนิยมมากๆ ข้อดีของ Rest API คือมันง่ายต่อการใช้งาน มี library และ tool ให้ใช้เยอะแยะ แถมยัง support หลายภาษา แต่ข้อเสียคือมันอาจจะไม่เร็วเท่า Grpc และอาจจะกิน bandwidth มากกว่า

สมัยก่อน Rest API คือพระเอกเลยนะ ใครๆ ก็ใช้ แต่พอมี Grpc เข้ามา มันก็เหมือนมีตัวเลือกที่แรงกว่า ประหยัดกว่า แต่ก็ต้องแลกมาด้วยความซับซ้อนที่มากขึ้น

Feature	Grpc	Rest API
Protocol	HTTP/2	HTTP/1.1 or HTTP/2
Message Format	Protocol Buffers (Binary)	JSON, XML (Text)
Performance	High	Moderate
Complexity	High	Moderate
Code Generation	Required	Optional
Browser Support	Limited (gRPC-Web)	Good

สรุปแล้ว Grpc เหมาะกับงานที่ต้องการประสิทธิภาพสูง เช่น microservices ที่ต้องสื่อสารกันภายใน data center ส่วน Rest API เหมาะกับงานที่ต้องการความง่ายในการใช้งาน และต้องการ support หลายภาษา เช่น public API ที่ให้คนทั่วไปใช้งาน

ถ้าอยากรู้เรื่อง IT สนุกๆ อีกเยอะ แวะไปอ่าน SiamCafe Blog ได้เลยนะ ผมเขียนไว้เยอะแยะเลย

และถ้าใครอยากลองทำ Grpc จริงๆ จังๆ ลองหา tutorial ใน SiamCafe Blog ดูนะ ผมอาจจะเขียนไว้บ้างแล้วก็ได้ 😉

Best Practices / เคล็ดลับจากประสบการณ์

น้องๆ หลายคนถามพี่ว่า "แล้วพี่บอมใช้ gRPC หรือ REST API ตอนไหนดี?" เอาจริงๆ มันไม่มีสูตรสำเร็จตายตัวหรอกน้อง แต่สมัยพี่ทำร้านเน็ตฯ SiamCafe พี่จะดูจากโจทย์เป็นหลักเลย

ถ้าเป็นงานภายในที่ต้องการความเร็วสูงๆ เช่น ระบบคิดเงินในร้านที่ต้อง real-time พี่จะมอง gRPC ก่อนเลย เพราะมันไวกว่าเยอะ แต่ถ้าเป็น API ที่ต้องเปิดให้คนภายนอกใช้ พี่จะเลือก REST API เพราะมันเป็นมาตรฐานที่คนส่วนใหญ่คุ้นเคยกว่า

3-4 เทคนิคที่ใช้ได้จริง

1. Protocol Buffers คือเพื่อนแท้

ถ้าตัดสินใจใช้ gRPC แล้ว น้องๆ ต้องสนิทกับ Protocol Buffers (protobuf) ให้มากๆ เพราะมันคือหัวใจของการ define data structure ทั้งหมด สมัยก่อนพี่เคยพลาดท่า เพราะไม่ได้ออกแบบ protobuf ให้ดีตั้งแต่แรก พอโปรเจ็คใหญ่ขึ้นมาแก้กันอ้วกเลย

syntax = "proto3";

package example;

message User {
  int32 id = 1;
  string name = 2;
  string email = 3;
}

ลองเริ่มจากง่ายๆ แบบนี้ก่อนก็ได้ แล้วค่อยๆ เพิ่ม field เข้าไปตาม requirement

2. Streaming คือทางรอด

gRPC มี streaming ให้ใช้ประโยชน์ได้เยอะมากๆ สมัยพี่ทำระบบ monitoring ในร้านเน็ตฯ พี่ใช้ streaming ส่งข้อมูล real-time จาก client ไป server แบบต่อเนื่อง ทำให้เห็นสถานะเครื่องลูกข่ายได้ตลอดเวลา

3. Authentication สำคัญเสมอ

ไม่ว่าจะเป็น gRPC หรือ REST API เรื่อง authentication สำคัญมากๆ น้องๆ ต้อง implement ให้รัดกุมเสมอ สมัยพี่ทำร้านเน็ตฯ เคยโดนแฮกเพราะ security ไม่ดี นี่เข็ดจนตายเลย

4. Monitoring & Logging ต้องมี

อย่าลืมใส่ monitoring และ logging เข้าไปในระบบด้วยนะน้อง เพราะมันจะช่วยให้น้องๆ detect ปัญหาได้เร็วขึ้น สมัยก่อนพี่ไม่ค่อยใส่ใจเรื่องนี้เท่าไหร่ พอระบบมีปัญหา กว่าจะหาเจอว่าเกิดอะไรขึ้นก็เสียเวลาไปเยอะ

FAQ คำถามที่พบบ่อย

gRPC เหมาะกับ Microservices จริงหรือ?

ใช่เลยน้อง gRPC เหมาะกับ microservices มากๆ เพราะมันช่วยให้ communication ระหว่าง services เร็วและมีประสิทธิภาพมากขึ้น แต่ต้องแลกมาด้วย complexity ที่เพิ่มขึ้นด้วยนะ

REST API จะตายไหม?

ไม่ตายหรอกน้อง REST API ยังคงเป็นที่นิยมอยู่ เพราะมันง่ายต่อการใช้งานและมี tool ให้เลือกใช้เยอะแยะ แถมยัง support HTTP ที่เป็น protocol หลักของเว็บอีกด้วย

gRPC vs REST API เลือกอะไรดี?

อย่างที่บอกไปตอนต้น มันขึ้นอยู่กับโจทย์ของน้องๆ ถ้าต้องการความเร็วสูงและเน้นประสิทธิภาพ gRPC คือคำตอบ แต่ถ้าต้องการความง่ายและเป็นมาตรฐาน REST API ก็ยังเป็นตัวเลือกที่ดี

มี Tool อะไรแนะนำบ้าง?

ถ้าใช้ gRPC พี่แนะนำ grpc-ecosystem/grpc-gateway มันช่วยให้เรา expose gRPC service เป็น REST API ได้ด้วย สะดวกมากๆ

สรุป

gRPC และ REST API ต่างก็มีข้อดีข้อเสียของตัวเอง ไม่มีอะไรดีกว่ากันเสมอไป น้องๆ ต้องเลือกใช้ให้เหมาะสมกับสถานการณ์และความต้องการของตัวเอง

จำไว้เสมอว่า technology เป็นแค่เครื่องมือ สิ่งที่สำคัญที่สุดคือการเข้าใจปัญหาและเลือกใช้เครื่องมือที่เหมาะสมที่สุดในการแก้ปัญหานั้นๆ

และอย่าลืมแวะไปอ่านบทความอื่นๆ ที่ SiamCafe Blog นะน้อง พี่เขียนไว้เยอะแยะเลย

สนใจเรื่อง Forex ลองดูที่ iCafeForex สิ!