Let's take a look at your slack example and say we have two server:

1. ServerOne implements Announce() via gRPC interface (say to announce notif to slack)
2. ServerTwo needs a server to announce something to slack. It needs to call ServerOne

Well then, I build ServerOne with lileio/lile and get an autogenerated code in Go. Neat and pretty.

How about ServerTwo? Hmmm its a bit tedious because:

1. To commnicate with ServerOne, developer need to read and understand the proto file of ServerOne. Good thing if ServerOne developers kindly have an API docs.
2. Then come changes in ServerOne proto file which change the comminication contract between ServerOne and ServerTwo. Then these changes also affect the dependent microservice (ServerTwo)

Ideas

There are two ideas for Go developer to resolve this:

1. Versioning of API: ServerOne do two version of API: the old schema and new schema. Allowing ServerTwo to slowly migrate.
2. Autogenerated Client-side: ServerOne can give its protofile to ServerTwo 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

• Easy migration for dependent services. Using protofile as single source of truth

Cons

• Generated code in Golang doesn't always adhere to how Go code is written. Some developers think its OK because its an autogenerated code. Hence, if we want this feature we have to make it autgenerated but clean
• Same problem as above, but this time autogenerated code like that of 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).