How to examine the options of a generated boilerplate?

Peter Babič — Wed, 08 May 2019 21:41:58 +0000

This article is a mix of multiple domains, mainly Nuxt project scaffolding and m the struggles I went through along with some shell scripting, when this whole trip got me diving deeper. If you are interested in any of this, you are welcome to continue reading.

Nuxt project generation

Nuxt.js is a framework for creating Vue.js applications, you can choose between Universal, Static Generated or Single Page application.

Following the instructions on their installation page using the create-nuxt-app scaffolding tool, the first step there is to Choose between integrated server-side frameworks and currently in Nuxt version 2.6.3 you can choose one of the following:

None (Nuxt default server)
Express
Koa
Hapi
Feathers
Micro
Adonis (WIP)

If you are a regular Node user like me, chances are that you have used Express before. There may even be "Hello World!" examples utilizing it as a quickstart guide for Node scattered across the internet, so without much thinking, choosing Express seems like an obvious choice.

The rest of the installation offers multiple awesome options to get you going. I was really pleased to see Buefy and Jest in the list. Hopefully you can find most of your favorite choices there as well.

When the project is generated, you can start building. You write your first Vue component and want to get the data into it. The Axios module is basically the way to go, Nuxt adds some functionality on top of it. You can read more in it's documentation.

Obtaining the data

But where do Axios get data from? Of course, from the integrated server-side framework chosen right in the first step! We have chosen Express, it has to be able to serve data for our simple app easily. No problem - there is a documented way: to use the serverMiddleware property.

Unfortunately, it is not all that perfect. There is an open issue with the two related closed issues. Long story short, you can use the serverMiddleware to serve the data with the framework of choice (one from the step 1 of the Nuxt installation), but the development still needs o lot of server restarting which is painful. You are basically required to have two separate parts - the server and the Nuxt project. Of course, when you work with micro-services, this is expected, but for simplest projects, I would not recommend having the data served directly from the Nuxt application itself yet (although if you follow the issue, you can see it is work in progress).

Choosing Express won't exactly help us with the development of the server. It is not because of the problem with the Express itself - it is because of the unresolved issue with HMR (Hot Module Replacement) and cache. This makes choosing all the other (koa, hapi, etc.) equally unhelpful. There is but one not self-explanatory choice in the list: the first one.

Nuxt default server

What does None (Nuxt default server) exactly mean? I could not find much details about this choice anywhere - maybe I need to improve my searching skills. However, I decided to dust off my shell scripting skills instead.

By generating two identical Nuxt projects, one named default-server and one express-server, choosing the specified server-side framework option as the only difference. Ready to compare the projects to learn more I fired off the following command:

 diff -r default-server express-server

If you think ahead, you can understand why it is not such a good idea. My screen got instantly filled with useless data. So I learned how to exclude something from the comparison and went further:

 diff -x node_modules -r default-server express-server

This was much helpful but it still contained a lot of irrelevant data. I have applied more exclusions:

 diff -x node_modules -x package-lock.json -x .nuxt -x README.md -r default-server express-server

Really helpful but there is one thing that can be improved:

 diff -x node_modules -x package-lock.json -x .nuxt -x README.md -r default-server express-server 
--color

Perfect.

The results however are far more minor than I would have thought. The only difference worth mentioning is how the server is started and the presence of the single file in express-server/server/index.js. See for yourself:

nuxt.config.js
1c1
- import pkg from './package'
--------
+ const pkg = require('./package')
3c3,4
- export default {
--------
+ module.exports = {

package.json
2c2
-   "name": "default-server",
--------
+   "name": "express-server",
8c8
-     "dev": "nuxt",
--------
+     "dev": "cross-env NODE_ENV=development nodemon server/index.js --watch server",
10c10
-     "start": "nuxt start",
--------
+     "start": "cross-env NODE_ENV=production node server/index.js",
15c15,16
-     "nuxt": "^2.4.0"
--------
+     "nuxt": "^2.4.0",
+     "express": "^4.16.4"

pages/index.vue
6c6
-         default-server
--------
+         express-server

Only in express-server: server

Digging deeper is unfortunately outside the scope of today's article.

Conclusion

The Nuxt scaffolding tool let's you choose integrated server side framework. It is possible to use it to serve not just the project (bundled JS, CSS and HTML) but the actual data that will hydrate the skeleton as well. However, it is fairly impractical, as it requires constant server restarts to apply even the slightest change, but this might change in the future.

Choosing no server-side framework using the option Nuxt default server for the simplest projects looks like better choice over Express due to one less dependency. You probably won't leverage the Express (or any other server-side framework for that matter) much anyway.

You can see the full difference of the two scaffolded projects in this Gist. I feel like I am missing something hugely obvious, so please help me point out the important bits. Cheers!

DEV Community: Peter Babič

How to examine the options of a generated boilerplate?

Nuxt project generation

Obtaining the data

Nuxt default server

Conclusion