🚀 Beta Release: gRPC Support in Bruno - Feedback wanted!

[sanish-bruno]

Hi everyone 👋

We’re excited to share that gRPC support is now available in Bruno (beta), starting from version 2.10.0 and above! 🎉
This is an early release, and we’d love your feedback to help us refine and improve the experience before it moves to stable.

👉 In this discussion, you can:

• Share your first impressions of gRPC support
• Report any issues, bugs, or unexpected behavior
• Suggest improvements or features that would make your gRPC workflows better
• Let us know how you’re currently using gRPC in your projects

Note

You need to navigate to Preferences > Beta and enable the gRPC checkbox to activate.

📹 We’ve also added a short screen recording below to walk you through the current functionality.

Screen.Recording.2025-08-29.at.1.20.32.PM.mov

🔗 Helpful links:

• Download Bruno
• gRPC Documentation

⚠️ Since this is a beta feature, you may run into limitations or rough edges — your feedback will directly shape how we improve it.

Looking forward to hearing your thoughts and ideas! 💬

Thanks for helping us make Bruno better,
The Bruno Team ❤️

[dominickp]

Is gRPC support expected to remain as a free feature when its out of beta? It being available for free users along with custom scripting would be a differentiator from Kreya.

[Its-treason]

Yes, it will stay free for everyone

[helloanoop]

Yes, it’s a part of out OSS codebase and will be a part of our free tier

Scripting across all requests (grpc, http, graphed) is also a part of our free tier

[markdstevens]

First off, huge thank you to the team for making this happen. I've gotten the chance to play a little with the gRPC features in beta, and it works very well, so great job!

One thing that isn't working for me though is the scripting. I added a simple console.log into the pre-request and post-response sections of my collection, and those scripts were not executed (the logs did not appear in the dev tools) when I fired the gRPC request from within the collection. I verified that the same pre-request and post-response scripts work fine when I execute a REST request from the same collection, so something appears to not be working specifically when firing a gRPC request.

[sanishchirayath1]

Hey @markdstevens , Thanks for joining the discussion. scripting is not yet supported with gRPC. We are planning add features iteratively. We still have to decide how the scripting APIs behave when it comes to gRPC.

Also, we were thinking of adding 3 scripts, pre request, post response, on message. Will you be able to share some insights on how do you use gRPC and scripting together?

What are your thoughts on 'on message, script?

Is it useful?

Do you have any specific scripting APIs in mind, that is useful when it comes to gRPC, (new or existing)?

[markdstevens]

@sanishchirayath1 The one use case I have at the moment is to use a pre-request script to fetch a fresh auth token (since they expire frequently) and then attach that as metadata on the outgoing gRPC request.

[sanishchirayath1]

@markdstevens scripting is something we will be supporting,we will be priotizing it within gPRC when it comes to features.

[LunaticoCR]

Also looking forward to scripting working with gRPC requests. I noticed there's no scripting fields in the gRPC requests themselves, but also, any top level folder scripts are also not triggered.
I have a use case where one of the requests needs to create a new random variable and store it so that all other requests in that folder can use it and as of now I haven't been able to find a way to do this.

[sanishchirayath1]

We will be working on scripting soon. It is on priority, and we are hoping to get the feature out by November @LunaticoCR

[darengrant]

Hi,

Great to see gRPC coming to Bruno, I've been watching and waiting patiently.

I've only had a chance to have a quick play so far and reflection is working nicely for me. However proto support is limited and has some issues.

1. Proto Selection is done one proto file at a time. For a collection of services this is painful:

   • would be great to point to the root proto/ directory and pull in all relative proto files.
   • and /or support proto descriptor sets would make it simple to pull in a whole suite of services.

2. Selecting a proto file in its relative location to a proto root fails to navigate correctly to be able to find imports. i.e. If I select servicex.proto in the structure below I get an error which in the developer console shows that annotations.proto is trying to be loaded below mycompany/myservice/. Handling relative proto files appears broken. Or I am doing something I should not be doing which is quite common ;-)

A folder structure
protos/
mycompany/myservice/servicex.proto
google/api/annotations.proto

Where servicex.proto has

package mycompany.myservice;

import "google/api/annotations.proto";

[sanishchirayath1]

Thanks a lot for joining the discussion. It is designed in such a way that, you'll only have to select the root proto file / the protofile where the services are defined. It should be able to resolve the relative paths within it.

I don't know what happening within this particular case, In my testing relative paths was working fine for me.

• How are you defining relative paths?
• Is there any alternative way of defining relative paths?
• Currently we have designed expecting that the user will only select the root proto file, Do you see any scenario where services are distributed among multiple files and this approach becoming a problem?
• Also do you have any example Api clients that does this really well, were we can access a suite of services. I guess the pain point is, you have services defined in multiple files within the folder and you are unable to see all the services, you are only able to see the services that are defined in the selected file.

[darengrant]

I think the easiest way to answer your questions is pointing to an existing public repo hosting protocol files.

The google common apis @ https://github.com/googleapis/api-common-protos

Using a checkout of this repo , and trying to browse and use the proto from google/iam/admin/v1/iam.proto results in an error in Bruno

index.d59564fb.js:16 Error loading gRPC methods: ENOENT: no such file or directory, open '/Users/xxxxxx/bruno-test/t1/api-common-protos/google/iam/admin/v1/google/api/annotations.proto'

With regard to the query re scenario where services are distributed among multiple files. I'd point to the google cloud APIs as an example https://github.com/googleapis/googleapis . Each service being specified in its own proto file or files where several services are used to build a test workflow..

I've only used the insomnia client for gRPC which has support for whole directory structures of proto files and handles relative paths well.

[sanish-bruno]

@darengrant Hey we have introduced 'import paths' for grpc, will it be helpful in your case? you can specify concerned import paths, it should be able to resolve the path within protos. #5520 , This will be part of 2.13.0, which will be released within next 2 weeks. If you want to try the feature out early you can try it out from bruno-nightly-builds (we are still in the process of testing the build, things may not work as expected). It will be helpful to know, if import paths can resolve your issue.

[darengrant]

Hi Sanish, I've just had a chance to pick up the latest version and the import paths works really well for my use case, thank you for the new feature. gRPC support is really shaping up, looking forward to scripting landing.

[alvinthen]

It'll be great if we can support v1 reflection, currently it's hardcoded to get reflection from v1alpha

In Spring gRPC, the reflection API is at grpc.reflection.v1.ServerReflection/ServerReflectionInfo, enabled by grpc-java

I believe the cause is because grpc-reflection-js is outdated

[sanish-bruno]

@alvinthen will look into it, thanks for reporting this!

[sanish-bruno]

@alvinthen here's the #5650 to track

[KeHaC24]

I've been waiting for this moment for a long time! Excited to see it being implemented!

I have only been playing around with it for a short time but I think I may have found a bug.
When saving a grpc body/message, it clears itself back to an empty json {} if the message itself is not a valid json.

If you need more information, please let me know.

[sanish-bruno]

@KeHaC24 Thanks for reporting it! I am aware of this issue. Do you have any use case where you may have to use something other than json within the body? So far i believe this is not blocking you from using the app, you can use ctrl/cmd + z to get back to the previous state and start making the edit! I will work on a fix where, save will throw a toast if the body is not valid instead of replacing it with empty object {}

[KeHaC24]

it's not really a use case issue, but more of a small annoyance when creating or changing the request and being just a bit too quick with pressing ctrl+s
i found out pressing ctrl+z brings it back, too, which is fine for now in my opinion

btw am i correct in assuming that the grpc response not coloring the json keys in a different color (in the grpc response) is also a known cosmetical flaw?
they are being colored in orange, the same color as json strings.

[cvigo]

gRPC support is great!!! Thanks for that.

I am having issues with messages including map types:

message ExecuteSqlRequest {
  ...
  map<string, Type> param_types = 5;
  ...
}

message Type {
  TypeCode code = 1;
  Type array_element_type = 2;
  StructType struct_type = 3;
}

enum TypeCode {
  TYPE_CODE_UNSPECIFIED = 0;
  BOOL = 1;
  INT64 = 2;
  ...
}

The JSON I used in Postman does not work, I get Request message serialization failure: .ExecuteSqlRequest.param_types: array expected

  "param_types": {
    "1": {
      "code": "BOOL"
    }
  },

I tried exporting to grpcurl and get a different error: Error invoking method "ExecuteSql": error getting request data: message type ExecuteSqlRequest.ParamTypesEntry has no known field named 1

The fix does not work either, I get Empty or null parameter name in 'paramTypes'

  "param_types": [
    {
      "1": {
        "code": "BOOL"
      }
    }
  ],

this one converted to grpcurl also produces a different error: Code: InvalidArgument, Message: Param 'fields' not found in 'paramTypes'

So I am not sure if map is not supported yet or if I am messing all up.

Help is appreciated!!

[hugosius]

yesterday i noticed that gRPC is supported. great! a few things i noticed when giving it a shot.

• in our development process we rely on reflection. some of our services have a lot of methods (150 and more). in postman we are able to select the desired method using text input which seems to support some sort of autocomplete. this makes it easy to select the desired method. i have not yet found a way to do that in bruno.
• we also rely on generating example messages heavily. while the existing feature works, i miss a few things:
  • nested properties do not seem to get generated
  • when deleting a property from the generated method it would be good to be able re-add the property with an autocomplete functionality
  • enumerations: autocompletion and also showing the actual enumeration value would be good

[k4l397]

Adding protoset support would be useful and make Bruno much more flexible. I often struggle to get tools to work with our proto files directly (not sure why exactly, I assume difficulties resolving imports?) but find that tools work much more smoothly when I can feed them a protoset (which I can make easily with our toolchain). Mostly use grpcurl currently and the workflow looks like this:

buf build -o service.protoset

grpcurl -protoset service.protoset ...

I think it works more reliably because by that point all imports are resolved and are in a binary format.

Excited to see gRPC support in Bruno!

[sanish-bruno]

Agree on this. This will definitely help testing gRPC more reliably. we already have this in mind and is one of the major feature we want to develop for gRPC, we can't ensure a timeline as of now.

[LunaticoCR]

I'm so glad this is now available! I analyzed this a few months ago and because gRPC wasn't available we couldn't use it in our team, but it's great that it's there now.
I've been playing with it today and it's working really really well, but I think I found a bug with bi-directional streaming requests. We use a lot of variables in our requests and it seems that variables are not injected in bidirectional requests. On the server, I see that the actual variable name string, is what got sent instead of the value. Is this a known bug?

[sanishchirayath1]

@LunaticoCR It is not a known bug, can you add more details on it, we will try to resolve it promptly

[LunaticoCR]

Thank you for your reply @sanishchirayath1 !
It's not hard to reproduce to be honest. Just create a gRPC request and in the message json use a few variables here and there. If you debug the request in the server side, you will see the names of the variables ({{var1}}) instead of the value of the variable. So it's like they're not getting parsed at all or something.
It worth noting that variables in the url field and in the metadata table do work fine. So the issue is just with consuming variables inside the request message.

[sanishchirayath1]

@LunaticoCR Thanks, we will look into it!

[LunaticoCR]

As I use this more I really like how I can add several client messages ready to be used. This really allows me to create a full request that mimics how a real client-server interaction would look like.
I would like to propose an idea that would make this even better, the ability to send all messages with a single click. And I mean a single click for everything: establish channel, do onNext for as many messages there are in order, and then do an onCompleted. And what would make this even better would be the ability to configure delays between messages, individually configurable. So for example between message 1 and 2 I could add a delay of 50ms, while between message 3 and 4 it could be 200ms.

[sanishchirayath1]

@LunaticoCR This is already being planned, we will eventually have connect & send functionality, especially for client streaming methods. Configurability part is not yet planned, definitely something that we can think of.