Open danielkurniadi opened 4 years ago
Hence, what do you think? If you say No to this feature, can you help me suggest what are the neat and efficient way to build a client-side Go application that can communicate with ServerTwo
but minimize coupling to ServerOne
gRPC schema as much as possible. Thanks!
Let's take a look at your slack example and say we have two server:
ServerOne
implementsAnnounce()
via gRPC interface (say to announce notif to slack)ServerTwo
needs a server to announce something to slack. It needs to callServerOne
Well then, I build
ServerOne
withlileio/lile
and get an autogenerated code in Go. Neat and pretty.How about
ServerTwo
? Hmmm its a bit tedious because:ServerOne
, developer need to read and understand the proto file ofServerOne
. Good thing ifServerOne
developers kindly have an API docs.ServerOne
proto file which change the comminication contract betweenServerOne
andServerTwo
. Then these changes also affect the dependent microservice (ServerTwo
)Ideas
There are two ideas for Go developer to resolve this:
ServerOne
do two version of API: the old schema and new schema. AllowingServerTwo
to slowly migrate.ServerOne
can give its protofile toServerTwo
and we can build a code generator for client side.I want to highlight on the (2) Ideas here and whether it should be supported, what are the Pros and Cons.
Pros
Cons
thrift
can yield freaking 50,000 lines of code just for 12 endpoints. This pollute the codebase, git commits, and slows down IDE and code intellisense (VSCode, Vim, GoLand, you name it).