EPIC: Evaluate Jetty as replacement for Netty

[pete-petey]

No description provided.

[niloc132]

This issue is to track the idea of running Deephaven Core and its associated browser-based UI without requiring docker or a local envoy install. As netty in grpc-netty is hard to extend (to offer a built-in grpc-web proxy, a ssl-less websocket proxy, or a server for static html/js content), we're exploring an old branch to the grpc-java project which added support for the jetty webserver.

Whereas netty is being used an internal implementation to grpc-netty, the grpc-jetty project assumed that the grpc wiring could coexist in a standard jetty server, along-side other filters and servlets. This would allow us to

• serve static content, such as the js api and the web UI
• build or include a servlet filter, which is capable of rewriting grpc streams to grpc-web
• build or include a servlet filter that can redirect websocket requests to grpc-web-enabled endpoints, in the same way as https://github.com/improbable-eng/grpc-web/ does in an external process

Each of these three removes the need for a single external process that we presently require - four distinct docker images are offered, along with a sample docker-compose.yml to show roughly how to wire them up, but they could as easily be run as local processes. Consolidating to a single process would still easily allow running from within docker, or behind an envoy proxy, but these would no longer be required, and setup/scaling could be simpler in some cases. Running natively on mac/windows or without the indirection of docker on linux would be possible too, making for easier debugging and integration with any other local resources.

Risks involved include any work needed to update the grpc-jetty project to latest grpc, and losing our hermetically-created python environment (we might want to produce jpy-dh wheels for other platforms and python versions).

Basic projected milestones of this epic:

• "wake up" the async servlet branch of grpc-java, currently up to about 1.32.0 (latest is 1.40.1, we presently use 1.38.0). We should also either see about getting this accepted upstream, or using our own fork of io.grpc (there are some changes to the core project that we would need to get away from netty).
• Implement a grpc-web frontend, either reimplementing how grpc is provided as a servlet (likely more efficient, but more code to copy/write), or putting a filter on the existing grpc servlet and translating on the fly (likely easier to implement, but might end up copying data more than necessary). Taking the proxy approach, we have a few reference implementations we can follow, in addition to the spec.
• As above, implement a websocket frontend that either reimplements how grpc is provided as a servlet, or serves as a proxy for grpc-web or grpc web. This might come in two stages, first 1:1 websocket to stream, as https://github.com/improbable-eng/grpc-web/ does, and potentially later finding a way to reduce the number of websockets that need to be held open at a time for a client. In addition to the base implementation as a reference, we can also use the client transport differences
• Select a strategy to make it easy for end users to select netty vs jetty, with or without docker, etc - we likely don't want to double the number of ways that are currently supported to start a server. This checkbox probably also includes shipping the static web resources.