สุดยอดทางเลือก BloomRPC

BloomRPC คือคำตอบสำหรับคำถามที่นักพัฒนา gRPC ทุกคนต่างถามในที่สุดว่า: “Postman สำหรับ gRPC ของฉันอยู่ไหน?” เพียงแค่โหลดไฟล์ .proto ก็จะได้เนื้อหาคำขอ JSON ที่แก้ไขได้ จากนั้นก็กดส่ง มันง่าย ฟรี และได้รับดาวบน GitHub ประมาณ 9,000 ดวงจากการทำงานเพียงอย่างเดียวได้ดีเยี่ยม จากนั้นในวันที่ 4 มกราคม 2023 ที่เก็บข้อมูลถูกเก็บถาวร ไฟล์ README ระบุไว้อย่างชัดเจนว่า: โปรเจกต์หยุดชะงัก ปัญหาต่างๆ ทับถมกัน และผู้ดูแลตอนนี้ระบุอย่างตรงไปตรงมาว่า “ไม่แนะนำให้ใช้งานอีกต่อไปแล้ว” พวกเขาแนะนำให้คุณดูรายการ awesome-grpc และขอให้คุณโชคดี

นี่คือคำตอบโดยตรง: Apidog คือทางเลือกที่ดีที่สุดแทน BloomRPC สำหรับทีมส่วนใหญ่ เพราะมันไม่ได้แค่มาแทนที่หน้าต่างโหลดไฟล์ .proto เท่านั้น มันรองรับ gRPC การเรียกทั้งสี่ประเภท (unary, server streaming, client streaming และ bidirectional streaming) สามารถนำเข้าไฟล์ .proto จากเส้นทางในเครื่อง, URL หรือจาก server reflection และจัดเก็บงาน gRPC ของคุณไว้ในโปรเจกต์เดียวกับ REST, WebSocket และ GraphQL endpoints พร้อมเอกสาร การทำงานร่วมกัน และการตั้งค่าการดีบักที่บันทึกไว้ หากคุณต้องการแค่การเรียกใช้แบบชั่วคราวจากเทอร์มินัล ก็ยังมีเครื่องมือที่เบากว่า และเราจะกล่าวถึงสิ่งเหล่านั้นด้วยความสัตย์จริงเช่นกัน บทความนี้จะอธิบายว่าเกิดอะไรขึ้นกับ BloomRPC ทำไมมันถึงหายไป และจะใช้สิ่งใดมาแทนที่ รวมถึงวิธีการย้ายข้อมูลอย่างละเอียด

BloomRPC คืออะไร และทำไมมันถึงหายไป

BloomRPC เปิดตัวในปี 2018 ในฐานะแอปพลิเคชันเดสก์ท็อป Electron ที่มีภารกิจเดียวคือ: สร้างการเรียก gRPC โดยไม่ต้องเขียนโค้ดฝั่งไคลเอนต์ คุณสามารถนำเข้าไฟล์ .proto ของคุณ มันจะแสดงรายการบริการและเมธอด สร้างโครงร่าง JSON สำหรับข้อความคำขอแต่ละรายการ และให้คุณแก้ไขข้อมูลเมตาแล้วส่งได้ สำหรับการเรียกแบบ unary และการสตรีมพื้นฐาน มันทำงานได้ดี และด้วยความ “ดีและฟรี” ทำให้มันเป็น gRPC GUI เริ่มต้นมาหลายปี

ประกาศการเก็บถาวรได้ยุติยุคนั้นลงอย่างสมบูรณ์ ที่เก็บข้อมูลที่ถูกเก็บถาวรหมายความว่าจะไม่มีการแก้ไขข้อผิดพลาด ไม่มีการอัปเดตการพึ่งพา และไม่มีการเผยแพร่ใดๆ สำหรับแอป Electron นั่นไม่ใช่สถานะที่เป็นกลาง: เวอร์ชัน Chromium และ Node ที่มาพร้อมกันจะหมดอายุการสนับสนุนด้านความปลอดภัย ไวยากรณ์ proto และคุณสมบัติ gRPC ใหม่ๆ จะไม่ได้รับการจัดการ และข้อผิดพลาดที่ทราบ (BloomRPC มีปัญหาที่ค้างคานานเกี่ยวกับการนำเข้า proto และการสตรีมบางประเภท) ก็จะยังคงอยู่เช่นเดิม ผู้ดูแลโครงการมีความซื่อสัตย์เกี่ยวกับเรื่องนี้ ซึ่งเป็นสิ่งที่โปรเจกต์ที่หยุดพัฒนาหลายๆ โปรเจกต์ทำไม่ได้ ข้อความคือ: หยุดติดตั้งสิ่งนี้

ผู้คนยังคงค้นหา BloomRPC เพราะรูปแบบของเครื่องมือมันถูกต้อง คำถามคือคุณจะแทนที่รูปแบบ (หน้าต่าง gRPC แบบสแตนด์อโลนอีกอัน) หรือแก้ไขการแยกส่วนที่อยู่เบื้องหลัง: ทีมส่วนใหญ่ที่รัน gRPC ก็รัน REST ด้วย และการทดสอบสิ่งเหล่านี้ด้วยเครื่องมือสองตัวที่แยกจากกันคือภาระที่ BloomRPC แอบเรียกเก็บมาโดยตลอด เราเคยเขียนไว้ก่อนหน้านี้ว่าอะไรทำให้ gRPC client ที่ดี; สรุปสั้นๆ คือ "โหลด protos, ส่ง calls" ตอนนี้เป็นเรื่องพื้นฐานแล้ว และความแตกต่างที่แท้จริงอยู่เหนือกว่านั้น

คำตอบ: Apidog

Apidog คือแพลตฟอร์มการพัฒนา API ที่นักพัฒนากว่า 500,000 คนใช้งาน ครอบคลุมการออกแบบ การดีบัก การทดสอบ การจำลอง และการจัดทำเอกสาร การรองรับ gRPC ของ Apidog ตาม เอกสารทางการ ครอบคลุมสิ่งที่ BloomRPC ทำได้และส่วนที่ BloomRPC ไม่เคยทำเสร็จ:

1. การเรียกทั้งสี่ประเภท รองรับ Unary, server streaming, client streaming และ bidirectional streaming ทั้งหมด การเรียกแบบสตรีมมิ่งทำงานเหมือนเซสชัน WebSocket: เปิดการเรียก แล้วเขียนและส่งข้อความจากแท็บ Message ในขณะที่มุมมองไทม์ไลน์แสดงข้อความที่ส่งและรับตามลำดับ การรองรับการสตรีมมิ่งของ BloomRPC นั้นไม่สมบูรณ์และมีข้อบกพร่องในช่วงท้าย; แต่ในที่นี้มันเป็นคุณสมบัติที่ได้รับการบันทึกไว้
2. สามวิธีในการนำเข้านิยาม API ของคุณ โหลดไฟล์ .proto ในเครื่อง, นำเข้าจาก URL หรือใช้ server reflection เพื่อดึงบริการโดยตรงจาก gRPC server ที่กำลังทำงานอยู่โดยไม่ต้องมีไฟล์ proto ในมือ หาก protos ของคุณขึ้นอยู่กับ protos อื่นๆ คุณสามารถเพิ่มไดเรกทอรีการพึ่งพาเพียงครั้งเดียว
3. JSON เข้า, JSON ออก เช่นเดียวกับ BloomRPC, Apidog แสดงข้อความ protobuf เป็น JSON ที่แก้ไขได้ ดังนั้นคุณจึงไม่ต้องเข้ารหัสข้อมูลไบนารีด้วยตนเอง หากคุณต้องการทำความเข้าใจการแมปนั้น ให้ดู protobuf เป็น JSON
4. TLS, metadata และการยืนยันตัวตน สลับ grpc:// หรือ grpcs:// ต่อคำขอ และแนบข้อมูลเมตาและการตั้งค่าการยืนยันตัวตนสำหรับการตั้งค่าที่บริการจริงมีอยู่จริง สำหรับรูปแบบโทเค็นและ mTLS, คู่มือการยืนยันตัวตน gRPC ของเราเข้ากันได้ดีกับสิ่งนี้
5. ไม่ใช่ทางตัน การเรียก gRPC ที่บันทึกไว้ (URL เซิร์ฟเวอร์, ข้อความ, ข้อมูลเมตา) สามารถแชร์กับเพื่อนร่วมทีมได้ และอยู่ร่วมกันในพื้นที่ทำงานเดียวกับ REST endpoints, สถานการณ์ทดสอบ และเอกสารที่เผยแพร่ของคุณ นั่นคือส่วนที่ไม่มีหน้าต่าง gRPC แบบสแตนด์อโลนใดๆ เคยมีให้

การเปลี่ยนแปลงที่เห็นได้จากคุณสมบัติแต่ละอย่าง

การเรียกใช้

การใช้งานในแต่ละวันจะให้ความรู้สึกคุ้นเคย นำเข้า protos, เลือกบริการและเมธอด, แก้ไขเนื้อหา JSON ที่สร้างขึ้น, ตั้งค่าที่อยู่เซิร์ฟเวอร์, แล้วส่ง การเรียกแบบ Unary จะคืนค่าหน้าต่างการตอบกลับ; การเรียกแบบสตรีมมิ่งจะเปิดเซสชันที่คุณสามารถส่งข้อความและดูไทม์ไลน์ได้ รหัสสถานะจะกลับมาเป็นรหัสสถานะ gRPC ซึ่งอ่านต่างจาก HTTP; ควรเก็บ ข้อมูลอ้างอิงรหัสสถานะ gRPC ไว้ใกล้มือในช่วงสัปดาห์แรก

การสตรีมมิ่งโดยเฉพาะ

นี่คือการอัปเกรดที่โดดเด่นที่สุด การสตรีมมิ่งฝั่งไคลเอ็นต์และแบบสองทางของ BloomRPC เป็นแหล่งที่มาของปัญหาที่เปิดค้างบ่อยครั้ง Apidog ได้จัดทำเอกสารสำหรับทั้งสี่โหมด และถือว่าการเรียกแบบสตรีมมิ่งเป็นการเชื่อมต่อแบบสด (live session) มากกว่าคำขอแบบครั้งเดียว (one-shot request) หากบริการของคุณพึ่งพาการสตรีมมิ่งเป็นหลัก ความแตกต่างนี้คือทั้งหมดของการตัดสินใจ; สำหรับข้อมูลพื้นฐานเกี่ยวกับโหมดต่างๆ ดู gRPC streaming อธิบาย

Server reflection

BloomRPC ต้องใช้ไฟล์ proto Apidog ยังรองรับ server reflection ดังนั้นคุณจึงสามารถชี้ไปยังเซิร์ฟเวอร์ที่เปิดใช้งาน reflection และเรียกดูบริการต่างๆ ได้โดยไม่ต้องตามหา proto revision ที่ถูกต้อง สำหรับการตรวจสอบเซิร์ฟเวอร์ staging ของคนอื่นอย่างรวดเร็ว นี่จะช่วยขจัดขั้นตอนที่น่ารำคาญที่สุดออกไป

เหนือกว่าแค่ไคลเอนต์

นี่คือการก้าวกระโดดของหมวดหมู่ ใน BloomRPC การเรียกที่ถูกดีบักจะหายไปเมื่อคุณปิดหน้าต่าง ใน Apidog บริการ gRPC จะอยู่ในโปรเจกต์: เพื่อนร่วมทีมสามารถนำการตั้งค่าการดีบักที่คุณบันทึกไว้กลับมาใช้ใหม่ได้ แทนที่จะต้องนำเข้า protos และพิมพ์ metadata ซ้ำๆ และพื้นที่ทำงานเดียวกันนี้ยังเก็บงาน REST และ WebSocket ของคุณ, การทดสอบ gRPC API อัตโนมัติ, mocks สำหรับ HTTP endpoints ของคุณ และเอกสารที่เผยแพร่ได้ แบ็กเอนด์ gRPC ส่วนใหญ่ยังให้บริการ REST หรือ GraphQL อยู่ด้วย; หากคุณกำลังชั่งน้ำหนักขอบเขตของโปรโตคอลเหล่านี้ เราได้เปรียบเทียบไว้ใน REST vs GraphQL vs gRPC และเจาะลึกถึงข้อดีข้อเสียใน gRPC vs REST

BloomRPC vs Apidog: ภาพรวม

การย้ายข้อมูลจาก BloomRPC

หมายเหตุการย้ายข้อมูลที่ซื่อสัตย์: ไม่มีอะไรต้องส่งออก BloomRPC ไม่ได้เก็บสถานะที่สามารถพกพาได้อย่างมีความหมาย ทำให้การทิ้งมันไปเป็นเรื่องเล็กน้อย:

1. รวบรวมไฟล์ .proto ของคุณ พวกมันอยู่ใน repository ของคุณ ไม่ได้อยู่ใน BloomRPC นั่นคือ "การส่งออก" ทั้งหมด
2. นำเข้าสู่ Apidog สร้างโปรเจกต์ เพิ่ม protos (หรือ URL ของมัน) และเพิ่มไดเรกทอรีการพึ่งพาหาก protos ของคุณนำเข้าไฟล์อื่น บริการและเมธอด rpc จะปรากฏเป็นบริการและเมธอด หรือจะข้ามไฟล์ไปทั้งหมดแล้วใช้ server reflection กับเซิร์ฟเวอร์ที่กำลังทำงานอยู่ก็ได้
3. ตั้งค่าที่อยู่เซิร์ฟเวอร์และ TLS ป้อน URL เป้าหมายและเลือก grpc:// หรือ grpcs://
4. สร้างเมตาดาตาและการยืนยันตัวตนใหม่ เพิ่มส่วนหัวและโทเค็นที่คุณเคยแปะใน BloomRPC ซ้ำอีกครั้ง คราวนี้จะถูกบันทึกพร้อมคำขอเพื่อให้คุณพิมพ์เพียงครั้งเดียว
5. บันทึกและแชร์ การเรียกที่บันทึกไว้จะกลายเป็นเป็นการตั้งค่าการดีบักที่แชร์กันในทีม ซึ่งเป็นสิ่งแรกที่คุณจะสังเกตเห็นว่าคุณไม่เคยมีมาก่อน

ผู้ใช้ BloomRPC ที่ใช้งานได้ควรจะสามารถส่งการเรียกใน Apidog ได้ภายในสิบนาที เพราะขั้นตอนที่ 1 ถึง 3 เป็นพิธีกรรมเดียวกันที่คุณรู้อยู่แล้ว

ทางเลือกอื่นๆ แทน BloomRPC ที่ควรทราบ

Apidog คือคำตอบหากคุณต้องการ gRPC ภายในแพลตฟอร์ม API ที่สมบูรณ์ หากความต้องการของคุณแคบลง ก็ควรพิจารณาเครื่องมือที่เฉพาะเจาะจงมากขึ้น:

• grpcurl: curl สำหรับ gRPC เป็นเครื่องมือที่เหมาะสมสำหรับ shell scripts, การตรวจสอบ CI และการใช้คำสั่งบรรทัดเดียวกับเซิร์ฟเวอร์ที่เปิดใช้งาน reflection; ไม่ใช่ GUI และไม่ได้แกล้งทำเป็นอย่างนั้น เราได้เปรียบเทียบอย่างละเอียดใน ทางเลือกที่ดีที่สุดสำหรับ grpcurl
• grpcui: น้องชายของ grpcurl ที่ให้บริการ UI บนเว็บชั่วคราวสำหรับเซิร์ฟเวอร์เดียว เหมาะสำหรับการทดสอบสั้นๆ ห้านาที โดยไม่มีการบันทึกสถานะตามการออกแบบ
• Kreya: ไคลเอนต์เดสก์ท็อปเฉพาะสำหรับ gRPC และ REST พร้อมเวิร์กโฟลว์ proto ที่ประณีตและแผนบริการฟรี; เป็นสิ่งที่ใกล้เคียงที่สุดกับ BloomRPC โดยตรง หากคุณต้องการไคลเอนต์แบบสแตนด์อโลนโดยเฉพาะ ดู Kreya คืออะไร และ ทางเลือกที่ดีที่สุดสำหรับ Kreya เพื่อดูข้อจำกัดของมัน
• Postman: เพิ่มการรองรับ gRPC ในปี 2022 ดังนั้นหากทีมของคุณจ่ายเงินเพื่อใช้งานอยู่แล้ว มันก็ใช้งานได้; การกำหนดราคาและข้อจำกัดของพื้นที่ทำงานของ Postman ทั่วไปยังคงใช้ได้ ซึ่งครอบคลุมใน ทางเลือกที่ดีที่สุดสำหรับ Postman
• evans: REPL สำหรับ gRPC ในเทอร์มินัลพร้อมโหมดอินเทอร์แอคทีฟ เป็นที่ชื่นชอบของผู้ที่ใช้ tmux เป็นหลัก; แต่ไม่ใช่ทางเลือกสำหรับผู้ที่ต้องการ GUI ของ BloomRPC

รูปแบบ: CLIs สำหรับระบบอัตโนมัติ, GUIs วัตถุประสงค์เดียวสำหรับงาน gRPC ที่แยกออกมา, Apidog เมื่อ gRPC เป็นหนึ่งในหลายๆ โปรโตคอล และคุณต้องการการเรียก, การทดสอบ และเอกสารในที่เดียว

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

BloomRPC ยังได้รับการดูแลอยู่หรือไม่?

ไม่ ที่เก็บข้อมูลถูกเก็บถาวรเมื่อวันที่ 4 มกราคม 2023 และไฟล์ README ระบุว่าไม่แนะนำให้ใช้งานอีกต่อไป จะไม่มีการอัปเดต การแก้ไขช่องโหว่ด้านความปลอดภัย หรือการเผยแพร่ใดๆ ในการเปรียบเทียบ gRPC client ในปัจจุบันควรรวมออกจากการเป็นตัวเลือกสำหรับการตั้งค่าใหม่

ฉันสามารถนำเข้าการตั้งค่า BloomRPC ของฉันไปยัง Apidog ได้หรือไม่?

ไม่มีไฟล์นำเข้าใดๆ เพราะ BloomRPC ไม่ได้เก็บข้อมูลที่สามารถพกพาได้ การย้ายข้อมูลหมายถึงการนำเข้าไฟล์ .proto จาก repository ของคุณซ้ำ (หรือใช้ server reflection) จากนั้นตั้งค่าที่อยู่เซิร์ฟเวอร์, รูปแบบ TLS และ metadata เป็นงานที่ใช้เวลาประมาณสิบนาที และหลังจากนั้นการตั้งค่าจะถูกบันทึกและสามารถแชร์ได้ แทนที่จะถูกจำกัดอยู่บนเครื่องเดียว

Apidog รองรับ gRPC streaming หรือไม่?

ใช่ รองรับการเรียกทั้งสี่ประเภท: unary, server streaming, client streaming และ bidirectional streaming การเรียกแบบสตรีมมิ่งทำงานเป็นเซสชันสดที่คุณสามารถส่งข้อความและดูไทม์ไลน์ของการรับส่งข้อมูล สำหรับการทบทวนว่าแต่ละโหมดเหมาะสมกับเมื่อใด ดู gRPC streaming

ถ้าฉันต้องการแค่การเรียก gRPC ผ่านคอมมานด์ไลน์อย่างรวดเร็วล่ะ?

ใช้ grpcurl มันจัดการการเรียกแบบสคริปต์และแบบเฉพาะกิจได้ดี โดยเฉพาะกับเซิร์ฟเวอร์ที่เปิดใช้งาน reflection และควรอยู่ใน CI ไม่ว่าคุณจะเลือก GUI ใดก็ตาม คู่มือทางเลือก grpcurl ของเราครอบคลุมถึงจุดที่มันไม่เพียงพออีกต่อไป

ฉันสามารถทดสอบ gRPC และ REST API ในเครื่องมือเดียวกันได้หรือไม่?

ใน Apidog, ใช่: gRPC, REST, WebSocket, SSE และ GraphQL อยู่ในโปรเจกต์เดียวกัน ดังนั้นบริการที่เปิดเผยทั้ง gRPC และ REST จะมีบ้านหลังเดียวกัน คู่มือการทดสอบ gRPC API ของเราแสดงเวิร์กโฟลว์ตั้งแต่ต้นจนจบ

เลิกใช้ไคลเอนต์ที่ถูกเก็บถาวร

BloomRPC บอกให้คุณไปจากมัน คำถามเดียวคือจะไปที่ไหน ชี้ Apidog ไปที่ไฟล์ .proto ของคุณ หรือเซิร์ฟเวอร์ที่เปิดใช้งาน reflection ทำการเรียก unary และ streaming ครั้งแรกของคุณ และเก็บพวกมันไว้ข้างๆ งาน API อื่นๆ ของคุณ ดาวน์โหลด Apidog ฟรี; ทีมที่มีผู้ใช้ 4 คนไม่ต้องเสียค่าใช้จ่ายใดๆ และ protos ของคุณคือไฟล์ย้ายข้อมูลเดียวที่คุณต้องการ