Target Markets and Caching

[PythonLinks]

There are big companies, and small companies, and their needs are very different. (Really I mean high traffic and low traffic web sites).

Big companies need a distributed cache. Maybe multiple caches, each configured differently and selected with a matcher. Of course big companies have all the money, and so that is what they get. On the Caddy Server Github account we find https://github.com/caddyserver/cache-handler, which does all of that.

Small companies just need a local cache that works reliably. Caddy 1 was great. Easy to install, it did https and it included a cache, which worked reliably. It met all of this small company's needs. I am still using it. I keep wanting to upgrade, I keep waiting for Caddy 2 to include a cache which meets my needs. I worked hard this week with the cache-handler plugin, but in the end gave up. You can read my comments and documentation pull request over on the cache hander github pages. Your tech support was great, thank you.

It absolutely makes economic sense to focus on the needs of the large companies. Particularly in America where big companies are effectively monopolies, it makes financial sense to target their needs. But please do not forget about the needs of the rest of the world's small poor companies. That is where the future growth lies.

[mholt]

Ok - thanks for the feedback. I'm not sure from the issue what made you gave up; a simple cache is just one or two lines of config.

But please do not forget about the needs of the rest of the world's small poor companies

There isn't any feature we are excluding from "small poor companies" -- it is freely open and available to all. You just have to learn how to use it. That's the same for large companies too! We can offer professional/expert support, but services cost a fee because we also have to pay the bills.

[PythonLinks]

I totally understand that you need to pay the bills. Really this open source software is a miracle. Thanks to all that so many people have done.

But the needs of small companies are very different than the needs of big companies. I do not need lots of features. Quite the reverse, I need fewer features. What I need is simplicity. I have way way too tall a software stack to manage single handedly. And every layer of the stack keeps getting more features, more complexity.

If you take a look at cache-handler, it has a ton of dials to tweak, and not much documentation about which ones do what. Worse yet it references three other products, each of which has more dials to tweek.

In contrast cdp-cache has way way fewer options. It is much simpler. That is what small companies need is simple software. Not more features. It is a very very different way of seeing things. And yet cache-handler is under github.com/caddyserver, but cdp-cache is not, telling me that the needs of small companies are second class citizens.

I particulary liked your experimental caddy option of loading a new plug in. Very conceptually simple. Maybe it was complex under the hood, but from my perspective it was as simple as it gets.

Now I am back to figuring out how to install go, it has to be an older version, compiling --with the plugin. Updating the executable, stopping and restarting, not just reloading. It is all too complex. Caddy 1 had this great feature that it was really quite simple to install and configure. In contrast I have been wrestling (and loosing) to caddy 2 for too long. (NGinx with Certbot on Linux is working just fine and was easy to install).

What I really want, is just install a pre-compiled executable,

pkg install caddy

and then have a web form to fill out, where I cannot make a typo, and all of the options are laid out. Maybe cPanel did something like that for managing a web server. KISS. Keep it simple. Less features, not more features.

There was once a great image, of google search, just a text line and a button, the ipod touch, just 5 buttons, and "your app". Tons of fields to fill out and buttons to choose from. We all know which did best in the market.

"Crossing the Chasm" is a very interesting book. It is about moving from the early adopters, maybe in this case the hard core geeks, to the larger market. Dumb end users like me, who are not go developers, and do not care at all about, or should i say, do not even know about rfc compliance. We just want a simple product that works.

[mholt]

Caddy 1 had this great feature that it was really quite simple to install and configure.

Installation and configuration of Caddy 2 is the same as Caddy 1. Same Caddyfile (albeit not backward-compatible with Caddy 1), same install steps (download the binary, put it in PATH, run it -- or use a package installer for your OS).

What I really want, is just install a pre-compiled executable, pkg install caddy, and then have a web form to fill out, where I cannot make a typo, and all of the options are laid out.

Ok, well, Caddy 1 never offered that, so I'm not sure what your point about Caddy 2 being harder than Caddy 1 is.

[PythonLinks]

Sorry if I was not clear. caddy 1 included caching. Caddy 2 I have to do go compilations to include caching. First it was such a pain to figure out which caching to use, what are the different ones, and i still have not gotten either of two to do what I need. (I am still trying.)

Since Caddy 1 had a cache manager included, I did not have to figure out which cache manager to use.

Since the Caddy 1 cache manager was conceptually simple, the documentation was easy to read and understand. It was complete. With the cache-manager, It took a while to extract the concept from the configuration file that it has multiple caches which are conditionally executed. My pull request explaining that was ignored.

In Caddy 1 I could just edit the config file and run. Caddy 2 it has to be specially formatted to run. There is an additional command caddy fmt, it has an overwrite command. Since I am not a go developer, I am suspicious of overwriting the files I am editing. Initially I had to also execute the fmt command. Later I wrote a 3 line script to edit the file, and then format it.

I now realize that overwriting is the standard in go projects, lots of developers so they format it in a standard way. I am a stand alone developer, I like my formats, I do not want another command.
It reminds me of react, where every single extra white space has to be removed. Just more burdens on the small developer. If I ever reach large amounts of traffic, then I can remove the extra white spaces. KISS.

I hate being so negative. I understand that open source is driven by the needs of the developers, the contributors. Maybe of the consulting clients. Caddy is the way that you want it to be.

I have this other vision. That the software stack should be easy to use. That I can fire up a mainstream linux server , and it is secure by default. That I do not have to do extra work to harden it. That I can install a web server, and without reading the docs, configure it using a form on the web. That I can upgrade the OS without breaking everything. It is not going to happen. I understand that. But maybe a simple caching system, with good documentation, can be included in the default caddy release.

And it is okay that you do not do that. I just want to make sure that you understand the perspective of the beginner user. Eventually some of us will succeed, we will get large, we will have no go developers on staff, and so will need your consulting services.

[francislavoie]

caddy 1 included caching.

You might be talking about https://github.com/nicolasazrak/caddy-cache which was also a plugin in Caddy v1. It never had caching built-in.

In Caddy 1 I could just edit the config file and run. Caddy 2 it has to be specially formatted to run.

That's not true. It's exactly the same in v1 as v2. You have a Caddyfile. You point Caddy to it, and it reads the config and runs. That hasn't changed at all.

The syntax did change, but that's because it had to, so that we could support tons of new features.

There is an additional command caddy fmt, it has an overwrite command.

You don't have to run that. That's just a helper to clean up any syntax issues you might have. It'll make sure your config is nicely indented so it's easier to read, etc. Yes we do warn if you didn't run it, but that's just a warning. You can ignore warnings. The warning is a suggestion that "hey, you might want to clean up your config so that it's nicer". And if you share your config and ask for support, it saves us some headaches if you formatted it, so we can more easily read it.

Since I am not a go developer, I am suspicious of overwriting the files I am editing.

That has nothing to do with being a developer. All it does is fixup indentation, basically (tabs instead of spaces, indentation inside blocks, etc). You don't have to use the --overwrite flag if you're nervous about it. Run it without that, and you'll see the output after the formatter runs. If you don't like what it did, that's fine. But if it looks good, run it again with --overwrite to let Caddy clean it up.

It reminds me of react, where every single extra white space has to be removed. Just more burdens on the small developer. If I ever reach large amounts of traffic, then I can remove the extra white spaces.

It has nothing to do with space/traffic concerns. It's about having consistency. If the code/config isn't consistently formatted, then it's harder to read, for everyone.

If you don't want to run caddy fmt every time you make a change to your config (you don't need to though, like I said), you could use VSCode with this extension https://github.com/matthewpi/vscode-caddyfile-support which can automatically format your Caddyfile every time you save it.

and without reading the docs, configure it using a form on the web

That's not a goal of the Caddy project. We really think that reading the docs is the best way to learn how to use your tools. And building out a web interface with forms to configure Caddy is a very very difficult problem to solve. You keep saying "KISS" but that is entirely the opposite of simple. That's very complex.

The only way we would have a feature like this, we'd want it to be done right, which means it would have to support as many usecases as possible. And doing that with a form or web interface is not easy at all. It's way easier and more flexible to just use a config file.

[PythonLinks]

Thank you for correcting me. I learned a lot. Most appreciated.