I spent almost a whole day on getting the fundamentals set-up right, as the documentation was somewhat vague compared to Vue’s or those of other frameworks. Apart from that, I discovered that for the part of signing credential tokens with a private key, I probably had to rely on a separate back-end (or utilize
npm packages such as
DOTENV, not to be confused with the
dotenv-module from Nuxt), as by design (aiming at optimized Server-Side Rendering, or SSR) Nuxt does not seem to have server-side-exclusive information. This was to the best of my knowledge at this point, so I may have been mistaken.
Eventually, I decided that Nuxt.js probably isn’t the most appropriate cookware for my groceries given its oversized shipment meanwhile missing some key parts I needed.
So, installation first. I was using macOS Mojave here, and since I had had
node 10.15.1 and
npm 6.13.4 (so
npx was also present) installed already, I jumped over to Nuxt.js’ installation guide. I first tried their
create-nuxt-app method, which prompted me with a bunch of options regarding what to include in first-run. I selected
none for wherever possible, and was then instantly overwhelmed by the massive amount of node modules that this command pulled (almost 10,000). The whole process took over 3 minutes to complete. Upon first running
npm run dev (which under the hood got executed as
npx nuxt), whoa, almost 150 megabytes of memory was consumed! Even though this was the development mode (and people say that this is already better than most other frameworks), and a second try of
npx nuxt build; npx nuxt start reduced the instant memory consumption to around 20 megabytes, I was still annoyed that I had to start with such a colossal initial environment.
Second trial. I noticed that the Nuxt team has put a second method on their website, “Starting from scratch”. This looks more friendly, and it seems to me that I have more control over what I want installed. I remove the previous folder, and with the example
packages.json provided on Nuxt.js’ getting started guide, I ran
npm install --save nuxt. Still, it was a few thousand packages, but better than what I got from my first attempt.
Subsequently, I needed to figure out the configurations, which was not too hard with Nuxt.js’ guide. I created an
src directory to store all Nuxt-related files, and set it as the value for
I have to say that Nuxt provides a really intuitive and handy way of creating routes for requests: basically, all that a developer using Nuxt needs to do is to create request-handling files in a series of sub-directories inside the
pages folder. A normally-named folder represents a layer of static request path, and an underscore-prefixed folder represents a layer of dynamic request path, capable of holding variables. This saves developers from the trouble of defining routes explicitly in some form of routing middlewares.
Then came the catch: to decide where contents should be placed. Nuxt provides three folders for structuring its webpages (“views”), a
pages folder, a
layouts folder, and a
components folder. A structural graph is available to illustrate the relationship between these parts:
It was a little bit confusing to me that
layout is actually a super part of
page in Nuxt, as I understood
layout as a form of theming for
pages. However, it still makes sense to have
pages wrapped by
layouts, similar to how every
Activity is rendered inside a
Layout in Android.
Here I also noticed a bug which happened to me in development mode only: regardless of inclusion, CSS codes (either direct or built from pre-processing codes) from every file inside the
layouts folder was included in the preview of the generated
index.html, even though I used the
scoped keyword for
<style> tags. According to this thread on GitHub, this problem has been present since
v1.4.2 of Nuxt.js, and still has not been fixed to date. As it happens, the
scoped keyword did help with specifying from which file should styles be retrieved to apply to an element on a page, so apparently, Nuxt was just loading redundant content in development mode. When I looked at the built version, there was no inclusion of styling codes from irrelevant layouts. This is nevertheless a trivial bug that hopefully gets fixed.
I then started looking for best practices to secure my signing credential obtained from Apple’s developer website for generating valid JSON Web Tokens (
JWTs) for OAuth purposes. Ideally, this Nuxt app that I was trying to create should only obtain and exposed signed
JWTs to its clients, without leaking the original private key in any form. I looked into
axios proxies, and Nuxt’s
dotenv-module, and several threads (1, 2) suggested that this was not quite possible without a secondary back-end or using
DOTENV from the start, that is, outside the scope of Nuxt.
Notice here that I am not talking about a protected api route or protected resources that will be accessible to a user once they are verified, which can be achieved by
axios proxies, but an key that should only be available to the server-side (i.e., back-end), similar to
SECRET_KEY in Django. Since
JWTs are usually short-lived, and best practice suggests that session access tokens be generated as frequently as every usage, I needed a mechanism to spontaneously generate valid signed
JWTs on the server-side. The best solution I could come up with was setting up a separate process that binds only to the server’s
127.0.0.1), responsible for signing and delivering
JWTs for the Nuxt app in the topic. Eventually, this was the practice I decided to implement.
I have come to the following incomplete summary of my first impression on Nuxt.js.
- Easy and one-step setup
- Clear structuring of content and routes
- Server-Side Rendering
- A heavily dependent initial setup process
- Lacking of server-side-access only information storage/management
This exploration narration ends here as the idea of trying out Nuxt was instantaneous (i.e., emerging a day before this article). With the power of Vue under the hood, Nuxt does seem to leverage the scalability and modularization of web application development. It is just more powerful than, meanwhile not as powerful as, what I needed.