Vapperjs - A Vue-based SSR framework
Tags: vue
Published: 2019-11-04 11:40:04

---
title: Vapperjs - A Vue-based SSR framework
published: true
description: Vapper does its best to bring the development experience of SSR applications closer to SPA
tags: vue
---

If you are using `Vue` to do isomorphic projects, then `Nuxt` and the `Quasar Framework` are good choices. But today I am going to introduce a new `SSR` framework based on `Vue`: https://vapperjs.org/ .

# The features of Vapper

I guess most people will have a question after seeing the title of this article: Why not use a framework such as Nuxt or Quasar Framework directly, but instead create a wheel? Next, we will try to answer these questions by introducing the features of `Vapper` to see what is different about `Vapper`.

## Goal 1: Vapper does its best to bring the development experience of SSR applications closer to SPA

How can vapper do this? We need to consider in several ways:

- 1. Project structure:

We know that `Nuxt` is a file system-based route, which means that it has a gap with the traditional `SPA` application in how files are organized. You need to write pages (or components) according to their conventions. However, we don't have these limitations when developing `SPA` applications, so we want a framework that allows us to organize files without any restrictions, just like the normal `SPA` application.

It's not that hard to achieve this, because the official documentation of Vue SSR teaches you this way, so `Vapper` is just a wrapper on this basis.

- 2. Data prefetching:

If you have used `Nuxt`, then you should be familiar with the `asyncData` component option it provides. You need to do data prefetching in the `asyncData` function, but it has some restrictions, such as the `asyncData` component option can not be used for any component, and only Can be used in routing components(or `pages`), and component instance are not accessible within the `asyncData` function.

Data prefetching, a simple understanding is request data, we do not have the limitation of "requesting data only in the routing component" when developing the `SPA` application, and there is no need to worry about not being able to access the component instance. So we want a framework that will save you from these mental burdens and do its best to make data prefetching of isomorphic applications closer to the `SPA` application.

`Vapper` makes this all possible. For details, read the official documentation to learn how to prefetch data in `Vapper`: [Data Prefetch](https://vapperjs.org/data-prefetching.html#data-prefetch).

Through the above two efforts, we have almost made the experience of developing the `SSR` application closer to the development of the `SPA` application.

## Goal 2: Only responsible for the necessary webpack configuration

Many companies or teams basically develop a so-called scaffolding tool, but most of the scaffolding tools developed by the team are only Vue CLI3 that implements 1% of the functions. In fact, under the existing architecture of Vue CLI3, you can fully implement the requirements of any business-specific scenario without having to write a scaffold yourself.

Vue CLI3 draws on Poi's architectural ideas. Poi is also an excellent `webpack` management tool, an excellent project scaffolding. So we hope to have such an SSR framework, which is only responsible for the necessary `webpack` configuration, that is, only responsible for the SSR-related `webpack` configuration, and other configurations are assigned to these excellent scaffolding management. The benefit of doing this is two-way, that is, `Vapper` provides SSR capabilities for these scaffoldings, and the capabilities of these `webpack` management tools have become `Vapper`'s capabilities, two birds with one stone.

One concept in Vapper is Configer, which is simply two modules:

- [@vapper/configer-vue-cli](https://vapperjs.org/configer.html#vapper-configer-vue-cli)
- [@vapper/configer-poi](https://vapperjs.org/configer.html#vapper-configer-poi)

This makes it possible to combine Vapper with these great `webpack` management tools, and more importantly, even if you don't use Vue CLI3 or Poi, you can write your own `Configer` to integrate into your own scaffolding, the documentation can be read here: [Write Configer](https://vapperjs.org/configer.html#writing-configer).


## Goal 3: Route level control

What is the "route level control" capability? For the sake of understanding, I posted a picture of the official website:

![](https://vapperjs.org/assets/img/spa-ssr-prerender.701eb249.png)

In a word, we hope that accessing different routes will be handled differently depending on the needs. For example, we want to apply server-side rendering(`SSR`) when accessing route `/home`; but send SPA resources to the user directly when accessing route `/foo`; when accessing the route `/bar`, we can send the pre-rendered content to the client.

The reason for this is because sometimes, not all pages we need to do `SSR`, and we can pre-render some of the pages, these are effective ways to improve service performance.

You can do this easily in `Vapper`. You can choose to turn `SSR` on or off by specifying `ssr: true/false` in the route `meta`, for example:

```js
new VueRouter({
  mode: 'history',
  routes: [
    {
      path: '/home',
      component: () => import('./components/Home.vue'),
      meta: {
        // Using SSR
        ssr: true
      }
    },
    {
      path: '/foo',
      component: () => import('./components/About.vue'),
      meta: {
        // Turn off SSR, and send SPA resources when users access /foo
        ssr: false
      }
    }
  ]
})
```

It's that simple and straightforward. At the same time, one thing I have to mention is that if all routes do not have `SSR` applied, then your project is no different from the `SPA` application. In other words, if you want to migrate an existing `SPA` project to a `SSR` project, then `Vapper` is great for you.

For pre-rendering to be a bit more complicated, you need to install the @vapper/plugin-prerender plugin and then configure it in `vapper.config.js` as follows:

```js
// vapper.config.js
module.exports = {
  plugins: [
    [
      '@vapper/plugin-prerender',
      {
        // This is the route to be prerendered
        routes: ['/foo']
      }
    ]
  ]
}
```

This way, during the build phase, `vapper` will pre-render `/foo` and generate a `html` file, which will be sent directly to the client when the user accesses the route. It should be noted that pre-rendering is only supported for routes with SSR enabled, which is reasonable.

Goal 4: Error handling

`Vapper` makes the error handling more flexible, we have two choices when the error occurs:

![](https://vapperjs.org/assets/img/error-handling.3a08fb6c.png)

In addition to displaying custom error pages, we can also choose to fall back to the SPA mode. The benefits of doing this are obvious, because some errors may only occur on the server, or some errors are non-fatal, we can choose to fall back to SPA mode when such error occurs, so that users can continue to use our application, which is very important for some scenarios that focus on conversion rates.

Read more: [Error Handling](https://vapperjs.org/error-handling.html#error-handling).

## More features

In addition to the core goals outlined above, `Vapper` has other great features, such as:

- [Out-of-the-box micro-caching and Component level cache support](https://vapperjs.org/caching.html#caching)
- [The useful components, properties, and methods that Vapper injects for the application.](https://vapperjs.org/injection.html#the-clientonly-component)
- [Custom Connect/Express/Koa Server](https://vapperjs.org/custom-server.html#custom-server)
- [Vapper's plugin architecture and plugin development](https://vapperjs.org/write-plugin.html#basic)
- [Vapper's existing built-in plugin](https://vapperjs.org/using-plugin.html#basic-usage)

We have used `Vapper` in our own projects, welcome `Star`, `PR`:

[Github: Vapper](https://github.com/shuidi-fed/vapper)