grpcurl là công cụ dòng lệnh ưa thích để tương tác với các dịch vụ gRPC, nhưng một lệnh terminal nặng cờ (flag-heavy) không phải lúc nào cũng là cách nhanh nhất để khám phá API, phát lại các cuộc gọi streaming, hoặc chia sẻ yêu cầu với đồng đội. Nếu bạn muốn một client gRPC trực quan hoặc một công cụ có thể làm được nhiều hơn là chỉ gọi một phương thức tại một thời điểm, hướng dẫn này sẽ giới thiệu sáu lựa chọn thay thế cho grpcurl, cả GUI và CLI, với những nhận xét chân thực về điểm mạnh của từng công cụ.
grpcurl là gì và những hạn chế của nó
grpcurl giống như curl dành cho gRPC. Bạn trỏ nó đến một máy chủ, đặt tên dịch vụ và phương thức, truyền một JSON request body, và nó sẽ trả về phản hồi. Nó hỗ trợ phản ánh máy chủ (server reflection), vì vậy nó có thể liệt kê các dịch vụ và phương thức mà không cần bạn cung cấp file .proto, và nó hoạt động với TLS, tiêu đề metadata, và các mô tả .proto hoặc protoset khi phản ánh bị tắt.
Điều đó bao gồm rất nhiều tính năng. Để kiểm tra nhanh tình trạng hoặc thực hiện một cuộc gọi script trong CI, grpcurl khó có thể bị đánh bại. Dưới đây là những điểm bất tiện của nó:
- Nó chỉ hoạt động trên CLI. Mỗi cuộc gọi là một lệnh, và việc khám phá một API không quen thuộc có nghĩa là bạn phải đọc danh sách phương thức trong terminal và tự gõ JSON.
- Streaming rất cồng kềnh. grpcurl có thể thực hiện streaming client, server và hai chiều, nhưng bạn phải nhập các thông báo dưới dạng một luồng JSON trên stdin. Không có cách trực quan nào để xem luồng server đến từng thông báo một.
- Các yêu cầu không được lưu. Không có bộ sưu tập, lịch sử hay chức năng chuyển đổi môi trường tích hợp. Bạn phải tự quản lý điều đó bằng các shell script hoặc một file ghi chú.
- Chia sẻ có nghĩa là chia sẻ một chuỗi lệnh. Không có không gian làm việc chung, không có ví dụ đã lưu mà đồng đội có thể mở và chạy.
Không điều nào trong số đó làm cho grpcurl trở nên tồi tệ. Nó chỉ khiến nó trở thành một công cụ chuyên biệt. Nếu công việc của bạn đã phát triển vượt ra ngoài các cuộc gọi script đơn lẻ, một trong các lựa chọn dưới đây sẽ phù hợp hơn.
Tổng quan về các lựa chọn thay thế cho grpcurl
| Công cụ | Giao diện | Hỗ trợ streaming | Reflection (Phản ánh) | Tốt nhất cho |
|---|---|---|---|---|
| Apidog | GUI (máy tính để bàn) | Unary + server, client, hai chiều | Có | Kiểm thử gRPC trực quan cùng với REST, GraphQL và tài liệu |
| grpcui | Giao diện web | Unary + streaming | Có | Một giao diện trình duyệt cho grpcurl, cùng tác giả |
| Postman | GUI (máy tính để bàn/web) | Unary + streaming | Có | Các nhóm đã tiêu chuẩn hóa trên Postman |
| Kreya | GUI (máy tính để bàn) | Unary + streaming | Có | Một client máy tính để bàn tập trung vào gRPC và REST |
| Evans | CLI tương tác | Unary + streaming | Có | Quy trình làm việc terminal kiểu REPL |
| BloomRPC | GUI (máy tính để bàn) | Unary + streaming | Hạn chế | Chỉ dành cho các dự án cũ (không được bảo trì) |
1. Apidog (client gRPC trực quan)
Apidog là một nền tảng API xử lý REST, GraphQL, WebSocket, SOAP và gRPC trong một ứng dụng máy tính để bàn duy nhất, vì vậy gRPC nằm cạnh các công việc API khác của bạn thay vì trong một terminal riêng biệt. Đặc biệt đối với gRPC, bạn nhập một tệp .proto hoặc kết nối thông qua server reflection (phản ánh máy chủ), và Apidog sẽ đọc các định nghĩa dịch vụ và phương thức cho bạn.
Từ đó, bạn có một trình xây dựng yêu cầu dựa trên biểu mẫu. Các phương thức xuất hiện trong một danh sách bạn có thể nhấp vào, các thông báo yêu cầu hiển thị dưới dạng các trường có thể chỉnh sửa dựa trên schema proto, và các phản hồi được định dạng. Tất cả bốn loại cuộc gọi gRPC đều hoạt động: unary, server streaming, client streaming và bidirectional streaming. Đối với server streaming, bạn xem các thông báo xuất hiện trong bảng phản hồi khi chúng đến, đây là phần mà grpcurl khiến bạn phải nheo mắt nhìn trên stdout.
Phạm vi chân thực: Apidog là một client gRPC GUI, không phải là một sự thay thế CLI một đối một cho grpcurl. Nếu nhu cầu thực sự của bạn là một binary có thể script được mà bạn đưa vào một pipeline shell, grpcurl hoặc Evans sẽ phù hợp hơn với hình dạng đó. Điểm mạnh của Apidog là khám phá, lưu các yêu cầu, biến môi trường cho các điểm cuối và metadata, và giữ gRPC trong cùng một không gian làm việc với các giao thức khác của bạn. Nếu bạn xây dựng các dịch vụ trên nhiều giao thức, quy trình làm việc API đa giao thức sẽ mượt mà hơn khi một công cụ bao gồm tất cả chúng.
Tải xuống Apidog để nhập một tệp .proto và thực hiện cuộc gọi streaming đầu tiên của bạn trong một GUI.
2. grpcui
grpcui đến từ cùng tác giả với grpcurl, fullstorydev, và nó là bước tiếp theo tự nhiên nếu bạn thích grpcurl nhưng muốn một giao diện trực quan. Nó khởi động một máy chủ web cục bộ cung cấp cho bạn một biểu mẫu trình duyệt để gọi các phương thức gRPC. Bạn có các menu thả xuống cho các dịch vụ và phương thức, các trường biểu mẫu được tạo tự động cho các thông báo yêu cầu và các trường nhập metadata, tất cả đều được hỗ trợ bởi server reflection hoặc proto descriptors.
Nó hỗ trợ streaming và phản ánh cùng một bộ tính năng gRPC mà bạn mong đợi từ dòng công cụ grpcurl. Điểm đánh đổi là grpcui chỉ có một mục đích duy nhất. Nó là một công cụ khám phá gRPC và không gì khác, vì vậy không có kiểm thử REST, không có bộ sưu tập được lưu giữa các phiên, và không có không gian làm việc nhóm. Nếu bạn muốn một giao diện trình duyệt nhanh chóng trên một máy chủ duy nhất, nó hoàn toàn phù hợp. Kho lưu trữ grpcui có chi tiết cài đặt.
3. Postman
Postman đã thêm hỗ trợ gRPC, và nếu nhóm của bạn đã sử dụng Postman thì việc dùng nó trước khi thêm một công cụ khác là đáng giá. Bạn tạo một yêu cầu gRPC, trỏ nó đến một máy chủ, tải một tệp .proto (hoặc sử dụng một máy chủ hỗ trợ reflection), và gọi các phương thức thông qua giao diện người dùng của Postman. Nó xử lý các cuộc gọi unary và streaming, cho phép bạn thiết lập metadata và ủy quyền, và lưu các yêu cầu trong các bộ sưu tập giống như phần còn lại của công việc Postman của bạn.
Những điểm mạnh là có thật: các bộ sưu tập, môi trường và một không gian làm việc mà nhóm của bạn đã quen thuộc. Vấn đề là gRPC trong Postman trong quá khứ đã bị chậm hơn so với trải nghiệm REST về độ trau chuốt, và các tài khoản Postman nặng hơn đi kèm với các cân nhắc về đồng bộ hóa đám mây và giá cả mà một số nhóm muốn tránh. Nếu bạn đang cân nhắc công cụ rộng hơn, hãy xem tổng hợp của chúng tôi về các lựa chọn thay thế Postman để kiểm thử API. Tài liệu gRPC của Postman bao gồm bộ tính năng hiện tại.
4. Kreya
Kreya là một client máy tính để bàn tập trung vào gRPC và REST. Nó đọc các tệp .proto và hỗ trợ server reflection, tạo các biểu mẫu yêu cầu từ schema của bạn, và xử lý tất cả các chế độ streaming. Nó tập trung vào một bố cục sạch sẽ, dựa trên dự án, nơi bạn tổ chức các cuộc gọi, thiết lập môi trường và tái sử dụng các biến, điều này làm cho nó trở thành một lựa chọn vững chắc nếu bạn muốn một GUI gRPC chuyên dụng mà không cần một nền tảng đầy đủ xung quanh nó.
Nó có phạm vi nhẹ hơn so với một nền tảng API đầy đủ, vì vậy bạn sẽ không tìm thấy các tính năng mocking, tạo tài liệu hoặc công cụ thiết kế. Đối với các nhà phát triển chủ yếu cần khám phá và kiểm thử các dịch vụ gRPC với một giao diện gọn gàng, sự tập trung đó là một tính năng, chứ không phải một thiếu sót.
5. Evans
Evans là một client gRPC tương tác hoạt động trong terminal của bạn nhưng hành xử giống một REPL hơn là một lệnh chạy một lần. Bạn bắt đầu một phiên, và Evans cho phép bạn duyệt các gói, dịch vụ và phương thức, sau đó xây dựng và gửi các yêu cầu một cách tương tác. Nó hỗ trợ server reflection và các tệp .proto, xử lý streaming, và giữ bạn trong một dấu nhắc được hướng dẫn thay vì buộc bạn phải nhớ mọi flag.
Nếu bạn muốn cảm giác hoạt động như terminal của grpcurl nhưng lại ghét việc gõ lại các lệnh gọi dài, Evans là giải pháp trung gian. Nó vẫn là một công cụ CLI, vì vậy không có chế độ xem streaming trực quan và không có không gian làm việc chung, nhưng chế độ tương tác loại bỏ rất nhiều sự bất tiện của grpcurl. Kho lưu trữ GitHub của Evans có hướng dẫn cài đặt.
6. BloomRPC (chỉ dành cho các dự án cũ)
BloomRPC từng là một GUI gRPC mã nguồn mở phổ biến, một ứng dụng máy tính để bàn với trình khám phá phương thức và trình chỉnh sửa yêu cầu. Nó vẫn được đề cập trong các hướng dẫn cũ hơn, vì vậy đáng để nhắc đến, nhưng dự án này không còn được duy trì tích cực nữa. Điều đó có nghĩa là các tính năng gRPC mới hơn, cập nhật phụ thuộc và các bản vá lỗi tương thích hệ điều hành không còn được phát hành.
Đừng chọn BloomRPC cho một dự án mới. Nếu bạn kế thừa một quy trình làm việc được xây dựng xung quanh nó, hãy lên kế hoạch chuyển sang một trong các lựa chọn được duy trì ở trên. Chúng tôi liệt kê nó ở đây chỉ để bạn biết nó là gì và tại sao nó không còn là một khuyến nghị hiện tại.
Cách lựa chọn
Hãy chọn công cụ phù hợp với cách bạn thực sự làm việc:
- Bạn muốn một client gRPC trực quan với tính năng streaming mà bạn có thể xem và các yêu cầu bạn có thể lưu và chia sẻ: Apidog.
- Bạn thích grpcurl và muốn một biểu mẫu trình duyệt trên đó: grpcui.
- Nhóm của bạn đã tiêu chuẩn hóa trên Postman: hỗ trợ gRPC của Postman.
- Bạn muốn một client máy tính để bàn tập trung vào gRPC và REST: Kreya.
- Bạn muốn ở lại terminal nhưng không muốn mệt mỏi vì cờ lệnh: Evans.
- Bạn đang duy trì một thiết lập cũ: hãy biết rằng BloomRPC không được duy trì và lên kế hoạch di chuyển.
Nếu bạn đang kiểm thử gRPC từ đầu đến cuối và muốn hướng dẫn chi tiết từng phương thức, hướng dẫn của chúng tôi về cách kiểm thử API gRPC hiệu quả sẽ đi sâu vào quy trình làm việc, và hướng dẫn grpc-curl ban đầu vẫn là điểm khởi đầu đúng đắn nếu bạn cam kết sử dụng dòng lệnh.
Các câu hỏi thường gặp
Có phiên bản GUI nào của grpcurl không?
grpcui, từ cùng tác giả, là GUI trực tiếp gần nhất: nó đặt một biểu mẫu trình duyệt lên trên cùng cơ chế phản ánh và xử lý proto mà grpcurl sử dụng. Nếu bạn muốn một ứng dụng máy tính để bàn đầy đủ với các yêu cầu đã lưu, môi trường và streaming mà bạn có thể xem trực quan, Apidog bao gồm gRPC cùng với REST và GraphQL trong một client.
Tôi có thể kiểm thử gRPC streaming mà không cần dòng lệnh không?
Có. Apidog, Postman, Kreya và grpcui đều hỗ trợ gRPC streaming thông qua giao diện người dùng, bao gồm cả server streaming nơi các thông báo hiển thị khi chúng đến. grpcurl và Evans cũng có thể streaming, nhưng chúng cấp và hiển thị thông báo dưới dạng văn bản terminal thay vì một bảng điều khiển trực quan.
Những công cụ này có cần tệp .proto không?
Không phải lúc nào cũng cần. Mọi công cụ ở đây đều hỗ trợ gRPC server reflection, vì vậy nếu máy chủ của bạn hiển thị reflection, client có thể tự động khám phá các dịch vụ và phương thức. Khi reflection bị tắt, bạn cung cấp một tệp .proto hoặc một protoset đã biên dịch, và hầu hết các công cụ này đều chấp nhận cả hai. Để có cái nhìn tổng quan hơn về kiểm thử, hướng dẫn toàn diện về kiểm thử API giải thích vị trí của gRPC trong số REST và các giao thức khác.
grpcurl có còn đáng dùng không?
Hoàn toàn có, nếu dùng đúng mục đích. grpcurl rất tuyệt vời cho các cuộc gọi script, kiểm tra CI và các lệnh gọi nhanh chóng, một lần từ terminal. Các lựa chọn thay thế ở đây trở nên quan trọng khi bạn vượt ra khỏi các lệnh đơn lẻ và muốn khám phá trực quan, các bộ sưu tập đã lưu, streaming có thể xem được hoặc một không gian làm việc nhóm chung.
Kết luận
grpcurl là một công cụ sắc bén cho gRPC dòng lệnh, và không gì ở đây có thể thay thế nó cho các cuộc gọi được script, nguyên bản trên terminal. Điều thay đổi là công việc. Một khi bạn đang khám phá các dịch vụ không quen thuộc, xem các luồng, hoặc chia sẻ yêu cầu với một nhóm, một client trực quan sẽ tiết kiệm thời gian thực sự. Trong số các lựa chọn GUI, Apidog nổi bật vì nó đặt gRPC, REST, GraphQL, mocking và tài liệu vào cùng một nơi, vì vậy việc kiểm thử gRPC của bạn không bị cô lập.
Bạn muốn kiểm thử một dịch vụ gRPC mà không cần viết một flag nào? Hãy dùng thử Apidog miễn phí, nhập tệp .proto của bạn hoặc kết nối thông qua reflection, và thực hiện các cuộc gọi unary và streaming trong một GUI chỉ trong vài phút.