BloomRPC là câu trả lời cho câu hỏi mà mọi nhà phát triển gRPC cuối cùng cũng hỏi: “Postman cho gRPC của tôi đâu?” Tải một tệp .proto, nhận một thân yêu cầu JSON có thể chỉnh sửa, nhấn gửi. Nó đơn giản, miễn phí và đã đạt được khoảng 9.000 sao trên GitHub nhờ làm tốt một việc duy nhất. Sau đó, vào ngày 4 tháng 1 năm 2023, kho lưu trữ đã bị ngừng phát triển. README không nói vòng vo: dự án bị đình trệ, các vấn đề chồng chất, và những người duy trì giờ đây thẳng thắn tuyên bố rằng “việc sử dụng nó không còn được khuyến nghị nữa.” Họ chỉ bạn đến danh sách awesome-grpc và chúc bạn may mắn.
Đây là câu trả lời trực tiếp: Apidog là giải pháp thay thế BloomRPC tốt nhất cho hầu hết các nhóm, bởi vì nó không chỉ thay thế cửa sổ tải .proto. Nó hỗ trợ cả bốn loại cuộc gọi gRPC (đơn hướng, luồng từ máy chủ, luồng từ máy khách và luồng hai chiều), nhập tệp .proto từ một đường dẫn cục bộ, một URL hoặc phản ánh máy chủ (server reflection), và đặt công việc gRPC của bạn vào cùng một dự án với các điểm cuối REST, WebSocket và GraphQL của bạn, kèm theo tài liệu, khả năng cộng tác và các thiết lập gỡ lỗi đã lưu. Nếu bạn chỉ cần một cuộc gọi dùng một lần từ terminal, có những công cụ nhẹ hơn, và chúng tôi cũng sẽ đề cập đến chúng một cách trung thực. Bài viết này giải thích điều gì đã kết thúc với BloomRPC, nên thay thế nó bằng gì và chính xác cách di chuyển.
BloomRPC là gì và tại sao nó không còn tồn tại
BloomRPC ra mắt vào năm 2018 dưới dạng một ứng dụng máy tính để bàn Electron với một nhiệm vụ duy nhất: thực hiện các cuộc gọi gRPC mà không cần viết ứng dụng khách. Bạn nhập các tệp .proto của mình, nó liệt kê các dịch vụ và phương thức, tạo một khung JSON cho mỗi thông báo yêu cầu và cho phép bạn chỉnh sửa siêu dữ liệu và gửi. Đối với các cuộc gọi đơn hướng và truyền phát cơ bản, nó hoạt động tốt, và “tốt và miễn phí” đã biến nó thành GUI gRPC mặc định trong nhiều năm.
Thông báo ngừng phát triển đã kết thúc kỷ nguyên đó một cách rõ ràng. Một kho lưu trữ bị ngừng phát triển có nghĩa là không có sửa lỗi, không có cập nhật phụ thuộc và không có bản phát hành nào. Đối với một ứng dụng Electron, đó không phải là một trạng thái trung lập: các phiên bản Chromium và Node đi kèm sẽ hết thời gian hỗ trợ bảo mật, cú pháp proto mới hơn và các tính năng gRPC sẽ không được xử lý, và các lỗi đã biết (BloomRPC có những lỗi lâu năm liên quan đến việc nhập proto và một số luồng truyền phát nhất định) vẫn giữ nguyên. Những người duy trì đã trung thực về điều đó, điều mà nhiều dự án đã chết không làm được. Thông điệp là: ngừng cài đặt cái này.
Mọi người vẫn tìm kiếm BloomRPC vì hình dáng của công cụ này phù hợp. Câu hỏi đặt ra là liệu bạn có thay thế hình dáng đó (một cửa sổ gRPC độc lập khác) hay khắc phục sự phân mảnh cơ bản: hầu hết các nhóm sử dụng gRPC cũng sử dụng REST, và việc kiểm thử chúng bằng hai công cụ không kết nối luôn là cái giá mà BloomRPC âm thầm tính phí. Chúng tôi đã viết trước đây về điều gì tạo nên một ứng dụng khách gRPC tốt; phiên bản ngắn gọn là “tải protos, gửi cuộc gọi” giờ đây là điều hiển nhiên, và những điểm khác biệt nằm ở trên.
Câu trả lời: Apidog
Apidog là một nền tảng phát triển API được hơn 500.000 nhà phát triển sử dụng, bao gồm thiết kế, gỡ lỗi, kiểm thử, mocking và tài liệu. Hỗ trợ gRPC của nó, theo tài liệu chính thức, bao gồm những gì BloomRPC đã làm và những phần BloomRPC chưa bao giờ hoàn thành:
- Tất cả bốn loại cuộc gọi. Đơn hướng (Unary), luồng từ máy chủ (server streaming), luồng từ máy khách (client streaming) và luồng hai chiều (bidirectional streaming) đều được hỗ trợ. Các cuộc gọi truyền phát hoạt động giống như một phiên WebSocket: mở cuộc gọi, sau đó viết và gửi tin nhắn từ tab Tin nhắn trong khi một chế độ xem dòng thời gian hiển thị các tin nhắn đã gửi và nhận theo thứ tự. Hỗ trợ truyền phát của BloomRPC chỉ là một phần và có lỗi ở cuối; ở đây nó là một tính năng được ghi lại.
- Ba cách để nhập định nghĩa API của bạn. Tải một tệp .proto cục bộ, nhập từ một URL hoặc sử dụng phản ánh máy chủ (server reflection) để kéo các dịch vụ trực tiếp từ một máy chủ gRPC đang chạy mà không cần các tệp proto có sẵn. Nếu protos của bạn phụ thuộc vào các protos khác, bạn chỉ cần thêm thư mục phụ thuộc một lần.
- JSON vào, JSON ra. Giống như BloomRPC, Apidog hiển thị các thông báo protobuf dưới dạng JSON có thể chỉnh sửa, vì vậy bạn không phải mã hóa thủ công các tải trọng nhị phân. Nếu bạn cần tìm hiểu về ánh xạ đó, hãy xem protobuf sang JSON.
- TLS, siêu dữ liệu và xác thực. Chuyển đổi giữa grpc:// hoặc grpcs:// cho mỗi yêu cầu và đính kèm cấu hình siêu dữ liệu và xác thực cho các thiết lập mà các dịch vụ thực tế có. Đối với các mẫu token và mTLS, hướng dẫn xác thực gRPC của chúng tôi rất phù hợp với điều này.
- Nó không phải là một ngõ cụt. Các cuộc gọi gRPC đã lưu (URL máy chủ, tin nhắn, siêu dữ liệu) có thể chia sẻ với đồng đội và chúng nằm trong cùng một không gian làm việc với các điểm cuối REST, các kịch bản kiểm thử và tài liệu đã xuất bản của bạn. Đó là phần mà không có cửa sổ gRPC độc lập nào từng cung cấp.
Việc chuyển đổi trông như thế nào theo từng tính năng
Thực hiện cuộc gọi
Việc sử dụng hàng ngày sẽ cảm thấy quen thuộc. Nhập protos, chọn một dịch vụ và phương thức, chỉnh sửa thân JSON được tạo, đặt địa chỉ máy chủ, gửi. Các cuộc gọi đơn hướng trả về một bảng phản hồi; các cuộc gọi truyền phát mở một phiên mà bạn đẩy tin nhắn và xem dòng thời gian. Mã trạng thái được trả về dưới dạng mã trạng thái gRPC, khác với HTTP; hãy giữ tài liệu tham khảo mã trạng thái gRPC tiện dụng trong tuần đầu tiên.
Truyền phát (Streaming), cụ thể
Đây là bản nâng cấp rõ rệt nhất. Truyền phát phía máy khách và truyền phát hai chiều của BloomRPC là những nguồn phổ biến gây ra các vấn đề đang mở. Apidog tài liệu hóa cả bốn chế độ và coi một cuộc gọi truyền phát như một phiên trực tiếp chứ không phải là một yêu cầu một lần. Nếu các dịch vụ của bạn dựa vào các luồng, sự khác biệt đó là toàn bộ quyết định; để biết thêm thông tin về các chế độ này, hãy xem giải thích về truyền phát gRPC.
Phản ánh máy chủ (Server reflection)
BloomRPC yêu cầu các tệp proto. Apidog cũng hỗ trợ phản ánh máy chủ (server reflection), vì vậy bạn có thể trỏ nó vào một máy chủ đã bật phản ánh và duyệt các dịch vụ của nó mà không cần phải tìm kiếm phiên bản proto chính xác. Để nhanh chóng kiểm tra một máy chủ staging mà người khác sở hữu, điều này loại bỏ bước phiền toái nhất.
Vượt ra ngoài ứng dụng khách
Đây là bước nhảy vọt về hạng mục. Trong BloomRPC, một cuộc gọi đã gỡ lỗi sẽ biến mất khi bạn đóng cửa sổ. Trong Apidog, các dịch vụ gRPC nằm trong một dự án: đồng đội có thể sử dụng lại thiết lập gỡ lỗi đã lưu của bạn thay vì nhập lại protos và gõ lại siêu dữ liệu, và cùng một không gian làm việc chứa công việc REST và WebSocket của bạn, kiểm thử API gRPC tự động, các mock cho điểm cuối HTTP của bạn và tài liệu có thể xuất bản. Hầu hết các backend gRPC cũng phục vụ REST hoặc GraphQL ở đâu đó; nếu bạn đang cân nhắc các giới hạn giao thức đó, chúng tôi đã so sánh chúng trong REST vs GraphQL vs gRPC và đi sâu vào các đánh đổi trong gRPC vs REST.
BloomRPC so với Apidog: Tổng quan nhanh
| BloomRPC | Apidog | |
|---|---|---|
| Trạng thái | Ngừng phát triển vào tháng 1 năm 2023; README: không khuyến nghị sử dụng | Đang được phát triển tích cực |
| Cuộc gọi đơn hướng (Unary calls) | Có | Có |
| Truyền phát từ máy chủ / máy khách / hai chiều (Server / client / bidirectional streaming) | Một phần, có các vấn đề đã biết | Tất cả đều được hỗ trợ, kiểu phiên với dòng thời gian |
| Nhập Proto | Tệp .proto cục bộ | Tệp cục bộ, URL, phản ánh máy chủ (server reflection) |
| TLS | Cơ bản | Chuyển đổi grpc:// / grpcs:// cho mỗi yêu cầu |
| Siêu dữ liệu và xác thực | Chỉnh sửa siêu dữ liệu | Siêu dữ liệu cộng với cấu hình xác thực |
| Chia sẻ nhóm | Không (chỉ cục bộ) | Các cuộc gọi đã lưu được chia sẻ trong không gian làm việc nhóm |
| Các giao thức khác | Chỉ gRPC | REST, WebSocket, SSE, GraphQL, gRPC |
| Tài liệu, kiểm thử, mock | Không có | Cùng nền tảng, cùng dự án |
| Giá | Miễn phí (bị bỏ rơi) | Gói miễn phí cho tối đa 4 người dùng |
Di chuyển từ BloomRPC
Lưu ý di chuyển thành thật: không có gì để xuất. BloomRPC không giữ trạng thái di động có ý nghĩa nào, điều này khiến việc rời bỏ nó trở nên dễ dàng:
- Thu thập các tệp .proto của bạn. Chúng nằm trong repo của bạn, không phải trong BloomRPC. Đó là toàn bộ quá trình “xuất”.
- Nhập vào Apidog. Tạo một dự án, thêm các protos (hoặc URL của chúng), và thêm các thư mục phụ thuộc nếu protos của bạn nhập các protos khác. Các dịch vụ và phương thức rpc sẽ xuất hiện dưới dạng dịch vụ và phương thức. Hoặc bỏ qua hoàn toàn các tệp và sử dụng phản ánh máy chủ (server reflection) chống lại một máy chủ đang chạy.
- Đặt địa chỉ máy chủ và TLS. Nhập URL đích và chọn grpc:// hoặc grpcs://.
- Tạo lại siêu dữ liệu và xác thực. Thêm lại các tiêu đề và token mà bạn đã dán vào BloomRPC, lần này được lưu cùng với yêu cầu để bạn chỉ cần gõ chúng một lần.
- Lưu và chia sẻ. Các cuộc gọi đã lưu trở thành thiết lập gỡ lỗi chung của nhóm, đây là điều đầu tiên bạn sẽ nhận thấy mình chưa từng có.
Một người dùng BloomRPC đang hoạt động sẽ có thể gửi các cuộc gọi trong Apidog trong vòng mười phút, bởi vì các bước từ 1 đến 3 là những nghi thức tương tự mà bạn đã biết.
Các giải pháp thay thế BloomRPC đáng biết khác
Apidog là câu trả lời nếu bạn muốn gRPC bên trong một nền tảng API đầy đủ. Nếu nhu cầu của bạn hẹp hơn, hãy công bằng với các công cụ hẹp hơn:
- grpcurl: curl cho gRPC. Công cụ phù hợp cho các script shell, kiểm tra CI và các lệnh một dòng chống lại các máy chủ đã bật phản ánh; không phải GUI và cũng không giả vờ là vậy. Chúng tôi đã so sánh nó một cách chuyên sâu trong giải pháp thay thế grpcurl tốt nhất.
- grpcui: anh em của grpcurl, cung cấp giao diện người dùng web tạm thời cho một máy chủ. Tốt cho việc kiểm tra nhanh trong năm phút, không có trạng thái lưu theo thiết kế.
- Kreya: một ứng dụng khách dành cho máy tính để bàn chuyên dụng cho gRPC và REST với quy trình làm việc proto tinh tế và gói miễn phí; gần giống nhất với một người kế nhiệm trực tiếp của BloomRPC nếu bạn đặc biệt muốn một ứng dụng khách độc lập. Xem Kreya là gì và giải pháp thay thế Kreya tốt nhất để biết giới hạn của nó nằm ở đâu.
- Postman: đã thêm hỗ trợ gRPC vào năm 2022, vì vậy nếu nhóm của bạn đã trả tiền cho nó, nó hoạt động; các đánh đổi về giá cả và không gian làm việc thông thường của Postman vẫn áp dụng, được đề cập trong giải pháp thay thế Postman tốt nhất.
- evans: một REPL terminal cho gRPC với chế độ tương tác. Được những người sống trong tmux yêu thích; không phù hợp với bất kỳ ai muốn GUI của BloomRPC.
Mô hình: CLI cho tự động hóa, GUI chuyên dụng cho công việc gRPC độc lập, Apidog khi gRPC là một trong số nhiều giao thức và bạn muốn các cuộc gọi, kiểm thử và tài liệu ở một nơi.
Các câu hỏi thường gặp
BloomRPC còn được duy trì không?
Không. Kho lưu trữ đã bị ngừng phát triển vào ngày 4 tháng 1 năm 2023, và README của nó tuyên bố rằng việc sử dụng không còn được khuyến nghị nữa. Không có bản cập nhật, sửa lỗi bảo mật hay bản phát hành nào sắp tới. Bất kỳ so sánh ứng dụng khách gRPC hiện tại nào cũng nên loại trừ nó như một lựa chọn cho các thiết lập mới.
Tôi có thể nhập thiết lập BloomRPC của mình vào Apidog không?
Không có tệp nhập vì BloomRPC không lưu trữ bất kỳ thứ gì có thể di chuyển. Di chuyển có nghĩa là nhập lại các tệp .proto từ repo của bạn (hoặc sử dụng phản ánh máy chủ), sau đó đặt địa chỉ máy chủ, lược đồ TLS và siêu dữ liệu. Đây là công việc mất mười phút, và sau đó cấu hình được lưu và có thể chia sẻ thay vì bị kẹt trên một máy.
Apidog có hỗ trợ truyền phát gRPC không?
Có, tất cả bốn loại cuộc gọi: đơn hướng (unary), luồng từ máy chủ (server streaming), luồng từ máy khách (client streaming) và luồng hai chiều (bidirectional streaming). Các cuộc gọi truyền phát chạy dưới dạng các phiên trực tiếp nơi bạn gửi tin nhắn và xem dòng thời gian của lưu lượng. Để nhắc lại về thời điểm mỗi chế độ phù hợp, hãy xem truyền phát gRPC.
Nếu tôi chỉ cần các cuộc gọi gRPC dòng lệnh nhanh thì sao?
Sử dụng grpcurl. Nó xử lý tốt các cuộc gọi theo kịch bản và ad-hoc, đặc biệt là chống lại các máy chủ đã bật phản ánh, và thuộc về CI bất kể bạn chọn GUI nào. Hướng dẫn thay thế grpcurl của chúng tôi đề cập đến những trường hợp nó không còn đủ.
Tôi có thể kiểm thử API gRPC và REST bằng cùng một công cụ không?
Trong Apidog, có: gRPC, REST, WebSocket, SSE và GraphQL nằm trong một dự án, vì vậy một dịch vụ hiển thị cả gRPC và REST sẽ có một nơi chung. Hướng dẫn kiểm thử API gRPC của chúng tôi cho thấy quy trình làm việc từ đầu đến cuối.
Ngừng sử dụng ứng dụng khách đã bị ngừng phát triển
BloomRPC đã bảo bạn rời đi; câu hỏi duy nhất là đi đâu. Hãy hướng Apidog đến các tệp .proto của bạn hoặc một máy chủ đã bật phản ánh, thực hiện các cuộc gọi đơn hướng và truyền phát đầu tiên của bạn, và giữ chúng được lưu cùng với phần còn lại của công việc API của bạn. Tải xuống Apidog miễn phí; một nhóm 4 người không phải trả gì, và các protos của bạn là tệp di chuyển duy nhất bạn cần.