Closed rustatian closed 1 year ago
Following. Let me know if you have any questions!
Hey guys 👋🏻
I investigated the possibility of adding RR and the module to the Caddy web server, and unfortunately, this is not possible because RR will lose almost all its features. I mean, no Queues support, temporal, gRPC, etc. Using the fCGI
/http2/h2c
/http
reverse proxy is better to pass the request to the RR.
@rustatian Are you sure? Why would it have to lose all its features?
@rustatian The suggestion was that it should run as an App Module, see https://caddyserver.com/docs/extending-caddy#app-modules. That would have Caddy start up RR as a dependency (i.e. the whole thing, not just one part), then you'd also have an HTTP handler module that would send the request through RR's pipeline.
RR is a little bit more than an HTTP handler 😃 HTTP is only one of the various ways to deliver the payload. Others are: temporal server handlers, various jobs handlers (RPC): Kafka, rabbitmq, etc, gRPC handlers. Many of the plugins have their own RPC bridges (via our goridge protocol to communicate via IPC with PHP processes). So, as far as I understand, the Caddy server use case is for the HTTP(2,3,S) only? So, for example, if the user uses only RPC with, let's say, the SQS queue, there is no need for Caddy (for such users). And because of that reason, if we integrate an HTTP part of the RR into the Caddy, all other RR's features would be lost.
@rustatian
So, as far as I understand, the Caddy server use case is for the HTTP(2,3,S) only?
No, the HTTP server is itself just a plugin to Caddy. It's an app module. RR would probably be an app module as well, not just an HTTP handler.
For example, here's a layer4 (TCP/UDP) server for Caddy: https://github.com/mholt/caddy-l4
Don't limit yourself to just HTTP!
I used the wrong terminology. Yeah, RR also has a TCP plugin. But by HTTP, I meant the whole transport layer (that was my mistake, I wanted to use fewer words).
Do you mean, that the app module can be fully independent with its own configuration, lifetime, http/grpc/tcp/temporal/jobs endpoints?
@rustatian
Do you mean, that the app module can be fully independent with its own configuration, lifetime, http/grpc/tcp/temporal/jobs endpoints?
Exactly. 🎯
Well, Caddy manages the config including reloads, but your app can manage state that persists through reloads, etc. It can definitely open its own sockets, etc.
I suggest you read through https://caddyserver.com/docs/architecture to get an idea of the architecture.
Yeah, I saw this doc earlier, thanks @francislavoie.
I'll discuss this case with the team, but I'm worried about the use cases.
So, to have a nice integration for the Caddy web-server, would be nice to have a RR module, but not the app. In this case, users will benefit from the Caddy, but RR should be significantly reworked with only the HTTP PHP processes pool.
Plugin
No response
I have an idea!
Implement a RR as a Caddy module.
Draft notes: Implement a
RoundTripper
to have a RR as a Caddy transport (http). Since this is good for the HTTP, other plugins, such as rr-temporal or those, that don't use an HTTP as a transport can't be easily integrated (for example, the whole queues bundle (jobs, sqs, beanstalk, etc.), rr-temporal integration. So, basically, we should find a way to use the RR plugins inside the Caddy. OR: Just use a classic approach, like,reverse_proxy
to the RR endpoint.config:
pool
configuration inside theserver
section (this is not the same as the RR configurationserver
section).roadrunner
repository. I guess, we only need to use a RR SDK, especially: linkPart of the discussion is here: https://github.com/roadrunner-server/roadrunner/issues/917