Proposal: Update truss to allow for sharing of protobuf definitions

[eriktate]

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.

[zaquestion]

@eriktate Hey I saw you've got some stuff going for this on your fork, have you had any success getting it working?

[kainoaseto]

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!