5 ms·

BloomRPC: GUI Client for GRPC Services

105 points by brunoluiz 8y ago

algorithmsRcool 8y ago
Finally! I've been wanting a tool like this to help get my gRPC development flow to parity with REST
thesandlord 8y ago
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 8y ago
  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 8y ago
looks very similar to a project I worked on last year: https://github.com/improbable-eng/Dragoman/tree/e8a78c42133569220113d504340cb39445e65fcc https://github.com/improbable-eng/Dragoman/tree/e8a78c421335...
Matthias247 8y ago
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 8y ago
  Wow! Those two features will be certainly a good addition to the client! I’ll be adding them to the list
fenos 8y ago
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 8y ago
  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 8y ago
    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
quietbritishjim 8y ago
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 8y ago
  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 8y ago
    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-protobuf https://stackoverflow.com/questions/18735609/the-path-in-pro... [2] https://github.com/protocolbuffers/protobuf/issues/723#issuecomment-132845240 https://github.com/protocolbuffers/protobuf/issues/723#issue...

105 points by brunoluiz 8y ago

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

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 8y ago
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 8y ago

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

Matthias247 8y ago

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 8y ago
Wow! Those two features will be certainly a good addition to the client! I’ll be adding them to the list

fenos 8y ago

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 8y ago
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 8y ago
  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

quietbritishjim 8y ago

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 8y ago
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 8y ago
  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-protobuf https://stackoverflow.com/questions/18735609/the-path-in-pro... [2] https://github.com/protocolbuffers/protobuf/issues/723#issuecomment-132845240 https://github.com/protocolbuffers/protobuf/issues/723#issue...