🚀 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]

@LunaticoCR Apologies for the delay — this feature is a priority for us and is planned for release in the next 2 months. We’ll update this thread as soon as we begin rollout.

Until then, it would be great to understand what scripting APIs or workflows you’d like supported for gRPC, so we can ensure we design it around real use cases.

[LunaticoCR]

Pre request script to trigger other gRPC or HTTP requests that prep stuff and produce variables that will be used by the gRPC request.

[RangaHax]

Post requets scripts to modify the response content would be awsome! We use this to make protobuf responses more human readable:

{
  "lo": "6518802532994722954",
  "hi": "16901024951377249158"
}

is a Guid for example: 9c112c8a-705d-5a77-86c3-dad6a5808cea. Similar conversions for Decimal, DateTime, DateOnly etc.

[antoniovalentini]

Until then, it would be great to understand what scripting APIs or workflows you’d like supported for gRPC, so we can ensure we design it around real use cases.

Post response script to store eventual "credentials" or "tokens" to be used in subsequent gRPC requests. That is essentials in many workflows.

[sanish-bruno]

@antoniovalentini @markdstevens @LunaticoCR @RangaHax I have created a discussion on how gRPC scripting will look like also introducing the concept around event based scripting. would love to hear thoughts on those.

#6982

[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.

[vitalyk-sh]

@sanish-bruno I have used variables using following syntax {{VAR_NAME}} and GRPC bodies dont like that, same as comments made with //, resets to {}. And if I save the BRU file with {{}} variables, it still opens the whole payload as {}

[sanishchirayath1]

@alvinthen Thanks for reporting this, we will work on the fix!

[vitalyk-sh]

@sanishchirayath1 just a quick follow up, maybe it is legit that it resets it - though unclear about comments. however I now started using the vars as "{{some_var}}" <- basically wrap it in quotes as its a string value, that does not reset the body to {}. Not sure if this is helpful. THank you! :)

[sanish-bruno]

@vitalyk-sh That will work if the some_var is a string, but the variable can be a number or any other type too, so we will have to fix it! This is a valid issue! I guess we are running JSON.stringify on an invalid JSON object and it is causing this problem, we will work on a fix for this

[sanish-bruno]

PR to track #6216

[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

[schimmy]

yes - autocomplete would be amazing

[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]

Any news here @sanishchirayath1 ?
I have found since that the problem seems to be with folder variables.

[sanishchirayath1]

@LunaticoCR Oh okay, we fixed the issue were the gRPC message gets reset to {}, when there's a variable! I think, we missed this scenario. Thanks for reminding me! I will work on it promptly!

[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.

[sanish-bruno]

@LunaticoCR will you be able to look into this #6996? I attached a screen recording of the connect & send functionality. let us know your thoughts

[sanish-bruno]

Draft PR #6994