PluginRPC
PluginRPC is an Protobuf RPC framework for plugins. It enables writing plugins defined by Protobufservices while only relying on CLI primitives such as args, stdin, and stdout. PluginRPC has noreliance on network calls. Individual RPCs are invoked via arguments passed to the CLI plugin,requests are sent on stdin, and responses are sent on stdout. It's everything you need to useProtobuf services to represent your plugin API without any of the cruft.
PluginRPC has the following goals:
- Make it possible to evolve both the PluginRPC protocol and the APIs for individual plugins inbackward-compatible ways over time.
- Make it possible to invoke multiple methods as part of a plugin. Many plugin frameworks onlyprovide for a single entrypoint. In contrast, PluginRPC provides the full power of Protobufservices: multiple services, and multiple RPCs per service, can be exposed.
- Expose the plugin interface in CLI-idiomatic ways. PluginRPC exposes individual RPCs assub-commands with flags for control, optionally allowing the specific sub-commands to becustomizable. PluginRPC attempts to consume and produce requests and responses in a manner thatwill be readable by humans invoking the sub-commands.
- Make it easy to call plugins even in the absence of an official language-specific library.
PluginRPC currently has one official language library:
Go is a natural language to write plugins in, and we have a direct use case for an RPC libraryin Go for our custom lint and breaking change plugins inbuf.However, PluginRPC is purposefully designed to be simple to implement in any language. If there issufficient demand, we may provide official implementations for other languages in the future.
If using Protobuf to write plugins, there's traditionally been two mechanisms:
- Have a single request message type sent over stdin, and return a single response message typeover stdout. This is how
protocoperates, for example, taking in aCodeGeneratorRequestand sending back aCodeGeneratorRequestover stdout. This is very simple, however it makes doing anything elseextremely difficult. All plugin API evolution needs to remain within these single messages forall time, and providing functionality for multiple methods is awkward at best (for example, viause ofoneofs). Multiple content types cannot be supported. - Bring a full-powered network RPC framework into the mix. This is howgo-plugin operates, for example, making a plugin exposea gRPC service, and then doing an exec/kill dance to bring the plugin up temporarily and exposeit on a port, call the required method, and then kill the plugin entirely. While effective inallowing lots of flexibility, it's bringing in a very complicated framework to solve a simpleengineering problem, adding brittleness, requiring network calls, and not allowing plugins toremain idiomatic CLI tools
PluginRPC provides the best of both worlds: simple CLI constructs with all the power you require. Ifyou want to use Protobuf services across the network, useConnectRPC. Ifyou want to use Protobuf services to write plugins, use PluginRPC.
Popular repositoriesLoading
- pluginrpc-go
pluginrpc-go PublicThe Go library for PluginRPC: A Protobuf RPC framework for plugins.
- .github
.github Public