Mocking gRPC Servers

[aperezg]

Context

Killgrave was born like an easy way to create mocks servers to HTTP APIs, so the philosophy of Killgrave was to make mocking easy and accessible to as many people as possible.

But now not only we have the HTTP APIs, there a lot of project that using gRPC to create theirs communications, so will be very interesting that find a way to do the Killgrave the way to mocking a gRPC server.

Proposed implementation

We will need to differentiate between an HTTP or gRPC server is calling, also we want to maintain the way to do the thing easy, so we need to find a solution that was easy to understand to everyone, so if it possible we want to continue using json to configure the imposters for the gRPC server.

Also we need that the config.yml could work for HTTP or gRPC

If you have any propose, please let us know.

[monicagangwar]

@aperezg
To differentiate between HTTP and grpc we can have different ports for them
As for config and imposter for grpc, in config we can ask the user to provide proto path and in request response define json corresponding to the protos, we can use jsonpb to marshal the json into proto structure and move ahead
how does this sound ?

[joanlopez]

Hi @monicagangwar,

Thanks for your interest in contributing!! 🙏

IMHO, in order to be able to take a decision, I'd analyze the approach used by some of the already existing gRPC mocking solutions (see the list below as suggestions):

• https://github.com/cbrz/mountebank-grpc
• https://github.com/tokopedia/gripmock
• https://github.com/YoshiyukiKato/grpc-mock

Then, we'll be able to take a meaningful decision together.

Thanks!!!

[cunyat]

Hey there, I've been using killgrave for testing and it is awesome, but that gRPC support would be amazing.

I've been looking that examples that provided @joanlopez.
The one with go, is compiling the mock when the user indicates the proto file.
I really don't like these approach, but the alternative whould be listening raw incoming request and parse the incoming data into outcome?

Also, that would be a good approach: https://hub.docker.com/r/salrashid123/grpc_curl/
Build that server inside a docker, so at least, the final user doesn't need all build tools to setup that server and as long as they are developing a client, seems normal that could have docker installed. But also changes a lot the way that killgrave is working. Here I think that would be better a new project, and end up with killgrave and killgrave-grpc?

What do you think about?

[joanlopez]

As for config and imposter for grpc, in config we can ask the user to provide proto path and in request response define json corresponding to the protos, we can use jsonpb to marshal the json into proto structure and move ahead
how does this sound ?

I really don't like these approach, but the alternative whould be listening raw incoming request and parse the incoming data into outcome?

@monicagangwar @cunyat

Looking forward to work on your suggestions about parsing the raw requests.
However, it doesn't seem as easy as it'd be for an HTTP/1.X use case. Could you bring any code example?

Thanks!! 🙏🏻 😇

[cunyat]

I've been looking for setup a grpc server, listen requests and try to unmarshall them into an empty interface, but i couldn't get it work...
Maybe I should try to listen as http server? I'm trying to learn about that, but it's pretty confusing.
@joanlopez Do you have any idea how can i get this working?

[cunyat]

Hey there!
It's been a long time... But I kept the idea in mind and finally got time to investigate on.
I think I have a good approach to handle gRPC requests, I've uploaded a proof of concept:
https://github.com/cunyat/playing-with-grpc

The idea is to build the FileDescriptor of the given proto file, and dinamically register server and methods. This allows to know types about requests and responses and encode/decode them correctly.
Also I think this would fit well in the current structure of killgrave, as once we have decoded the incoming message we could convert it to json and send them as requests to imposters.

Also, I see that the project is a bit inactive. How do you see keep going with this?

[joanlopez]

Hey @cunyat,

Also, I see that the project is a bit inactive. How do you see keep going with this?

It has been a bit inactive, right. Unfortunately, mix of both work and personal duties forced us slow down the activity on this project. However, I'm glad to be able to say that: "we're back!". Since last few weeks we already started to work on a set of new features that I hope (at least a few) will be available by the end of the year.

I think I have a good approach to handle gRPC requests, I've uploaded a proof of concept:
https://github.com/cunyat/playing-with-grpc

At first glance, I'd say your PoC looks really well! Let me give it a try and I'll reach you back in few weeks.
I'm excited to, finally, be able to come back to work on this idea we had in the past. All credits, thaaanks!!!