-
Notifications
You must be signed in to change notification settings - Fork 86
Open
Description
Let's take a look at your slack example and say we have two server:
ServerOneimplementsAnnounce()via gRPC interface (say to announce notif to slack)ServerTwoneeds a server to announce something to slack. It needs to callServerOne
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:
- To commnicate with
ServerOne, developer need to read and understand the proto file ofServerOne. Good thing ifServerOnedevelopers kindly have an API docs. - Then come changes in
ServerOneproto file which change the comminication contract betweenServerOneandServerTwo. Then these changes also affect the dependent microservice (ServerTwo)
Ideas
There are two ideas for Go developer to resolve this:
- Versioning of API:
ServerOnedo two version of API: the old schema and new schema. AllowingServerTwoto slowly migrate. - Autogenerated Client-side:
ServerOnecan give its protofile toServerTwoand 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
thriftcan 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).
Metadata
Metadata
Assignees
Labels
No labels