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.
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:
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.
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:
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:
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:
// 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:
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.
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
- The useful components, properties, and methods that Vapper injects for the application.
- Custom Connect/Express/Koa Server
- Vapper's plugin architecture and plugin development
- Vapper's existing built-in plugin
We have used Vapper in our own projects, welcome Star, PR:
Top comments (9)
Interesting article. But if you're going to claim to do things better than Nuxt or Quasar, I would have expected differentiating tables of features and performance. Right now you're asking your readers to take a jump of blind faith that Vapper is better than Nuxt or Quasar.
Hey, thanks for your reply, our focus is only on introducing the features of vapper, and then giving the choice to the user, isn't it?
You said this:
"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."
The important part being: "what is different about Vapper"
But, no differences between Vapper vs Nuxt/Quasar are pointed out! Those questions were never answered.
Slightly misleading and somewhat what I'd call a "bait and switch" technique in your writing to entice readers to keep reading thinking they'll find the comparison data that never comes. The way this is written, it is intended for someone to know Nuxt/Quasar so they can figure out what the differences are on their own.
If you want to be a credible writer, then follow through with your statements. Revise and re-edit until your story is what it says it is. Also, get someone to proof-read it. For spelling, grammatical, truthfulness and completeness.
Thanks for the article, and for the introduction to Vapper.
This article does a good job of highlighting some benefits of Vapper over Nuxt. However, it doesn't seem to make any mention to the downsides of Vapper, or where Nuxt could be the better choice. It would be nice to see an unbiased comparison of the two.
Would you be able to talk a bit about where Vapper falls short of Nuxt? Perhaps situations where it wouldn't be the right choice? I believe that would help us make a more informed choice.
Awesome article! Definitely hits home on some of the nuances of Nuxt. For the nuxt page/route convention/system, I wouldn't say that its a "limitation" as you've pointed but more of a mere convention/system since you can easily add custom routes to bypass the page/route system.
Overall, great article! Will definitely try out vapper this coming weekend. Thanks!
Vapper looks awesome, I will try it out this weekend. Especially with VueApollo and GraphQL.
Great Article and Framework, this is fairly new.
Is there any updates if Vapper has typescript built-in?
I've seen the codebase and its written in plain javascript.
Hi, thanks, Vapper borrows vuecli or poi to manage webpack configuration, so you can use vuecli or poi's typescript plugin to support TS
What about performance versus Nuxt ?