Mocking gRPC Servers
aperezg opened this issue · comments
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.
@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 ?
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!!!
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?
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?
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!! 🙏🏻 😇
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?
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?
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!!!