3 ms·

One thing that drives me off from Caddy is that many features don't compose with each other well. I understand this might be a sacrifice for a simpler user inte

by htfy96 7y ago

One thing that drives me off from Caddy is that many features don't compose with each other well. I understand this might be a sacrifice for a simpler user interface, but the composition of declarative-style configurations is always a mess compared to imperative ones like nginx.conf

mholt 7y ago
Thanks for the feedback. (To clarify, nginx's config is also declarative... well, mostly: they got in trouble for mixing declarative and imperative [1].) You'd be surprised what we've been able to accomplish with upgrades to Caddy's configuration in Caddy 2. Its config is technically declarative, but the underlying JSON structure [2] implies a procedural flow, enabling you to compose certain behaviors that almost feels imperative. When Caddy 2 release candidates go out in a couple months, try it out with both the Caddyfile (soon to be majorly improved in beta 13) and the underlying JSON and you'll see what I mean. Oh, but if you want to still use your nginx config, go ahead (WIP) [3]. :) [1]: https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ https://www.nginx.com/resources/wiki/start/topics/depth/ifis... [2]: https://caddyserver.com/docs/json/ https://caddyserver.com/docs/json/ [3]: https://github.com/caddyserver/nginx-adapter https://github.com/caddyserver/nginx-adapter
- htfy96 7y ago
  Thank you for the quick reply! Currently our routing needs lots of flexibility, and we are wondering if it's possible to have something similar to OpenResty-style [0] config where builtin directives are Lua functions, and users can handle requests by dispatching them in Lua with a function call. [0]: https://openresty.org/en/ https://openresty.org/en/
  - mholt 7y ago
    We have a handler-scripting solution in the works that may be about 2x faster than nginx+Lua (from initial early benchmarks). Can you file an issue to request specifically what you need? https://github.com/caddyserver/caddy/issues/new https://github.com/caddyserver/caddy/issues/new

by htfy96 7y ago

mholt 7y ago

Thanks for the feedback. (To clarify, nginx's config is also declarative... well, mostly: they got in trouble for mixing declarative and imperative [1].) You'd be surprised what we've been able to accomplish with upgrades to Caddy's configuration in Caddy 2. Its config is technically declarative, but the underlying JSON structure [2] implies a procedural flow, enabling you to compose certain behaviors that almost feels imperative. When Caddy 2 release candidates go out in a couple months, try it out with both the Caddyfile (soon to be majorly improved in beta 13) and the underlying JSON and you'll see what I mean. Oh, but if you want to still use your nginx config, go ahead (WIP) [3]. :) [1]: https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ https://www.nginx.com/resources/wiki/start/topics/depth/ifis... [2]: https://caddyserver.com/docs/json/ https://caddyserver.com/docs/json/ [3]: https://github.com/caddyserver/nginx-adapter https://github.com/caddyserver/nginx-adapter

htfy96 7y ago
Thank you for the quick reply! Currently our routing needs lots of flexibility, and we are wondering if it's possible to have something similar to OpenResty-style [0] config where builtin directives are Lua functions, and users can handle requests by dispatching them in Lua with a function call. [0]: https://openresty.org/en/ https://openresty.org/en/
- mholt 7y ago
  We have a handler-scripting solution in the works that may be about 2x faster than nginx+Lua (from initial early benchmarks). Can you file an issue to request specifically what you need? https://github.com/caddyserver/caddy/issues/new https://github.com/caddyserver/caddy/issues/new