truss
truss copied to clipboard
Proposal: Update truss to allow for sharing of protobuf definitions
Suppose you have a .proto
file that contains an import
sourcing another service definition:
Dependent service definition
syntax = "proto3";
package thread;
// Importing protobuf from some 'post' service.
import "github.com/eriktate/truss-test/post/post.proto";
import "github.com/eriktate/truss-test/shared/shared.proto";
service Threader {
rpc Publish(post.Post) returns (shared.SuccessResponse) {}
}
Standalone service definition
syntax = "proto3";
package post;
import "github.com/eriktate/truss-test/shared/shared.proto";
service Poster {
rpc CreatePost(Post) returns (PostID) {}
rpc UpdatePost(Post) returns (shared.SuccessResponse) {}
}
message Post {
string id = 1;
string title = 2;
string content = 3;
}
message PostID {
string id = 1;
}
Shared messages
syntax = "proto3";
package shared;
message SuccessResponse {
bool success = 1;
string err = 2;
}
The truss generated gokit service should have imports utilizing the .pb.go
files referenced in
the .proto
imports.
Primary Use Case
The ability to proxy messages through one service to another. In the definitions supplied above,
the Threader
service needs to accept a Post
message from the post.proto
definition which it will ultimately use in some call to the Poster
service itself (perhaps to UpdatePost
).
You could replicate the messages across service definitions, but that creates more problems than it solves. Most notable of which is, simply, future maintenance (e.g. updating a message requires updating every copy of it in related services). Type mismatches are also a fairly significant problem as mapping functions between copies of message structs will be required to work with other service clients.
Considerations
- What if the
.pb.go
files are actually generated in a directory away from the.proto
file? - Is the expected workflow acceptable? E.g. making sure you keep depended-on services up to date and built locally.
- You could simply put shared messages in a shared folder/repo and reference those from all services that need them. This seems like it might not be a great developer experience though.
@eriktate Hey I saw you've got some stuff going for this on your fork, have you had any success getting it working?
Would be interested in helping to make this a reality at some point also, let me know if there's anything I can do to assist or if there is a clear path forward on implementation!