Looks cool. I did something similar 2 years ago in a job, and found it super helpful. My favorite feature was that I added an autocompletion/intellisense engine to the editor window in the browser, and then could start creating requests by just ctrl+space-ing. This worked by parsing all input in a failure tolerant fashion, determining at which field the cursor is, and loading possible matches from the interface definition.

It's pretty cool to interact with an unknown server API in the same fashion than with an unknown library in an IDE.

What I also added was the ability to export requests that one created in the GUI (e.g. as a cURL command including parameters). That made it pretty ease to create requests in the GUI, and then persist and reuse them in other ways.

Wow! Those two features will be certainly a good addition to the client! I’ll be adding them to the list

Hi! Creator of BloomRPC here. Thanks for the warming welcoming of the client! I’m glad to see lots of positive feedbacks.

The client aim to give the best developer experience possible on your day to day usage of GRPC services.

We are using it heavily internally and improving it everyday

I hope you’ll enjoy working with bloomrpc and that will be soon your GRPC companions

PM for gRPC here - this looks great! Thank you for creating it. I'll definitely be pointing folks to it. I saw that there is support for reflection and TLS planned already.

Are there plans to support record/replay of a sequence?

Thanks, I’m glad you like it!

Yes, TLS will arrive very soon. Reflection too but it will take slightly longer.

Request chain will follow along!

I haven’t thought about recording and replay.

That is a great addition to the editor once we support request chain

This is really sweet! Definitely fixes one of the missing usability features compared to JSON/REST APIs.

Are there any examples of public gRPC APIs that provide their .proto files? I know Google does (https://github.com/googleapis/googleapis), does anyone else?

GRPC offers server reflection so your tools can interrogate the protocol at runtime, so your tool doesn’t need to compile in all the protocol descriptions.

looks very similar to a project I worked on last year: https://github.com/improbable-eng/Dragoman/tree/e8a78c421335...

Great job. I ran this on Windows by building from source, it seemed to work for me. I just had to change a couple of things:

* Activate Python 2 virtual environment (it didn't work with Python 3!)

* Change forward slashes to back slashes in `./node_modules/.bin/electron-rebuild` (I also ran it as a separate command to `yarn install`, not sure whether `&&` would have worked).

* Run `npm start hot-server` (rather than `npm start server-hot` in the instructions).

* Close the Chrome dev tools, which appeared by default.

I must admit I didn't try actually sending a request. Our services are often split into multiple protos with a full relative import (like: import "companyname/project/foo.proto") so you'd need to set the include path for them to work.

Fantastic! I've never had a chance on launching the app on windows, I'm glad it worked!

I think you are running the dev mode, that's why the Chrome dev tools appeared :)

The import paths feature will be released soon so stay tuned! In the meantime, you can temporarily place the imported protos close to the one you want to use

Ty

Sorry I didn't call this out more clearly, but I think the server-hot vs hot-server thing is a typo in the readme that's wrong on any platform.

Looking forward to include path support. I tried flattening my protos into one directory, updated all their `import` directives and gave it a go, and it works great, thanks! Both client and server running on Windows. My protos use a well known type (google.protobuf.Duration) and I was particularly impressed that it worked without me having to copy in the proto file for that.

I'm sure you already know this, but just in case: Include paths don't just help with proto files scattered across different directories, they also allow part of the path to be part of the canonical name of the proto. [1, 2] For example, if you have these files:

    /
        src/
            xyz/
                foo.proto   # Contains: import "xyz/bar.proto"
                bar.proto

Then you need -I/src (or similar) because if you run protoc from within /src/xyz/ without -I then it's like you specified -I/src/xyz, and then foo.proto can't find bar.proto (because it looks for /src/xyz/xyz/bar.proto). Using relative paths like this is useful because you can have proto files with the same file name (like "config.proto") so long as their full canonical name is different, and because generated files are output into corresponding subdirectories (which is especially useful in Python where the subdirectory indicates the package name).

[1] https://stackoverflow.com/questions/18735609/the-path-in-pro...

[2] https://github.com/protocolbuffers/protobuf/issues/723#issue...

Finally! I've been wanting a tool like this to help get my gRPC development flow to parity with REST