I have mostly used REST or grpc separately in services. When I needed both, used go-kit. But in my new project, OpenAPIv3 is a high want on the REST side and grpc is also needed.
I have two options:
- use grpc-gateway: this way, I can generate the OpenAPIv2 spec through grpc protobuf annotations. Not sure how it will handle more complex OpenAPI requests like handling mixed mode requests (multipart-form-data + JSON metadata at the same time in a request). Also, OpenAPIv2 will have to be converted to OpenAPIv3 as well.
- maintain separate API secifications.. one for REST and another for Grpc. And then an inermediate HTTP layer connects OpenAPI generated server to the underlying service layer methods. Similarly, an intermediate GRPC layer connects GRPC generated server to the underlying service layer methods. This is similar to the go-kit approach. The up-side is that full support of OpenAPIv3 toolchain on the REST side. Downside is that having to manually maintain 2 separate APIs specifications (grpc protobuf and OpenAPIv3 yaml).
I can go with 2, but want to know if this is an anti-pattern and industry wide, grpc-gateway is used in this scenario?