Should I drop gRPC?

[fsmv]

I could switch the RPC API entirely to JSON over HTTPS, which is more fitting probably for a web server, and that would allow me to drop a huge dependency. I wouldn't like to be stuck with it forever after 1.0.

I would have to figure out a way to nicely do the API in-band with the same port used for web connections but I think something should be possible, at worst I would have to reserve a url path which could be configurable. I could also keep it a feature to optionally run the HTTPS RPC server on a different port so you can firewall it separately, but by default only open the HTTP and HTTPS ports (in the future I can even drop the required HTTP port and let it be HTTPS only if desired).

I would probably at least at first keep protos internally and use the proto to json library because I still like the textproto config file in spawn, although I suppose I could implement json5 parsing and do that instead. I'm thinking of also hiding all the generated protos from the public API so I'm free to change the field names. Although I would still need RegisterRequest and Lease structs.

I would sort of like to have "no dependencies" and get rid of the proto library dependency as well but I really like a lot of things about protos. Not writing my own type checking code, having clear backwards compatibility rules, and a clean text format, an efficient binary format, and a reusable schema file are all really nice to have. At the same time there's the march of time affecting all dependencies. There's a newer opaque go proto API that I'm not using for example and I can't switch to it without breaking go API compatibility. Also it wouldn't really be no dependencies anyway because there's the go compiler and standard library and the golang.org/x/ libraries as well that are all unavoidable.

For getting rid of gRPC there would be a transition period where I support both gRPC and the HTTPS RPCs, then in the next "major" pre-1.0 version I would remove gRPC.

[fsmv]

The reason I originally switched to gRPC from the go standard library gob and rpc packages was I found that it was really hard to upgrade safely.

With protos and gRPC you can have binaries compiled with different versions talk together successfully because of the way backwards compatibility works. If the server is new and the client is old the client will only ask for old features the server can still do, if the client is new and the server is old the server will just ignore new fields. I think we can get most of this with json if we still use protos internally (or replicate the logic in a custom way eventually).

gRPC also has some nice benefits like a client that operates on a pool of connections so retries are built-in and automatic. Also having out-of-band error codes is really nice. It also has support for tracing with context attachments that I could probably extend into the go context (but I don't use it so far). I also like having a well defined service definition file that I can give to people to use in other languages.

gRPC also has a ton of code I'm not using. It feels like a very big hammer when I don't really need most of it. Registering for a reverse proxy server isn't exactly a high QPS service that needs maximum performance and load balancing.

[fsmv]

For what it's worth, I would be able to check ports are in the uint16 range if I did it with json custom. Protos only have uint32.