Connect-RPC คืออะไร — gRPC ที่ browser เรียกได้ตรง ๆ • Devfavor

เคยอยากใช้ gRPC ในโปรเจกต์ไหม ความเร็วดี schema ชัด generate client ให้อัตโนมัติ type safe ทั้งระบบ ฟังดูครบทุกอย่างที่ฝันถึง

แล้วพอจะให้ frontend ที่รันบน browser เรียก gRPC ตรง ๆ ก็เจอกำแพง — browser เรียก gRPC ปกติไม่ได้ ต้องไปตั้ง proxy อย่าง Envoy มาแปลภาษาก่อน เพิ่ม component ในระบบ เพิ่มเรื่องที่ต้อง deploy เพิ่มจุดที่พังได้

สุดท้ายหลายทีมก็ถอย กลับไปเขียน REST + JSON ธรรมดา ยอมทิ้ง type safety กับ codegen ที่อยากได้ เพราะแค่ “ให้ browser เรียกได้” ก็ต้องแลกมาด้วยความยุ่งยากเกินไป

Connect-RPC เกิดมาเพื่อแก้ปมตรงนี้พอดี — ได้ของดีจาก gRPC แต่ browser เรียกได้ตรง ๆ และเรียกผ่าน curl + JSON ได้เหมือน REST ทั่วไป

🧩 Connect-RPC คืออะไร#

Connect (หรือที่เรียกกันว่า Connect RPC) คือชุดไลบรารีสำหรับสร้าง HTTP API ที่เข้ากันได้ทั้งกับ browser และ gRPC

วิธีทำงานคือเริ่มจากเขียน Protocol Buffer schema สั้น ๆ ว่า service มี method อะไรบ้าง รับอะไร คืนอะไร แล้วเครื่องมือจะ generate โค้ดให้อัตโนมัติทั้งสองฝั่ง — ฝั่ง server เป็น handler ที่รอให้เราเติม logic เข้าไป ฝั่ง client เป็น type-safe client ที่เรียกใช้ได้เลย

งานน่าเบื่อที่ต้องทำซ้ำทุกครั้งกับ API อย่าง marshaling (แปลงข้อมูลไปกลับ), routing, compression และ content negotiation เหล่านี้ Connect จัดการให้หมด เราเหลือแค่เขียน schema กับ business logic

Connect สร้างโดยบริษัท Buf — ทีมเดียวกับที่อยู่เบื้องหลัง buf.build และเครื่องมือสาย Protobuf tooling ทั้งหลาย โดยตั้งใจแก้ข้อจำกัดของ gRPC แบบดั้งเดิม โดยเฉพาะเรื่องที่ใช้งานยากบน HTTP/1.1 และ browser ปัจจุบัน Connect เป็นโปรเจกต์ภายใต้ CNCF (Cloud Native Computing Foundation) มีโครงสร้างการกำกับดูแลแบบ community-led แล้ว

🔀 จุดเด่นที่แท้จริง — รองรับ 3 โปรโตคอลใน server เดียว#

หัวใจที่ทำให้ Connect ต่างจาก gRPC ปกติคือ server หนึ่งตัวรับได้ทั้ง 3 โปรโตคอลพร้อมกันโดย default

gRPC — โปรโตคอลเต็มรูปแบบ รองรับครบทั้ง streaming, trailers, error details ดังนั้น gRPC client ภาษาใดก็เรียก Connect server ได้ และ Connect client ก็เรียก gRPC server ของใครก็ได้ ข้ามไปมาได้หมด
gRPC-Web — รองรับโดยตรง ไม่ต้องตั้ง translating proxy อย่าง Envoy มาคั่นกลางอีกต่อไป
Connect protocol — โปรโตคอลของ Connect เองที่เป็น HTTP-based ทำงานบน HTTP/1.1, HTTP/2 และ HTTP/3 จุดนี้แหละที่ทำให้เรียก unary RPC ได้จาก browser หรือ cURL ตรง ๆ

ความหมายในทางปฏิบัติคือ เราเขียน backend ครั้งเดียว แล้วเลือกได้ว่าฝั่งไหนจะคุยด้วยโปรโตคอลอะไร microservice ภายในคุยกันด้วย gRPC เพื่อความเร็ว ส่วน browser frontend คุยด้วย Connect protocol ตรง ๆ

และที่สำคัญคือสลับ protocol ได้ด้วยการแก้ config ไม่ต้องแก้โค้ด business logic เลย

⚙️ ใช้งานจริงหน้าตาเป็นยังไง#

ลองดูตัวอย่างฝั่ง Go เริ่มจากนิยาม service ใน protobuf schema

service GreetService {
  rpc Greet(GreetRequest) returns (GreetResponse) {}
}

protobuf

จากนั้น Connect generate โค้ดให้ เราแค่ implement handler

func (s *GreetServer) Greet(
    ctx context.Context,
    req *connect.Request[greetv1.GreetRequest],
) (*connect.Response[greetv1.GreetResponse], error) {
    res := connect.NewResponse(&greetv1.GreetResponse{
        Greeting: fmt.Sprintf("Hello, %s!", req.Msg.Name),
    })
    return res, nil
}

แล้ว register เข้ากับ http.NewServeMux() ผ่าน greetv1connect.NewGreetServiceHandler(greeter) — สังเกตว่าใช้ net/http มาตรฐานล้วน ๆ ไม่มี HTTP server แปลก ๆ ของตัวเอง

ทีนี้ฝั่ง client ที่ทำให้คนชอบ — เรียกผ่าน curl ธรรมดาได้เลย

curl --header "Content-Type: application/json" \
  --data '{"name": "Jane"}' \
  http://localhost:8080/greet.v1.GreetService/Greet
# {"greeting": "Hello, Jane!"}

bash

JSON เข้า JSON ออก เหมือน REST API ทั่วไปที่เรา debug กันอยู่แล้ว ไม่ต้องมีเครื่องมือพิเศษมาแกะ binary

ส่วนฝั่ง web ก็ได้ type safety เต็มที่ สร้าง transport ด้วย createConnectTransport({ baseUrl }) แล้วสร้าง client ด้วย createClient(ElizaService, transport) จากนั้นเรียก await client.say({ sentence: inputValue }) ได้เลย ถ้าพิมพ์ชื่อ field ผิด TypeScript จะ error ตั้งแต่ตอน compile ไม่ต้องรอ runtime

ตัวอย่างเหล่านี้ทำงานกับ web framework ได้หลากหลาย ทั้ง Angular, Next.js หรือ vanilla JavaScript และโค้ด TypeScript ที่ generate ออกมาก็ใช้งานสบาย เทียบเท่ากับ REST client ที่เขียนเอง

🎯 เอาไปใช้กับงานแบบไหนได้บ้าง#

จาก use case ที่ยืนยันได้จริง Connect เหมาะกับสถานการณ์เหล่านี้

เรียก RPC จาก web frontend แบบ type-safe — React, Angular, Next.js หรือ vanilla JS เรียก backend ได้ตรง ๆ พิมพ์ field ผิดรู้ทันทีตอน compile
backend ตัวเดียว serve ได้หลายโปรโตคอล — เขียน Go ครั้งเดียว serve ทั้ง gRPC, gRPC-Web และ Connect พร้อมกัน
real-time streaming — มีตัวอย่างใช้ .NET backend คู่กับ React frontend ผ่าน Connect เพื่อ consume streaming endpoint
สลับ protocol ด้วย config — เปลี่ยนวิธีคุยได้โดยไม่ต้องแตะโค้ดหลัก

เรื่องภาษาที่รองรับก็ครอบคลุมพอสมควร โดยสถานะ ณ ตอนนี้คือ Go, TypeScript/JS (ทั้ง web และ Node.js), Swift และ Dart อยู่ระดับเสถียร (stable) ส่วน Kotlin และ Python ยังเป็น beta

⚖️ ข้อดีและข้อควรรู้ก่อนตัดสินใจ#

ข้อดีที่ชัดเจน:

ได้ type safety แบบ end-to-end ข้ามภาษา จาก schema เดียว
browser เรียกได้ตรง ๆ ไม่ต้องตั้ง proxy แปลภาษา ลด component ในระบบ
debug ง่ายเพราะเรียกผ่าน curl + JSON ได้เหมือน REST
ภายใต้ฝากระโปรงเป็นแค่ Protocol Buffers + standard library ของแต่ละภาษา ไม่มี custom HTTP implementation ไม่มี name resolution หรือ load balancing API ใหม่ให้ต้องเรียนรู้ อะไรที่ทำงานกับ http.Server / http.Client / http.Handler ได้ ก็ใช้กับ Connect ได้
ยึด semantic versioning อย่างเคร่งครัด — breaking change จะมาพร้อม major version bump เท่านั้น (เช่น connect-es 2.0 ที่ไม่ backward compatible กับ 1.x เพราะอิงกับ Protobuf-ES 2.0) และเวลาอัปเกรดก็มี migration guide พร้อมเครื่องมือ automate ช่วย รวมถึงยังดูแล major version เดิมต่อระหว่างที่ทีม migrate

สิ่งที่ต้องชั่งใจ:

ยังต้องเขียน Protobuf schema และ run codegen อยู่ ถ้าทีมไม่เคยแตะ Protobuf เลยก็มีช่วงปรับตัวอยู่บ้างในช่วงแรก
บางภาษา (Kotlin, Python) ยังเป็น beta ถ้า stack หลักอยู่ตรงนั้น ต้องประเมินความพร้อมก่อน
ถ้า API เล็กมาก มี endpoint ไม่กี่ตัว และไม่ได้ต้องการ type safety ข้ามภาษา REST + JSON ธรรมดาอาจจะพอแล้ว ไม่จำเป็นต้องลากทั้ง toolchain เข้ามา

หลักคิดง่าย ๆ คือ Connect เด่นที่สุดเมื่อเรามีทั้ง frontend และ backend ที่อยากให้ share schema เดียวกัน อยากได้ความเร็วและ type safety แบบ gRPC แต่ก็ยังอยากให้ browser เรียกได้สะดวก

🧭 สรุป#

Connect-RPC คือทางสายกลางที่ลงตัวระหว่าง gRPC กับ REST — ได้ schema-driven, codegen และ type safety จากฝั่ง gRPC แต่ยังเรียกจาก browser และ curl ได้สบายเหมือน REST โดยไม่ต้องมี proxy มาคั่น

จุดขายแท้จริงไม่ใช่แค่ “เร็ว” แต่คือการที่ server เดียวพูดได้ทั้ง gRPC, gRPC-Web และ Connect protocol พร้อมกัน ทำให้ทีมเลือกได้ว่าแต่ละฝั่งจะคุยด้วยวิธีไหน โดยไม่ต้องเขียน backend ซ้ำ

ถ้าอยากลองต่อ แนะนำเริ่มจาก getting started guide ของภาษาที่ทีมใช้บน connectrpc.com แล้วลองสร้าง GreetService ตามตัวอย่าง — เขียน schema สั้น ๆ generate โค้ด แล้วยิง curl ดูสักครั้ง

😎 ☕