Consider using descriptor set instead of Go compilation for mock/stub creation

[holgerstolzenberg]

This is just meant to give some feedback and file a possible enhancement to the project.

I lastly had to build a gRPC client connection for a Java backend. On getting through this, I was in need of a local gRPC (mock) server in order to not bloat the local dev env and I stumbled upon your nice little project and Wiremock gRPC extension. I skipped Wiremock in the beginning, as gRPC extension is somewhat in a preview/beta state.

Setting it up bavix/gripmock via docker compose worked like a charm - for a hello world style project :-), but I really struggled to get it set up for my "real world" use case.

So here is the problem. The schema where I have to do the protoc compilation for is large and uses a lot of subdirectories, importing types from proto files here and there. This schema I was not able to get to compile properly in order to be used by Gripmock. This is mostly due to the setup of the Go compilation.

• our project is not targeted towards Go and therefore the schema artifact does not have the necessary go_package option
• adding it did not fully solve the problem, it just caused other problems regarding Go (module) compilation, which is very hard to understand when coming from the Java world
• I checked out Gripmock by myself and added some log statements, rebuild the image locally in order to understand what is actually going on
• the final protoc command that was constructed by Gripmock was not sufficient in order to compile the schema

I initially thought I can provide a PR to Gripmock but due to time issues I switched to Wiremock with gRPC extension - and it works. It is not as streamlined in terms of the stub syntax, as the Wiremock syntax for HTTP mocking is re-used, but everything else works quite well.

1

So here is the point/idea. There is a major difference in how the mocking is achieved. In order to use Wiremock, you have to provide descriptor set files only to Wiremock. You have no need to compile your schema towards a certain language. This could also be very beneficial for Gripmock, as it would not force the end user to be proficient with Go language. The descriptor set files do not need special compilation options (as far as I am aware of)...

The following snippet shows the configuration I used for the Gradle protobuf plugin in order to compile the schema to java for my project and creating the descriptor sets needed by Wiremock:

protobuf {
  protoc {
    artifact = "com.google.protobuf:protoc:${protocVersion}"
  }
  plugins {
    grpc {
      artifact = "io.grpc:protoc-gen-grpc-java:${grpcVersion}"
    }
  }
  generateProtoTasks {
    all().configureEach { task ->
      task.generateDescriptorSet = true
      task.descriptorSetOptions.path = "${projectDir}/build/generated/protoc-dsc/mds_schema.dsc"
      task.descriptorSetOptions.includeImports = true

      task.plugins {
        grpc {
          // this setting will most likely change in the future towards '@generated=omit'
          option 'jakarta_omit'
        }
      }
    }
  }
}

This also takes the need from the server to re-compile on each startup.

2

Another small enhancement to Gripmock could be just to properly log the full protoc command the server generates in order to get an better idea how the compilation is handled.

So these are just ideas/random thoughts - hope that might help you guys on your journey...

✌️

[holgerstolzenberg]

And of course there is one thing I forgot to write down 🙈. I also had to updated the protoc version bundled with the image in order to get the compilation to work at all.

The following Commit showcases, what I was playing around with. This is just dirty code, nothing to be taken serious:

https://github.com/bavix/gripmock/compare/master...holgerstolzenberg:gripmock:feature/enhance-go-compilation

[rez1dent3]

217 #222