gRPC?

[sleipnir]

Hi, this is an excellent project as well as ThousandIsland, thanks for investing time in this.

I would like to know your opinion on how complex it would be to implement the gRPC protocol on top of this library. Do you think this would be viable? Do you have plans for this? What hooks would you need to implement to achieve this?

[sleipnir]

From what I understand from the code the HTTP2 support is very much linked to the Plug, but a good part of the code could be reused to implement any kind of protocol Handler, the main parts that I saw that should be changed would be here and in the Adapter code, and probably some minor changes in some other places that should be specific to the desired protocol (in this case gRPC). Am I right in my analysis?

I intend to implement gRPC in this project https://github.com/eigr/falco that today uses Cowboy in its implementation. See issue here

[mtrudel]

To the extent that gRPC could be landed via the Plug interface, bandit is agnostic to whatever you're running. However, I don't think that gRPC is really supportable via the Plug API, so that's a bit of a glib answer.

The intent of Bandit is very narrowly premised on Plug (and eventually WebSocket) support, so if it's not possible to do via Plug I'm not really open to entertaining additions beyond that within the library. That being said, if Plug evolves to make things like gRPC support possible, Bandit will obviously follow.

I would suggest:

1. Investigating the feasibility of implementing a gRPC endpoint via the Plug API (Bandit & Cowboy would both support this today, so long as it's possible through the API).
2. If support isn't possible with Plug at the moment (I'm not well versed in gRPC subtlety to know for sure), propose workups against the Plug API to add whatever is missing to its API.

What do you think?

[sleipnir]

Hi @mtrudel thanks for answer!

The problem with the plug's API is that it is made to handle request reply and gRPC has many modes besides request reply, namely stream in, stream out, bidirectional stream, and unary (request reply). And I think you would run into the same Plug API for Websockets problem that you have today. So I think the ideal abstraction for Bandit HTTP2 implementation is to prepare it for streaming communication in any direction. In fact the Plug is quite limited in what it can do.
That said, I think it's possible to reuse a good part of your current http2 stack The problem with the plug's API is that it is made to handle request reply and gRPC has many modes besides request reply, namely stream in, stream out, bidirectional stream, and unary (request reply). And I think you would run into the same Plug API for Websockets problem that you have today. So I think the ideal abstraction for Bandit is to prepare it for streaming communication in any direction. In fact the Plug is quite limited in what it can do.
That said, I think it's possible to repurpose a lot of your current http2 stack to implement gRPC, but maybe this isn't the project to do that. Is it ok for you if I leverage your http2 stack in my project? I'll give credit to you.

[mtrudel]

Sounds great! You can absolutely use whatever code is in this repo by the terms of license (MIT in this case). No need for my permission (though I'm happy to see you making us of this!)

While I'm pretty intent on keeping Bandit laser focused on Plug as an upstream API, it may be worthwhile to try and accommodate other APIs in a streamlined way. If you end up coming up with a useful abstraction that captures that, by all means let's try and find a way to make things work here without a hard fork.

I'm going to go ahead and close this issue for purposes of cleanliness; if you feel there is future work to discuss, feel free to reopen the issue or create a new one.

Thanks for the issue!