Creating and using gRPC services is pretty easy. However, there are a few gotchas and best practices that should be known to all. For example, do you know the default message size limit? Or do you know that protobuf supports optional fields since v3.15? Or that enum names should be unique inside a protobuf package?

If you don't know the answers to these questions, then this blog post is exactly for you.

Kreya 1.7 introduces generating fake data, referencing authentication configurations, adds a new light theme and other useful changes.

How many users use Kreya? How many requests are sent each day? Why do we collect this information? These and more questions we want to answer in the following blogpost and give you a detailed insight in our telemetry data.

In our blog, we'll try to give you insights into decisions and considerations that went into Kreya. We'll start by showing you how we started building Kreya over a year ago. Back then, the only gRPC GUI client was BloomRPC. It worked well, but we missed some crucial features like environments or global authentications, which made it a bit cumbersome to use. Both Postman and Insomnia, which we used for REST APIs, did not support gRPC (Insomnia has since added basic gRPC support). We decided that we should build a gRPC GUI client similar to Postman or Insomnia, which supports advanced features to make calling and testing gRPC APIs easier.