Please correct me if I am wrong but caddy v2 is like the previous Linux unikernel design where if you wanted to add a plugin to your caddy v2 service, you will have to:
Write that plugin in Go
Compile caddy with this plugin (alongwith other plugins) that you want in your caddy v2 service
Which means that:
You cannot write caddy v2 plugins in another language, only Go?
You cannot “drop in” or “take out” a plugin and restart caddy but literally have to compile caddy on every plugin change
Are these 1 - 4 all accurate?
In that case:
Is there a caddy v2 plugin that perhaps allows a way for an external service to act as a caddy middleware, say over HTTP or gRPC? (by being a middleware, it will affect how caddy behaves - like a plugin would but be more limited/might lack a lot of the features a native Go plugin can expose)
Lacking that, is there any way to kind of achieve the same effect as writing a simple plugin that’s not very featureful, but in another language than Go - I’m thinking like FastCGI but for affecting caddy’s behavior itself?
Regarding 5 and 6, there’s lots of things you can do just using Caddy to select for specific kinds of requests and forward them via HTTP reverse proxy to an appropriate application server, which you could write in any language and could have whatever logic you want. This, of course, exports your “middleware” beyond the realms of Caddy’s ongoing state - which would be the case with any kind of programming language jump you could possibly implement anyway.
What kind of Caddy behaviour are you looking to have your middleware alter? Can you achieve these alterations via the JSON API?
It’s possible that this immediate usecase can be resolved just by affecting the HTTP request-response payloads (so FastCGI could work) but I wanted to learn about ways where more advanced behavior would be needed (for example, if I wanted to persist caddy config in Hashicorp Consul or secrets in Hashicorp Vault)