What is Caddy?

Caddy is a web server much like Nginx. It calls itself “a new kind of extensible platform for server apps”. Features include -

1. Easy configuration (super readable config. files - we will get to this in a bit)
2. Configuration is exposed as APIs (JSON files can be used to create/change configuration)
3. An extensible plugin system
4. Automatic https using Let’s Encrypt

Caddy does all this with a single executable, and a single configuration file.

Caddy version 2 caused some ground-breaking changes from v1. Since I did not quite use v1, can’t really compare how they fare. Caddy is free to use and is licensed under Apache 2.0 open source license.

Why use Caddy?

The most important factor for me - Caddy enables quick setup of a server with multiple apps without spending hours on configuration.

As a non sysadmin developer, I approach server configuration with some skepticism. I cannot quite get away from it due to cheaper costs, but I would rather spend time creating something else rather than fiddling with server configuration.

Nginx has been a great companion. The configuration files are just ok and I don’t mind them as long as they are setup only once. However, introducing multiple apps, APIs and static file hosting on same server confuses me and requires quite a bit of trial & error configuration.

Over years I have tried solving the problem with a few options -

• Use cookie cutter config files with Nginx
• Nginx configuration file generator
• Alternate server options (there are many options but one needs to be careful about a solution that is too niche or has a thin community behind it)
• Self-hosting solutions like Parse that let’s me get away with backend configuration changes

It is with that background that I find Caddy a refreshing change. With minimal configuration, easier changes and acceptable performance, Caddy works great for this use case.

My Typical Use Case

My preferred architecture when using “quick” Vue apps -

1. A node server that serves APIs and database on a 2-4 GB server
2. Front-end hosted on same server. VueJS is my framework of choice
3. Static content on Github, Netlify or similar

Each server typically hosts 1-4 production apps or x test/MVP apps.

The Caddy server should -

1. handle API requests and proxy them to Node server. The requests may be from the frontend application or from external systems
2. handle frontend requests when routing to different pages

Caddy Configuration

While I found Caddy documentation to be great in general, the examples seem to be for a more “in the know” audience. The radical changes from v1 to v2 have made some of the previous content irrelevant.

I typically use Caddyfile to store Caddy configuration, which does not appear to be future-proof but is fully supported and quite easy to use. The structure looks somewhat like this -

example.com {
    root * /usr/www/example
    file_server
}

You can store this file wherever you please, but I use /etc/caddy/Caddyfile.

I can now start Caddy with -

sudo caddy start -config /etc/caddy/Caddyfile

I will switch to configuration using JSON at some point in time with a typical structure looking like this -

{
  "apps": {
    "tls": {
      "certificates": {
        "automate": ["example.com", "another-example.net"]
      }
    }
  }
}

The JSON format is not quite difficult to understand, but more “typing”. I don’t send API requests to configure web servers (thank heavens), and the specific port remains closed in the firewall.

Caddy and Quasar

While I knew Caddy’s configuration was quite simple, I could not get it to play nicely with client-side routing of Vue apps at the beginning.

After some hit & miss, and lot of searching on Google, I have this configuration that simply works.

# Caddyfile
example.com {
    root * /usr/www/example

    route {
        reverse_proxy /api/* localhost:3000
        try_files {path} {path}/ /index.html
        file_server
    }
}

another-example.net {
    root * /usr/www/anotherexample
    file_server
}

This file accomplishes the following -

1. Host site example.com
   • redirect all requests with /api/* to localhost:3000. The node server listens on port 3000, and that port is not open to the Internet
   • redirect any request to / and allow Vue to handle routing. I do this using try_files {path} {path}/ /index.html, which tries locating for a file with the name passed from URL and redirects to it. If no file is found, it directs to index.html
   • the route statement ensures that Caddy follows the given order while handling URLs. APIs with /api/ are served by Node server and other URLs are served by client-side routing
2. Host site another-example.net
   • serve files in /usr/www/anotherexample

All I now need to is point the domain name to the IP address of this server and both example.com and another-example.net just work!

When not to use Caddy?

Caddy works great for all my use cases. I don’t quite build Twitter or Facebook level apps - so I should be ok I guess.

At the same time, I will not quite migrate everything to Caddy at this time. If you have configured Nginx a couple of times, you know that all it takes is some “lazy copy/paste” to get the whole thing working. Simpler needs = simple tasks = no need to take drastic action to change status quo.

You may also not want to use Caddy if you -

• manage quite an intensive server that handles high traffic volumes. Nginx can manage twice the processing
• want to consume as less memory as possible. Caddy is light-weight but not as much as Nginx, and can consume more than double the memory

See -

• benchmarks for Caddy2 vs Nginx on Centminmod forums.

Finis

I personally believe in a great future for Caddy. It has a great community, good documentation and is a delight to use.

Start using Caddy for your dev/test environments and see the difference. Migrating production environments may be a long drawn out decision based on your intended use.

Use Case: Frappe Charts in Vue

Let’s consider a simple use case for using Vue plugins - we want to use Frappe charts.

We can simply use vue2-frappe to easily do that. Just install the package in your project -

npm i --save vue2-frappe

Next, register it as a Vue plugin -

import Vue from "vue";
import Chart from "vue2-frappe";

Vue.use(Chart);

Frappe in Quasar

In Quasar you can’t do a Vue.use like the above. There is no main.js to orchestrate that.

The documentation of vue2-frappe does say that we can use vue2-frappe directly in components..

import { VueFrappe } from "vue2-frappe";

export default {
  components: {
    VueFrappe,
  },
};

.. but, I was never successful in getting that to work.

Time is always of essence - so I did the next best thing. I used a boot plugin to register Vue plugins.

Create ./src/boot/vplugins.js.

import Vue from "vue";
import Chart from "vue2-frappe";

// Similar to Vue.use()
Chart.install(Vue);

Register this new plugin in quasar.conf..

module.exports = function (/* ctx */) {
  return {
    // app boot file (/src/boot)
    // --> boot files are part of "main.js"
    // https://quasar.dev/quasar-cli/cli-documentation/boot-files
    boot: ["vplugins"],
  };
};

You can now happily use frappe charts from any component -

<template>
  <div>
    <vue-frappe
      v-if="trend['labels']"
      id="prodTrend"
      :labels="trend['labels']"
      :dataSets="trend['datasets']"
      type="bar"
      :height="300"
      :colors="['blue']"
    ></vue-frappe>
  </div>
</template>

<script>
  export default {
    data() {},
    props: {
      trend: {
        // provide options for Frappe chart
      },
    },
  };
</script>
>

Have additional plugins to register? Instead of creating distinct files for more than one Vue plugin, we just combine everything in one file - just change vplugins.js and you are all set.

import Vue from "vue";
import Chart from "vue2-frappe";
import GobblyGook from "gobbly";

Chart.install(Vue);
GobblyGook.install(Vue);

Enter boot files. These were simply called app plugins which led to them being mixed up with Quasar’s own plugins. Now they are simply referred to as “boot files”.

Why Boot Files?

Use cases for boot files include -

1. Use common start-up code for your app
2. Enable functions that are accessible from anywhere
3. Initiliase your own dependencies

A great example is provided out of the box in axios. If you select axios library to be enabled while creating project using Quasar CLI, you will find a boot file in ./src/boot/axios.js.

import Vue from "vue";
import axios from "axios";

Vue.prototype.$axios = axios;

Next, this plugin is registered in quasar.conf.js.

module.exports = function (/* ctx */) {
  return {
    boot: ["axios"],
  };
};

In any component, you can now do -

const { data } = await this.$axios.get(url);

.. without the need to import axios.

Create a simple boot plugin

The axios plugin works just fine as-is. But, you have no way to provide options in one common place. Take an example of providing just the bearer token -

const { res } = await this.$axios.post(
  `store.state.baseURL/${reqURL}`,
  reqData,
  {
    headers: {
      Authorization: store.state.bearerToken,
    },
  }
);

Clutter affects code readability and maintenance - more importantly, we lose “cool” factor.

Let’s create our own version of Axios so that bearer token is included automatically for authentication.

If you are curious - we could always extend the current plugin, but I found it the hard way that it led to confusion for people on the beginner side of spectrum (“axios automatically authenticates in that project, but there is something wrong here”).

Create a new file ./src/boot/req.js.

import axios from "axios";

const req = {
  async post(url, data) {
    try {
      return await axios.post(`https://baseURL.com/${url}`, data, {
        headers: {
          Authorization: "token",
        },
      });
    } catch (e) {
      console.error(e);
    }
  },
};

export default async ({ Vue }) => {
  // something to do
  if (req) req.Vue = Vue;

  Vue.prototype.$req = req;
};

We are doing simple things here -

1. Create an object with a function
2. Create a function within the object that makes axios call with arguments passed to the function
3. Register object to be globally available through a Vue prototype

Register the plugin in quasar.conf.js..

module.exports = function (/* ctx */) {
  return {
    boot: ["req"],
  };
};

You can test this code from any component..

<template>
  <!-- Stuff goes here -->
</template>

<script>
  export default {
    methods: {
      async updateRecord() {
        let reqData = { a: 1, b: 2 };
        const { data } = await this.$req.post("get-sum", reqData);
        console.log("data", data);
      },
    },
  };
</script>

Accessing the Store

Wait, there’s more.

There is no need to hard-code values when you can bring them from one central place - from the Vuex store.

Let’s do that.

Modify ./src/boot/req.js.

import axios from "axios";

export default async ({ Vue, store }) => {
  // something to do
  const req = {
    async post(url, data) {
      try {
        return await axios.post(`${this.store.state.baseURL}/${url}`, data, {
          headers: {
            Authorization: this.store.state.bearerToken,
          },
        });
      } catch (e) {
        console.error(e);
        // throw if you want to pass errors back
      }
    },
  };

  req.Vue = Vue;

  Vue.prototype.$req = req;
};

We have included store argument and moved req within the exported function (which was not strictly required, but it avoids creating more variables and confusion with this).

You can now use this.$req.post() from anywhere within your app, and authentication is automatically taken care for you.

Similar to Vue and store, there are other arguments available to your boot function -

• router
• ssrContext: useful in server rendered contexts
• app: object that root component instantiates with

Read more in docs.

Why is Quasar any different?

“Is it not just Vue?”

Well, yes. But.. the project structure created by Quasar CLI differs from a “normal” that by Vue CLI. Quasar CLI builds on top of Vue as well but may not follow similar practices to other frameworks / libraries using Vue.

If you can’t really move away from the standard structure, just use Quasar as a plugin in a project created by Vue CLI. You may lose some features, but you may find yourself at home and stay happy. In that case, you could leverage your existing knowledge on using Vuex states and mutations in multiple ways.

Or.. you could just experiment more and accept a different normal.

An app created by Quasar CLI does not have main.js. Vue compile/load sequence is taken care by quasar with options defined in a /quasar.conf file.

The store/index.js file in Vue CLI will have a function invocation -

// ...
export default new Vuex.Store({
  // ...
});

This store is then used in main.js..

import store from "./store";

// ...

new Vue({
  router,
  store,
  render: (h) => h(App),
}).$mount("#app");

This and the corresponding setup within Vue CLI projects make it convenient to access states or mutations (in addition to helper functions).

1. Use this.$store in components, store modules, or router

2. Directly import store and use it to access store functions

   import store from "./store";
   // ...
   
   if (!store.state.auth.isLoggedIn) {
     // how do you penalise a person without login
   }
   

In Quasar CLI, the /store/index.js file returns a store object..

//...

export default function({ ssrContext }) {
  const Store = new Vuex.Store({
    namespaced: true,
    //...
    return Store;
  }
}

… but this is not used in the same way as Vue CLI.

Also, the modules are structured within folders in /src/store by default. And.. you can use quasar CLI to create a new module.

Directly accessing store will not work -

1. Can’t just import store

   import store from "./store";
   
   store.set("blah", val);
   // store is a function and does not support `set`
   

2. this.$store is undefined and not available in stores / modules

How can you use a Vuex store in Quasar?

You have more than one way to get to the store..!

Use helper functions

Continue to use mapState, mapMutations, and friends to manage your state.

Use Pathify

Works great everywhere. Use sync in store modules or in components. See working with Pathify.

Use “normal” commit

Fall back on the trusty commit in store modules!

// ...
export default {
  name: "contact",
  namespaced: true,
  state: state,

  actions: {
    async updateContact({ commit }, data) {
      //...
      commit("first_name", "Ram"); // within this module
      commit("action/updateCall", actionData, { root: true }); // mutation from `action`
      //...
    },
  },
};

Change the default store structure

Just change the Vuex store structure to access it from anywhere.

Modify ./src/store/index.js.

import Vue from "vue";
import Vuex from "vuex";

// Use a new variable and export values to change default behaviour.
let store = null;

Vue.use(Vuex);

// .. other code

export default function () {
  const Store = new Vuex.Store({
    namespaced: true,
    name: "global",
    state: { answer: 42 },
    // mutations / getters / plugins/ other code
  });

  // add this so that we export store
  store = Store;

  // Quasar default
  return Store;
}

// add this line to access store wherever you need
export { store };

This is useful to access state as well as commits.

// ./src/router.js

import store from "./store/index";

Use boot time plugins (“app plugins”) in Quasar

Create a new plugin (say superfunc) by creating a new file in /src/boot/superfunc.js -

const superfunc = {
  // ...
  store: null,
  // ...
};

export default async ({ store, Vue }) => {
  // something to do
  if (superfunc) {
    superfunc.store = store;
  }

  Vue.prototype.$superfunc = superfunc;
};

Then happily use superfunc in places -

console.log("story store", this._vm.$superfunc.store);

Parting Words

Not quite what you call “super fun”, but stores simply work in Quasar, and that’s all there is to it.

I faced this issue in a medium-sized project that I was playing around with. I was stupid enough to change a few lines in multiple components, and lo and behold - I don’t see the changes being compiled. Restarting quasar dev doesn’t help either.

The command simply does not move ahead beyond a point..

The first and foremost thing you do is to revert things to where they were. With no real commits, I could only fidget around till I get to a working state, or go back to the original.

After trying about 10 minutes, I gave up and was exploring package.json and quasar CLI params to see whether I could anything else. And.. saw this.

"scripts": {
    "lint": "eslint --ext .js,.vue --ignore-path .gitignore ./",
    "test": "echo \"No test specified\" && exit 0"
},

I see commands, I run them. So, lint it was.

npm run lint

Looks like quasar dev breaks without errors if there are errors in templates - who knew..? I do remember seeing errors in Vue CLI for similar issues - should go back, compare them, and report the issue back to the teams (soon 🐌).

Also, linting helps. Again, who knew.. :)?

The fix by itself was easy enough. All it needed was a change in two lines of code in distinct components. And, I was all set to continue breaking the application further.