ทีมวิศวกรยังคงเสียเวลาทั้งบ่ายไปกับการถกเถียงว่า REST ตายแล้ว หรือ gRPC ทำให้เทคโนโลยีอื่นล้าสมัยไปแล้ว การถกเถียงนั้นข้ามประเด็นสำคัญไป คุณไม่ได้กำลังเลือกโปรโตคอลที่ดีที่สุด แต่คุณกำลังเลือกขอบเขต (boundary) ที่เหมาะสม โปรโตคอลที่ทำงานได้อย่างยอดเยี่ยมภายใน Kubernetes cluster ของคุณ อาจจะทำงานติดขัดเมื่อคุณต้องส่งต่อมันให้กับนักพัฒนาภายนอกนับพันคน โปรโตคอลที่ช่วยประหยัดแบนด์วิดท์อันมีค่าให้กับแอปมือถือของคุณ อาจทำให้โครงสร้างพื้นฐานของคุณล่มจมได้ หากคุณเปิดให้มีการคิวรีสาธารณะแบบสุ่ม หากคุณตัดสินใจเรื่องนี้เหมือนกับการประกวดความนิยมของเทคโนโลยี คุณกำลังสร้างหนี้ทางสถาปัตยกรรม (architectural debt) ที่จะคงอยู่ยาวนานกว่าสมาชิกทุกคนในทีมของคุณในปัจจุบัน
The Boundary Principle
สถาปัตยกรรมคือเรื่องของการแลกเปลี่ยน (trade-offs) ไม่ใช่การหาผู้ชนะ คำถามที่ถูกต้องไม่ใช่ "อันไหนเร็วที่สุด?" หรือ "อันไหนใหม่ที่สุด?" แต่คือ "ใครอยู่ฝั่งตรงข้ามของสายสัญญาณ และพวกเขามีอำนาจควบคุมอะไรบ้าง?" โปรโตคอลคือวัตถุที่เป็นขอบเขต (boundary objects) การเลือกผิดไม่ได้แค่ทำให้คุณทำงานช้าลง แต่มันจะฝังความผิดพลาดลงในระบบของคุณไปอีกหลายปี
Public APIs: REST Is Not Boring, It Is Responsible
เมื่อผู้ใช้งานของคุณคือนักพัฒนาภายนอกที่คุณไม่เคยรู้จัก API ของคุณคือผลิตภัณฑ์ ไม่ใช่แค่เพียงอินเทอร์เฟซ นักพัฒนาคนนั้นอาจกำลังดีบั๊กตอนตีสอง โดยมีเพียงแค่ curl และ Postman collection เท่านั้น หากพวกเขาต้องติดตั้ง client library เฉพาะทาง หรือต้องเรียนรู้ภาษา schema ก่อนที่จะเรียกใช้งานครั้งแรกได้สำเร็จ คุณก็ได้เสียพวกเขาไปแล้ว
REST ยังคงอยู่รอดได้เพราะมันคือตัวตนของเว็บ HTTP methods, status codes และ JSON คือภาษากลางที่ทุกคนเข้าใจ การทำ Caching ไม่ใช่เรื่องที่มาคิดทีหลัง แต่มันคือโครงสร้างพื้นฐานที่มีอยู่แล้ว ทั้ง Browser, CDN และ edge caches ต่างก็เข้าใจ Cache-Control headers และการตรวจสอบ ETag โดยธรรมชาติ คุณสามารถวาง REST API ไว้หลัง CDN มาตรฐาน และประหยัดแบนด์วิดท์ได้ทันทีโดยไม่ต้องเขียนโค้ดสำหรับ caching แม้แต่บรรทัดเดียว ซึ่งเรื่องนี้สำคัญมากเมื่อทราฟฟิกสาธารณะนั้นคาดเดาไม่ได้ และคุณต้องจ่ายเงินสำหรับทุกๆ Gigabyte ที่ออกจากคลาวด์ของคุณ
ในทางตรงกันข้าม GraphQL นำมาซึ่ง "ภาษี" ที่หนักอึ้งสำหรับขอบเขตสาธารณะ GraphQL endpoint ที่เปิดสู่สาธารณะจำเป็นต้องมีการวิเคราะห์ต้นทุนการคิวรี (query cost analysis), การจำกัดความลึก (depth limiting) และการให้คะแนนความซับซ้อน (complexity scoring) เพื่อป้องกันไม่ให้การคิวรีที่ประมาทหรือมุ่งร้ายเพียงครั้งเดียวทำลายฐานข้อมูลของคุณ คุณไม่ได้แค่ส่งมอบ API แต่คุณกำลังสร้างเครื่องมือประมวลผลการคิวรี (query execution engine), กลยุทธ์การจำกัดอัตรา (rate-limiting strategy) และโมเดลการคิดค่าบริการตามการประมวลผล (compute billing model) เว้นแต่คุณจะมีศักยภาพในการดำเนินงาน (operational muscle) เทียบเท่ากับแพลตฟอร์มยักษ์ใหญ่ ภาระงานส่วนเกิน (overhead) เหล่านั้นถือว่าเสี่ยงเกินไปสำหรับพื้นที่สาธารณะ REST มีการกำหนดขอบเขต (guardrails) ไว้ให้โดยค่าเริ่มต้น แต่ละ endpoint ทำหน้าที่เพียงอย่างเดียว ผู้ใช้งานจะดึงข้อมูลเฉพาะสิ่งที่คุณเสนอให้เท่านั้น ไม่ใช่ตามใจชอบที่พวกเขาจะจินตนาการได้
Internal Services: Own the Whole Pipe
ภายในองค์กรของคุณ บทสนทนาจะเปลี่ยนไป คุณควบคุมทั้งฝั่ง client และ server คุณสามารถกำหนด technology stack สำหรับทุกบริการในสายการเรียกใช้งาน (call chain) ได้ นี่คือจุดที่ gRPC แสดงความคุ้มค่าของมัน
อย่างแรก เลิกปฏิบัติกับ JSON เหมือนเป็นสิ่งศักดิ์สิทธิ์ Protocol Buffers ทำการ serialize ได้เร็วกว่า JSON ประมาณสามเท่า และ payload ยังมีขนาดเล็กกว่าเพราะเป็นรูปแบบ binary ในเครือข่ายภายในที่หนาแน่น มิลลิวินาทีและเมกะไบต์เหล่านั้นจะสะสมกลายเป็นต้นทุนเงินจริง ๆ และช่วยลด tail latency ลงได้ ที่สำคัญกว่านั้น Protobuf มอบสัญญา (contract) ที่เข้มงวดให้แก่คุณ เมื่อคุณเปลี่ยนประเภทของ field หรือเปลี่ยนชื่อ message ข้อผิดพลาดจะเกิดขึ้นตั้งแต่ตอน compile ไม่ใช่ตอนตีสามในสภาพแวดล้อม production เมื่อบริการปลายทาง (downstream service) เริ่มพ่น parse exceptions ออกมา
gRPC ทำงานบน HTTP/2 ดังนั้นคุณจึงได้ทั้งการบีบอัด header, multiplexed streams และความหมายของการทำ streaming ที่แท้จริง หากคุณกำลังส่งผ่าน event ที่มี throughput สูงระหว่างบริการ หรือการผลักดันการอัปเดตแบบ real-time การทำ server-side และ bidirectional streaming คือฟีเจอร์พื้นฐาน ไม่ใช่การแก้ปัญหาแบบ long-polling ที่เอาเทปมาแปะไว้บน framework แบบ request-response
มีข้อควรระวังที่สำคัญคือ: อย่าชี้ gRPC ไปที่ browser โดยตรง โมเดลเครือข่ายของ browser ไม่ได้สื่อสารด้วย HTTP/2 ในแบบที่ gRPC คาดหวัง คุณจะลงเอยด้วยการต้องนำ grpc-web และ proxy อย่าง Envoy มาติดตั้งเพิ่มใน stack เพียงเพื่อให้ browser คุยกับ backend ได้ นั่นไม่ใช่ข้อผิดพลาด (bug) แต่มันคือสัญญาณบอกขอบเขต (boundary signal) จงเก็บ gRPC ไว้หลัง firewall ของคุณ ระหว่างบริการที่เชื่อใจกัน และยอมรับความซับซ้อนในการดีบั๊กว่าเป็นราคาที่ต้องจ่ายเพื่อแลกกับความเร็ว เนื่องจาก binary payload ไม่สามารถอ่านด้วยตาเปล่าใน log file ได้ง่ายเหมือน JSON
Complex UIs and Mobile: GraphQL's Niche
หน้าจอมือถือสมัยใหม่เป็นการรวมกันของหลายส่วน (patchworks) หน้าจอหนึ่งอาจต้องการข้อมูลโปรไฟล์ผู้ใช้,