
BloomRPC: GUI Client for GRPC Services - brunoluiz
https://github.com/uw-labs/bloomrpc
======
Matthias247
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.

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

------
fenos
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

~~~
hsaliak
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?

~~~
fenos
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

------
thesandlord
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](https://github.com/googleapis/googleapis)),
does anyone else?

~~~
stdplaceholder
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.

------
pboothroyd
looks very similar to a project I worked on last year:
[https://github.com/improbable-
eng/Dragoman/tree/e8a78c421335...](https://github.com/improbable-
eng/Dragoman/tree/e8a78c42133569220113d504340cb39445e65fcc)

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

~~~
fenos
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

~~~
quietbritishjim
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...](https://stackoverflow.com/questions/18735609/the-path-in-protobuf)

[2]
[https://github.com/protocolbuffers/protobuf/issues/723#issue...](https://github.com/protocolbuffers/protobuf/issues/723#issuecomment-132845240)

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

