Design for HTTP/gRPC Server

[ccrvlh]

Currently Flintlock's HTTP server is being autogenerated from the protobuf files. The autogenerated HTTP server uses Gorilla Mux, which has just been archived (see here). It seems the project is stable enough, so it shouldn't break anything for now, but it makes sense to look at alternatives.

Discussing the use of Mux also brings the discussion regarding how to approach the HTTP server (and the gRPC server). As mentioned, this is currently being autogenerated, so it's worth looking if we want to keep this autogenerated, or to have two different interfaces (one for each server: HTTP and gRPC), using the same services underneath.

Autogenerated:

• Pros:
  -- Two implementations for one single piece of code - only the protos would need to maintained, and the HTTP would be free
  -- Consistency: easier/simpler to have exactly the same interface regardless whether it's gRPC or REST
• Cons:
  -- Lack of flexibility with HTTP: we are tied to whatever code is being generated, not trivial to customize (i guess?)
  -- Potentially tied to out of date libraries/dependencies (as it's the case with mux), may be fixed by upstream

Ideally, whichever entry point being used (gRPC, REST, CLI) shouldn't matter much, and they all should be using the same services underneath, but it seems that having some flexibility to be able to adapt/customize the interface so it's inline with best practices of each implementation. I'm not particularly familiar with the gRPC and the autogenerated server, so I can't say much about it. Also not sure if the autogenerated code is easy to customize (or even if it should be customized).