Having to recompile to add functionality that alternatives provide as dynamically loaded plugins is insane. This is 2017. Linux has had loadable kernel modules since 1995, and I worked on them for other versions of UNIX as far back as 1991. I understand that it's hard for a Go program to support plugins written in other languages using a more conventional runtime. No problem there. However, there's just no excuse for relying on recompilation instead of dynamically loading modules also written in Go and thus using the same runtime. I really want to like Go, but as long as the Go community clings to long-discredited ideas regarding things like packaging and distribution and symbol versioning I just don't feel like I can depend on it to build infrastructure that will remain robust over time.
> However, there's just no excuse for relying on recompilation instead of dynamically loading modules also written in Go and thus using the same runtime.
Actually there is.
Go plugins are something we're looking at, but it's complicated and the technology is currently immature. Please read this forum thread in full: https://forum.caddyserver.com/t/go-1-8-plugin-model/934?u=ma...
Like the rest of Caddy, I find the plug-in system to be simple and solid. Some people just seem to like complexity. (smile)
Is there any way to query what plug-ins are bound into a Caddy exe? (given that I'm a non-Go-programming, Windows guy)
An idea I had for the website was to allow us to sign in and have accounts. Downloads and plug-in preferences could be tracked. (It might even lead to a way to pry some money out of cheapskates like me with premium plug-ins and whatnot.)
It sound like a neat project where there are some good defaults and where most weaknesses (performance, flexibility, etc) come from golang. It would be interesting to see a rewrite in another language.
I'm confused, aren't Go plugins exactly the feature you want? And on that note, it was just introduced as of 1.8, wasn't it?
Seems a bit harsh to criticize a project for not using (during it's development time) unfinished and not production ready features.
Caddy dev's are probably going to be all over that.
Googling around for a Caddy file[0], it looks fairly similar, and not so much easier or harder to configure or understand that NGINX config.
I'd also like to see a benchmark vs. H2O which seems to have the most advanced HTTP/2 support right now (its running the nghttp2 web site for some time now).
I'm a longtime Windows developer who doesn't have much patience with nerdy complexities. I started in 1996 with a buggy, gawd-awful Netscape webserver, moved to the late-lamented O'Reilly WebSite (even had a T-Shirt) and reluctantly settled on MS IIS, with occasional Apache encounters. Caddy has been an absolute breath of fresh air.
I currently run 4 sites from a system at my home, using Namecheap dynamic DNS. Caddy serves the basic web pages and static content and also reverse proxies to an internal Python server for dynamic content. Sounds a little complicated, but believe me, configuration is dead-simple thanks to Caddy. Plus I get full HTTPS from Let's Encrypt for the cost of supplying my email address and agreeing to a EULA - no configuration needed at all.
I've never used a webserver that was easier to configure or had such low resource requirements.
That is funny because I have setup Apache, Nginx, and IIS web servers before and by far the one I found to have the most nerdy complexities is IIS.
All in all, I do like Caddy's defaults and out of the box for newer tech. I haven't really tried it much, mostly out of complacency with nginx/iis in Linux/windows. And I will definitely never run Apache on a new box again.
All in all however, I like the look of Caddy. The best bit I feel has been left out though:
"That is why, effective this release, Caddy will automatically serve all live sites over HTTPS without user intervention."
Which I think is just brilliant.
How is this done? Ie, to not need any account and still get new/valid certs.
And, on that note, what is the difference between having an account and not? Eg, how might using no accounts harm a production environment?
Just trying to wrap my head around that. Really cool UX for side stuff!
edit: Ah, looks like there is an account involved - it creates one, possibly using your email address. This makes more sense now.
Personally I found Nginx configuration much simpler than Apache. I think Nginx is pretty intuitive, it certainly is much supplier than IIS, which is a nightmare.
I posted a gist[0] with my Caddy+Varnish+PHP-FPM configuration and a README explaining the hows and whys. I'm moving a bunch of WordPress sites from Apache/mod_php to this configuration (each site's PHP-FPM instance is Dockerized, but that's out of the scope of the gist). Hopefully someone finds it helpful!
0. https://gist.github.com/mwpastore/f42f6f1309a7b067519f4c08e1...
