DEV Community: Jiří Procházka

Starting up a new Vue 3 project with Vite and Docker

Jiří Procházka — Wed, 16 Feb 2022 17:50:54 +0000

I'm enjoying new Vue 3 script setup syntax and blazing fast hot-reload using Vite.
And as I'm using Docker containers for my development environment here are the few steps needed to start a new Vue 3 project with Vite under the Docker.

Docker

docker-compose.yml

version: "3.4"
services:
  my_frontend:
    container_name: my_frontend
    image: node:lts
    working_dir: /var/www/html/app/
    entrypoint: /bin/bash
    expose:
      - 8000
    volumes:
      - ./frontend/:/var/www/html/app
    tty: true

This is simple. Just using the node:lts image and setting some stuff around.

I'm spinning the container up with:
$ docker compose up -d
and hooking into the container with:
$ docker exec -it my_frontend /bin/bash

New Vue Project

When in the docker container, create a new Vite with Vue project:
$ npm init @vitejs/app
Then select the Vue, name the project and so on.
After the project is generated, install the packages.

Setting up the Project for running under the Docker

For running the project under the Docker there are some adjustments that need to be done in the Vue/Vite project.

At first the port must be set to match the one in the docker-compose.yml file (in my case it is 8000).

Open the vite.config.js file and add the server object with the port field to the configuration:

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

// https://vitejs.dev/config/
export default defineConfig({
  server: {    // <-- this object is added
    port: 8000
  },
  plugins: [vue()]
})

We must also add parameter --host to the vite command in the package.json, so replace dev command in scripts:

// package.json
...
"scripts": {
    "dev": "vite",
...

with:

// package.json
...
"scripts": {
    "dev": "vite --host",
...

And that's it!

Sending SvelteKit server requests with httpOnly cookies

Jiří Procházka — Fri, 10 Dec 2021 11:04:33 +0000

Form my new project I have chosen a SvelteKit for a frontend and AdonisJS on a backend.
On Svelte I appreciate SSR and almost boilerplate-less pure javascript code.

httpOnly cookie problem

Here and there I get stuck. Like last time, I was writing an authentication using tokens and httpOnly cookies (will write a dedicated article about it in the near future). Basically the backend is instantiating a httpOnly cookie with a session id in it and send it to the frontend. Frontend should send such cookie back with each request and the backend can read the token from the cookies and verify it.

So far, so good, unless you use the load method (loading in docs) and the request is sent not by the client, but by the SvelteKit server in pre-render. In such case the cookies must be passed to the SvelteKit server first, in order to be sent with the request to the API.

There are some discussions about it like #1198 or #1777, but the proposed solutions are just workarounds, some even with security issues.

Proposed solutions (working, but not ideal)

Basically there are proposed solutions:

1) use handle hook and read the token from cookies in the backend (handle method is run on every request before the component is created), pass it to the frontend to the load method and use it with the fetch from there. The thing is you are exposing the token to the client and it is a big security vulnerability.
It is even stated in the docs:

In the load method you:

should not directly reference any API keys or secrets, which will be exposed to the client, but instead call an endpoint that uses any required secret

2) Which is leading to the second workaround - use the SvelteKit endpoint as a proxy (do not mistake it with the backend API endpoint. This endpoint is part of your SvelteKit frontend application). To pass every request to the endpoint first, enrich the request with the cookies or token in headers and then, finally, make a request to the backend api. You can even make such endpoint generic (and proxy all your app request through this single endpoint), but it could possibly be kind of a bottleneck and I just simply don't want this proxy in my frontend app.

A proper solution

I was still hoping for a better solution, the correct one.

In SvelteKit documentation there is stated a small discreet note:

Cookies will only be passed through if the target host is the same as the SvelteKit application or a more specific subdomain of it.

Which means we have to get rid of localhost with port (localhost:####) urls and use proper domains. Locally.

I'm using Docker for a local development anyway, so some reverse proxy image was an easy choise.

The idea was simple - according to the SvelteKit docs quote above the frontend and the backend must be run on the same domain (not possible), or the frontend can run on a domain dev.localhost and the api on a subdomain be.dev.localhost.

It is also a premise for cookies to be exchanged between the frontend and the backend (the backend and frontend must share the same 2nd level domain).

If you are just keen for the solution, here is the docker-compose.yml:

version: "3.4"
services:
  proxy:
    container_name: proxy.dev.localhost
    image: jwilder/nginx-proxy
    network_mode: bridge
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
    networks:
      - myNetwork

  frontend:
    container_name: dev.localhost
    image: node:lts
    working_dir: /var/www/html/app/
    entrypoint: /bin/bash
    environment:
      - HOST=0.0.0.0
      - VIRTUAL_HOST=dev.localhost
      - VIRTUAL_PORT=80
    expose:
      - 80
      - 10000
      - 35729
    volumes:
      - ./frontend/:/var/www/html/app
    tty: true
    networks:
      - myNetwork

  backend:
    container_name: be.dev.localhost
    image: node:lts
    working_dir: /var/www/html/app/
    entrypoint: /bin/bash
    environment:
      - VIRTUAL_HOST=be.dev.localhost
    expose:
      - 80
    volumes:
      - ./backend/:/var/www/html/app
    tty: true
    networks:
      - myNetwork

  database:
    container_name: db.dev.localhost
    image: mongo:4.4.10
    environment:
      - VIRTUAL_HOST=db.dev.localhost
    ports:
      - 27017:27017
    volumes:
      - mongodata:/data/db
    networks:
      - myNetwork

networks:
  myNetwork:
    external: true

volumes:
  mongodata:
    external: true

Important to note is:

You must also put these domains to the HOSTS file:

127.0.0.1 dev.localhost be.dev.localhost db.dev.localhost

On Windows 10 the hosts file is on the path C:\Windows\System32\drivers\etc\hosts.

Conclusion

There is a way how to setup the dev environment using Docker to simulate a production domain setup on local computer. In such setup you can use httpOnly cookies authentication without any security leaks made just because of the compromises for the local development.

Vue/Vuex ...mapComputed

Jiří Procházka — Sat, 25 Jan 2020 09:42:06 +0000

When you are binding directly a Vuex state property to the form via v-model you need to create Two-way Computed Property like this:

// MyComponent.vue
<input v-model="email">

// MyComponent.vue
...
computed: {
    email: {
      get() {
        return this.$store.state.email;
      },
      set(value) {
        this.$store.commit('setEmail', value)
      }
    }
}
...

Doing this for each property is annoying and verbose. Fortunately we can inspire in Vuex mapGetters, mapMutations and mapActions methods and create our own mapComputed method:

// mapComputed.js
export const mapComputed = (module, fields) => {
  const obj = {};
  fields.forEach(field => {
    obj[field.name] = {
      get() {
        return this.$store.getters[`${module}/${field.getter}`];
      },
      set(value) {
        this.$store.commit(`${module}/${field.setter}`, value, { root: true });
      }
    };
  });
  return obj;
};

The usage is simple then:

// MyComponent.vue
...
computed: {
    ...mapComputed("user", [
      { name: "email", getter: "getEmail", setter: "setEmail" }
    ]),
...

Where name is the name of the computed property used in v-model, getter is the name of getter and setter is the name of used setter.

This is only the simple version considering using modules only.

Vuex mixins

Jiří Procházka — Wed, 22 Jan 2020 15:39:46 +0000

Wouldn't it be nice to have a possibility to use a Vuex setter in more modules?
That is what are mixins made for, right?

But you can't use Vue mixins in Vuex. Despite that, thanks to ES6 features it's easy to achieve that. We have a spread operator available.

// mixins.js
export const mixinState = () => {
  return {
    fields: []
  };
}


export const mixinMutations = () => {
  return {
    addField(state, field) {
      state.fields.push(field);
    }
  };
}

// module.js
import { mixinMutations, mixinState } from "./mixins.js";

const state = mixinState; // replace whole state with the state defined in mixin

const mutations = {
  ...mixinMutations(), // merge mutations defined here with mixin mutations
  clearFields(state) {
    state.fields = [];
  }
};

const actions = {
  addField({ commit }, field) {
    commit("addField", field);
  }
}

export default {
  namespaced: true,
  state,
  mutations,
  actions
};

And that's it. Such simple it is.

Vuex mixins vs. modules

Of course you can have objections that it is what modules are made for. That's true, but modules are good for more complex units of state (state, getters) and behaviour (actions, setters).

Vuex mixins are more for reusing simple things like structures stored in state and it's setters.
For example I have a deeply nested object which is fallen apart into several state fields after normalization and I want to use such fallen structure in more Vuex modules. And the setters doing such decomposition accordingly with it.