Personal Life

Moving to a new Country 🇳🇱

My personal life changed quite at bit! After committing to a long-distance relationship (Leipzig - Amsterdam) last year, it was time for the next step. Eight hours of train ride every two weeks could be worse, but it was still a lot. And the time in between when not seeing each other was also not ideal. In addition, having no "main home" was not for me, especially because I had quite some plans that need a steady home base.

So, time for a change! And because I can work from anywhere, I decided to move to Amsterdam in April. While it wasn't easy to "leave my friends and family behind" - just physically of course, I'm really happy with the decision. Especially because it isn't the other side of the world and I can still visit them regularly in not even a day of traveling.

Finding a flat wasn't that easy. But thanks to being a web developer, I could optimize a lot of the flat hunting. I even gave a talk on how I did it!

Amsterdam is a beautiful city, and I'm really happy to live here. Not too big (hey Berlin!), but also not too small - beautiful architecture, vegetation and full of bike roads. Not that we don't have them in Germany, but it's a different level here. And I love it!

The cultural differences compared to Germany are not that big and you can get around with English quite well. Learning Dutch is on the list, but priority-wise it wasn't that high for 2023. For 2024, it is part of my goals though!

One thing that was a bit unusual for me though - flats in the Netherlands often come without a floor! So, buying and installing the laminate was one of the first things on the list.

Traveling to unknown Places ✈️

Besides getting to know Amsterdam better and better, I also had the opportunity to travel to new places and even new countries! From going to Brussels for a long weekend meeting with a good friend and doing some sightseeing, to traveling to Cambridge and Oxford after a conference, I've seen a lot. One of the most amazing trips this year was to Toronto, Canada. Before speaking at VueConf Toronto, I had the chance to explore the city and meet some amazing people. In addition, I also had the chance to visit the Niagara Falls, which was a great experience. Maybe a bit cold (4°C), but still a breathtaking view.

A travel of another kind was to Tomorrowland - my only music festival this year. I've been to a few in the past, but this one was the first time at Tomorrowland. And it was spectacular! The atmosphere, the people, the music - everything was great. I'm really looking forward to going there again next year - if my luck is good enough to get tickets again.

Social Connections

Even though I moved to a new country, I still had the chance to meet lots of amazing people. From like-minded new faces at conferences and meetups, to old friends and family. Of course, I visited my hometown every now and then to ensure I don't lose contact with my friends and family there.

And it is always fascinating to meet the people you know from the internet in person. Be it with parts of the Nuxt team in Amsterdam, or finally connecting in real life at events - it's always a great experience.

Studying

Ehh, yes. That might be a weird fact (sometimes even fun fact), but I am still studying at the university in Dresden. Nevertheless, I'm finally at the end of my studies and started writing my thesis this fall. I hope to finish it in the first quarter of 2024 and finally get my degree - but a few more pages (read: at least sixty) are between me and that goal. So, wish me luck!

Health

My routines changed to the worse in the first part of the year. Due to the commuting and then moving, my sport routines really suffered. Same for my eating habits. But towards the end of the year, I slowly found my way back on track to establishing a healthy lifestyle. I started going to the gym again, and the nutrition improved a bit as well. But there is still way to go, making this one of my main goals for 2024.

My work-life balance, on the other hand, is still good. The only thing that could go better there (and in general)is my time management and planning skills.

Open Source

2023 was a good year for my open source contributions. While the move impacted my time for open source, I still contributed a lot. As usual, most of it in the Nuxt.js and UnJS ecosystem, but also to other projects if I saw some low-hanging fruit.

It is important to mention that most of my contributions are not code-related and therefore not fully covered by the GitHub graph. Most of my tasks I'd described as "community engineering and management" tasks. They range from triaging issues and PRs, answering questions on Discord, Twitter and other channels, to improving documentation and more. Non-code contributions are an essential and important part of open source, and I'm happy to help with it.

Of course, I also shared my knowledge at conferences, rewrote my website and even started creating more content again. I'll cover that in the next two sections - Speaking and Content Creation.

Speaking

Speaking is one of the things I really enjoy. I love to share my knowledge and experience with the community and help others to learn something new. I had the chance to speak at a number of conferences and meetups, as well as partially MC'ing two larger ones.

In numbers, I gave 13 talks and was part of 2 panels at 4 meetups and 9 conferences. In addition, I was an MC at WeAreDevelopers and Vue.js Amsterdam. You can find the full list on the speaking page here!

Fun fact: The busiest conference was WeAreDevelopers, where I was MC'ing, part of a panel and gave two talks. That was a lot of joy, but also a lot of work.

I definitely want to continue speaking at conferences and meetups in 2024. I had a blast and it is a great way to meet new people and share knowledge. I don't have a definitive number of talks I want to give in 2024, but I think 8 is a good rough estimate.

Content Creation

Personal Branding and Website Rewrite

Content creation was always something I enjoyed and wanted to do more. In 2018, I started writing blog posts about Nuxt and Vue regularly but eventually stopped due to the lack of time. One of the issues that kept me from releasing a blog post was my self-built blog which simply became legacy. Eventually, my backend server expired rendering me unable to update a single line of content. And yes, this all screamed one thing: Rewrite!

The goal was to merge my website and blog into one (before the blog was a separate Nuxt app on a subdomain), give everything a modern design and switch to Nuxt content. So, with a plan in mind I started to create the website you are reading this post on now. As before, I wanted to open-source it. But there was more behind it.

Another goal I wanted to achieve was to improve my personal branding. The process started with a modern logo incorporating the lightbulb - which was always part of my online identity. I also wanted a consistent design across all my channels, so I created a new banner for Twitter, YouTube, Twitch and more.

This all launched in the last week of September, where I created a "launch week" event. From Monday to Friday, I deployed my new website, released two new blog posts, did a live stream guiding through the website's code, eventually open-sourced it, and then revealed another project I was working on: My YouTube channel.

YouTube + Twitch

Yes, the YouTube channel was one of the things that I wanted to do for a long time. I always enjoyed creating videos and sharing my knowledge. But first, I lacked the time and consistent branding. After that I lacked a "home" to record my videos in. I decided if I want to tackle it, I need to do it right and consistent. After the move to Amsterdam, the upcoming months were occupied with stuff revolving around the flat, furnishing it and making it a home. And then, I finally had a place to record videos.

And, oh boy, did I look forward to it. Even though the launch week event described in the previous subsection was a lot of work, it sparked so much joy. Creating videos became a passion, and thanks to Niki (my girlfriend), I also had someone to help me with the editing, not only making it look more professional and saving some time, but also letting each of us shine on what we can do best.

If you haven't checked the channel yet - I am focusing on intermediate and advanced content around Vue, Nuxt, UnJS, and the JS and TS ecosystem in general. I noticed a lot of beginner content is out there, but as soon as things become more complex or advanced, there is a high demand, but not enough content to match it. So, I want to fill that gap and create content matching the niche. Because of my expertise, I thought this is even more suitable, and I can help the community that way.

Besides the YouTube channel, Twitch and livestreaming was another big topic for me. But after three consecutive streams I realized it was tricky to stick to a regular schedule for these. While you can flexibly produce YouTube clips, streaming means (ideally) having a fixed timeslot every week, and due to conferences, work and other commitments, it wasn't feasible for me. Nevertheless, I want to stream a few more times next year but don't want to commit to a regular schedule.

In numbers, I published 16 videos - 14 original videos (once a week) and two uploaded livestream VODs from Twitch. The videos now have over 27.000 accumulated views, and the channel reached 1.500 subscribers before the end of 2023. These are staggering numbers - I didn't expect such a great start.In addition, I did not set any goal for the channel except being consistent with releases, so I'm even more delighted about the outcome and all the positive feedback and constructive criticism I got.

Thanks to everyone for the support and feedback, as well as for the ideas for new videos. PS: If you have some, please let me know!

Newsletter

And yes, I also started a newsletter with the website launch, which I want to continue and actually highlight in 2024. I'm not sure yet how often I want to send it out - so far, I didn't due to the lack of time. But I hope to find a good schedule for it in 2024.

Update: The newsletter didn't work out — I didn't have the time to keep it going, so I've shut it down.

Business

Open source is lots of fun, but it doesn't fully pay the bills. At this point, I want to thank all my sponsors and also past sponsors for their support. It means a lot to me, and I'm really grateful for it.

The main chunk of my income comes from my work at my own company through consulting and workshops - and I think it is the perfect counterpart to open source. I can work with companies and help them with their projects while also learning a lot from them and their use cases. That allows me to understand how they use Nuxt.js, which pain points they experience and how I can help them. On the other hand, they also expect me to know the guts of Nuxt.js and how it works internally - a perfect symbiosis.

In 2023, I worked together with incredible people and companies. Business-wise, 2023 was a great year, even with quite some time spent on the move and the economic crisis. With a good number of clients as wells as more than 12 workshops (at conferences and for businesses), I'm really pleased with the outcome of 2023.

Goals and plans for 2024

To finish this years recap, I want to set some goals for 2024 that I want to achieve. Some are "SMART" but some goals might not have a fixed number attached to them. While this might not be the best way to set goals, I think there are some goals that are not measurable but still achievable.

• Personal
  • Get a good gym routine, going at least once a week without more than two weeks of break (due to conferences, holidays, etc.)
  • Lose weight and get in shape - at least 10kg - and keep it below that
  • Travel to two or more new places I haven't been to yet
  • Continue to learn Hungarian
  • Start learning Dutch
  • Keep my work-life balance as good as it is right now
  • Finish my thesis (finally - due time is March)
  • Improve my time management and planning skills
• Open Source
  • Invest time into open source and the community consistently (at least half a day a week, but probably more than that)
• Content Creation
  • Release at least 52 videos on YouTube - that's roughly once a week again
  • Become a YouTube partner
  • Write minimum 4 blog posts
  • Do a livestream on Twitch every quarter, at least.
  • Send out the first newsletter, then decide on a schedule (possibly 1x a quarter?)
• Speaking
  • Be a speaker at ~8 conferences or meetups - I want to continue speaking at conferences and meetups and share my knowledge with the community. No fixed number here, but I think 8 is a good baseline. I want to pick the conferences I speak at more carefully and focus on the ones that I really want to attend.
• Business
  • Continue to being able to pay my bills with my own company
  • Increase my companies profit by at least 10% compared to 2023 (no absolute numbers here, sorry folks!)

Conclusion

2023 was a terrific year for me, personally and business-wise - with lots of changes and new experiences. I'm really grateful for all the opportunities I had and the people I met. I'm looking forward to 2024 and hope to see you there! Some in person at conferences, some online on Twitter, YouTube, Twitch or somewhere else.

The burden of a general solution

If you want to integrate a solution into one single project, no matter if it is a feature, a third-party service, or a library, it is pretty straightforward. No matter how weird the requirements are, you can almost always find a way to make it work. It only has to work for you and your team - your project only.

The tricky part starts when you want to make it work for more people, dare I say, for everyone. It starts with thinking about all the different use cases, all the different setups, all the different requirements. You have to make sure that your solution is flexible enough to be used in all those different scenarios, or at least 80 percent of them. Also, your solution should not be too opinionated, so it can be used in a wide range of projects, no matter how weird the requirements are - maybe even weirder than in the project you've built the integration initially for.

And then it comes to configuration...

I personally am a big advocate of convention over configuration, but sometimes you just can't get around it. If you want to make your solution flexible enough, you have to provide a way to configure it. The options should be straightforward and easy to use, ideally aligning with the mental model of potential users already. You want to find the sweet spot between too many and too few options.

Frankly, this is a common struggle for module authors! Fellow Nuxt contributor Julien Huang (did I hear someone saying server components?) also shares similar experiences:

While developing the Nuxt Application Insights module, I had to split what I created as my own implementation into a Nitro package (nitro-applicationinsights) first and am now working on creating a Nuxt module.

It is kinda difficult to take out what specific implementation you've made for your own project and then decide, for example how to allow build time and runtime configuration so that the module or library is generic enough.

Thankfully, we have a nice hooking system for that 😝

Testing will also be quite complex as I have to dive into the source code to figure out what to mock.

In the case of the Sentry module, Rafał, the author and maintainer of the Nuxt 2 module did a great job and laid out a solid foundation - but this also adds another part of complexity: Which features and settings should be ported to the Nuxt 3 module? Which features and settings should be dropped, and what should added? And how to adapt the existing set of features to make it work seamlessly with the Composition API or Nitro, Nuxt's server engine?

I am afraid I can't answer these questions yet - but I am working on it. While being committed to finding the best possible solution, it will take some time. But just because the module needs a bit more time to become Nuxt 3 compatible, this doesn't mean you have to wait.

Own your implementation

And actually, it can be beneficial to own your implementation. It depends on the use case but can make sure that it fits your needs and requirements as needed and don't rely on module authors for a fix. Furthermore, you decide the scope of features and can omit unnecessary ones that might bloat your bundle, reducing complexity. In addition, you actually learn how the integration works under the hood, which means less unknown magic.

On the other hand, it might lead to increased maintenance effort as you are responsible for the implementation and have to keep it up to date. But this is a trade-off you have to make eventually, for every dependency, framework, library, or module you use.

Integrating Sentry into a project

Okay, enough of the theory and preamble. Let's get into integrating Sentry! The following approach was also implemented by me in one of my client's projects, which is Intrinsify's academic online portal.

We will take a look at both sides of your application, the server-side covered via integrating Sentry with Nitro, and the client side which will be covered through the Sentry Vue plugin.

To make things easier, I've created a tiny GitHub repository containing the code for this implementation, so you can easily move it into your own project. You can find the GitHub repository here.

Defining the runtimeConfig

Before we get into the details of each implementation, we need to define a common interface for configuration variables, which will be the

There are lots of configuration options, but we start simple. We need Sentry's DSN to work and also provide an environment flag to later differentiate between development, staging, and production environments.

We have to put the content in the public part of the runtime config, as the Sentry Vue plugin will be used on the client side and needs access to the configuration.

By the way: If you want to learn more about how to properly set keys in your

runtimeConfig

, Friday's launch week surprise will be really helpful for you!

export default defineNuxtConfig({
  runtimeConfig: {
    public: {
      sentry: {
        dsn: '',
        environment: 'development',
      }
    }
  }
})

As mentioned before, various other configuration options can be part of your

• NUXT_PUBLIC_SENTRY_DSN
  to set up Sentry's DSN
• NUXT_PUBLIC_SENTRY_ENVIRONMENT
  to set up the correct environment tag
• And whichever config options you want to add

Alright, we are good to go for starting with the server-side implementation!

Nitro integration - Sentry on the server side

When I originally started implementing the Nitro part of the Sentry integration, it was... tricky, to say the least. But since Nitro v2.6, things got way easier thanks to the new hooks! We will use three of them straight away. Also, this guide will work for a pure Nitro server too! Just skip the Nuxt-specific parts (e.g. ignore the

Before we start with using Nitro though, we need to install the dependencies, namely Sentry's node package and the profiling integration (if desired). This can be done via

After we do this, we will create a new Nitro plugin. In there, we want to initialize Sentry and set up the profiling integration. We will also retrieve our variables from the runtime config and set up the nitro hook:

import * as Sentry from '@sentry/node'
import { nodeProfilingIntegration } from '@sentry/profiling-node'

export default defineNitroPlugin((nitroApp) => {
  const { public: { sentry } } = useRuntimeConfig()

  // If no sentry DSN set, ignore and warn in the console
  if (!sentry.dsn) {
    console.warn('Sentry DSN not set, skipping Sentry initialization')
    return
  }

  // Initialize Sentry
  Sentry.init({
    dsn: sentry.dsn,
    environment: sentry.environment,
    integrations: [nodeProfilingIntegration()],
    // Performance Monitoring
    tracesSampleRate: 1.0, // Change in production!
    // Set sampling rate for profiling - this is relative to tracesSampleRate
    profilesSampleRate: 1.0 // Change in production!
  })

  // Here comes the hooks
})

So far so good, we set up the configuration. As mentioned before, lots of things can be added to the

Capturing errors with Sentry in Nitro

First, we want to ensure that Sentry will be capturing all kinds of errors Nitro is throwing at us the user. For this, we can use the

// Inside the plugin, after initializing sentry
nitroApp.hooks.hook('error', (error) => {
  Sentry.captureException(error)
})

Now, all errors will be captured. You might not want to capture some of these, e.g. 404s or 422s, as they are usually not relevant for error tracking. This can be done with a bit of custom logic - by checking if the error is an H3Error, and if so, if the status code is one of the exceptions we don't want to track:

// On the top of the file, import H3Error!
import { H3Error } from 'h3'

// Inside the plugin, after initializing sentry
nitroApp.hooks.hook('error', (error) => {
  // Do not handle 404s and 422s
  if (error instanceof H3Error) {
    if (error.statusCode === 404 || error.statusCode === 422) {
      return
    }
  }

  Sentry.captureException(error)
})

Sharing Sentry with the event context

After the initial setup is done, we also want to ensure that we can use Sentry in our API routes, e.g. to attach a user, send messages, and whatever your use case is. The best way is attaching Sentry to the event context, so we can access it from any event handler. We can do this for every request by using the

nitroApp.hooks.hook('request', (event) => {
  event.context.$sentry = Sentry
})

Okay, we are not fully done yet if we use TypeScript because the event context doesn't know about the

import type { Sentry } from '@sentry/node'

declare module 'h3' {
  interface H3EventContext {
    $sentry?: Sentry
  }
}

It might be a bit confusing that you have to augment the

Now we can do something like this in any event handler:

export default defineApiHandler(async (event) => {
  const sentry = event.context.$sentry
  if(sentry) {
    // Do something with Sentry if exists
    // e.g. 
    sentry.setUser({/*...*/})
  }
})

Closing Sentry on shutdown

An often forgotten task is cleaning up! We want to ensure that Sentry is gracefully shut down when the Nitro server stops. We can achieve this by using the

nitroApp.hooks.hookOnce('close', async () => {
  await Sentry.close(2000)
})

And that's it! Our nitro integration is ready. Now, up to the client side.

Nuxt integration - Setting up the client side

The client side is also not that complicated. Technically, we have to do what we did in the Nitro plugin, but on the client side. We will use a client-only Nuxt plugin for this. In there, we also initialize Sentry based on our

Let's not forget to add the Sentry vue plugin to our dependencies before via

Then, we provide the vue app via

import * as Sentry from '@sentry/vue'

export default defineNuxtPlugin((nuxtApp) => {
  const router = useRouter()
  const { public: { sentry } } = useRuntimeConfig()

  if (!sentry.dsn) {
    return
  }

  Sentry.init({
    app: nuxtApp.vueApp,
    dsn: sentry.dsn,
    environment: sentry.environment,
    integrations: [
      Sentry.browserTracingIntegration({ router }), 
      Sentry.replayIntegration({
        maskAllText: false,
        blockAllMedia: false,
      }),
    ],

    // Configure this whole part as you need it!

    tracesSampleRate: 0.2, // Change in prod

    // Set `tracePropagationTargets` to control for which URLs distributed tracing should be enabled
    tracePropagationTargets: ['localhost', 'https://your-server.com'],

    replaysSessionSampleRate: 1.0, // Change in prod
    replaysOnErrorSampleRate: 1.0, // Change in prod if necessary
  })
})

From here, error tracking works out of the box. Of course, you can build your own composable exposing

Conclusion

We did it! Together, we set up a very simple Sentry integration for our Nuxt 3 project, only by relying on Nuxt, Nitro, and Sentry. Don't forget to check out the full result on GitHub.

I hope this article helped you understand why module development can be tricky, might take a little longer than just adding your own implementation, and what pros and cons owning an implementation brings with it. Also, I hope now your Sentry setup is up and running.

If you have any questions, feel free to reach out to me as usual! And please don't forget to share this article with your friends and colleagues if you found it helpful.

Happy hacking!

This is the second post on my new blog and it feels so good to be back at writing! Thanks a lot for all the positive feedback on my previous article. Also, don't forget to join the big open source launch party this Thursday (Sept 28th, 2023) on my Twitch channel, starting 15:30! But now back to the topic!

In Nuxt 2, you could already selectively enable SSR or SPA mode based on the page URL with a little trick. However, this approach doesn't work anymore in Nuxt 3. But don't worry, in this article, we will cover three different ways to selectively switch SSR on or off for your site!

Prelude - The <ClientOnly> component

A common solution to render parts of your application only on the client is the

<ClientOnly>
  This content will not be rendered on the server side
</ClientOnly>

You can even set a few options on the component to control the behavior, such as the content for the server-side fallback, either via props (

<ClientOnly>
  This content will not be rendered on the server side
  <template #fallback>
    This content will be rendered on the server side, ideally this should be some loading state
  </template>
</ClientOnly>

While using the

Solution 1 -

routeRules

Since the introduction of

export default defineNuxtConfig({
  routeRules: {
    '/spa-route-rule': { ssr: false }
  }
})

This also works for all routes that match a certain pattern, using a wildcard. Then you also have to add the index URL manually though:

export default defineNuxtConfig({
  routeRules: {
    '/spa-route-rule': { ssr: false },
    '/spa-route-rule/**': { ssr: false }
  }
})

This is the recommended approach. But sometimes, just choosing the route might not be enough!

Solution 2 - The experimental

x-nuxt-no-ssr

header

Another way to disable SSR, this time for the whole request and not bound to a path, is to set the

export default defineNuxtConfig({
  experimental: {
    respectNoSSRHeader: true,
  },
})

Using the header is a rather uncommon solution, but it might be useful for debugging a staging environment. Also, be aware that this is an experimental feature and could be adapted/changed in the future without a major version bump. As a last note: You might not want to enable this feature in production, as it could be used to disable SSR for all pages.

Solution 3 - A custom Nitro middleware

If you really want some fine-grained control over the SSR/SPA mode, you can always write your own Nitro middleware, very similar to the

export default defineEventHandler((event) => {
  if (!event.path.includes('/spa-header-custom')) {
    return
  }
  event.context.nuxt = event.context.nuxt || {}
  event.context.nuxt.noSSR = true
})

Be aware that this approach relies on internals, though breaking changes are unlikely to happen here. Also, the

Conclusion

There are many ways to selectively enable or disable SSR in your Nuxt 3 application. And you can see them all in use in this StackBlitz.

The recommended way is to use

I hope this article was helpful to you. If you have any questions, feel free to reach out to me on any of the social networks below. And as usual, please share this article with your friends and colleagues if you liked it. Happy hacking!

This article is written for Vue 3 and Nuxt 3.

If you are looking for the Nuxt 2/Vue 2 version of this article, please follow this link to the older Nuxt 2 / Vue 2 version.

When using Vue or Nuxt, we have are spoilt for choice when it comes to asset handling: Do we put them in the

Read further to find out why loading static assets from neither folder is no problem at all and which pattern to use when the asset path or name must be dynamic. In case you want to skip the internals and explanations, you can do so and go straight to the solution, but you will miss out some in-depth information!

Static images

Let's define our experimental use case first: Imagine a component called

The only thing our components needs is a template with a single image tag using the desired path as

When using the

<img src="@/assets/doggos/riley.jpg">

<img src="../assets/doggos/riley.jpg">

In case you are using the

<img src="/doggos/riley.jpg">

So far so good -- but what if we have a list of cute puppies and the user can decide which image to display on the page?

The

public

folder strategy

One suitable way is to put all the images in the

Let's say we load the dynamic image source via Vue’s binding system. Imagine we have a small component set up where we can select a puppy:

<script setup lang="ts">
const dogNames = ['Riley', 'Annie', 'Marvin'];
const selectedDog = ref('');
</script>

<template>
  <div>
    <label v-for="doggo in dogNames" :key="doggo" style="margin-right: 2rem">
      <input type="radio" :value="doggo" v-model="selectedDog" />
      {{ doggo }}
    </label>
    <img :src="`/doggos/${selectedDog.toLowerCase()}.jpg`" width="500" :alt="selectedDog" />
  </div>
</template>

All that is left to do is to retrieve the correct image for the

<img :src="`/doggos/${selectedDog.toLowerCase()}.jpg`" :alt="selectedDog">

And it works! We can now select a puppy and the image will be displayed. Open this CodeSandbox to see the code up and running.

This approach has a few downsides though:

• Caching: The image will be cached by the browser, so if we want to change the image, we have to change the file name as well. This is not optimal, especially if we want to use the same image in multiple places.
• Image optimization: The image will not be optimized by Vite plugins or similar, so we have to do it manually.
• Image size: The image will be loaded in its original size, which can be a problem for mobile users with a slow connection if the image is big.

Let's take a look how the approach for the

The

assets

folder strategy

Alright, let's take the code from above as base. As a naive approach, why not just replace the paths using the path to assets instead?

Naive approach

<img :src="`../assets/doggos/${selectedDog.toLowerCase()}.jpg`" :alt="selectedDog">

Let’s add that line quickly and see what happens when we push the button mapped to Riley…

Bummer, a broken image and only the alt tag! Let us take a look at the DOM. It contains the following image tag:

<img src="../assets/doggos/riley.jpg" alt="Riley">

It means that the asset path hasn’t been replaced. It is the string that the expression in our template string above evaluates to, but no bundler magic happens.

So, what now?

Bundler magic

The solution to this problem depends on the bundler you are using. If you are using Webpack with Vue 3, which is rather uncommon, you can follow the solution from the Vue 2 / Nuxt 2 post.

We will focus on Vite here, as it is the default bundler for Vue 3 and Nuxt 3.

As Vite does not support

The

import.meta.glob

trick

Instead of

Let's start simple and grab all

<script setup lang="ts">

const glob = import.meta.glob('@/assets/doggos/*.jpg', { eager: true })
</script>

If we stringify the result, we can see that we get an object with the local image path as key and the image path in a nested object as value. The

{
  "/assets/doggos/annie.jpg": {
    "default": "/_nuxt/assets/doggos/annie.jpg"
  },
  "/assets/doggos/marvin.jpg": {
    "default": "/_nuxt/assets/doggos/marvin.jpg"
  },
  "/assets/doggos/riley.jpg": {
    "default": "/_nuxt/assets/doggos/riley.jpg"
  }
}

This is close to what we want, so we need to do some transformations. We will take the entries of the object and map over them, eventually assembling them into an object again. In the

<script setup lang="ts">
import { filename } from 'pathe/utils'

const glob = import.meta.glob('@/assets/doggos/*.jpg', { eager: true })
const images = Object.fromEntries(
  Object.entries(glob).map(([key, value]) => [filename(key), value.default])
)
</script>

This is also the suggested workaround from Daniel Roe for achieving a "require-like" behavior with Vite.

Now, let's put it all together!

<script setup lang="ts">
import { filename } from 'pathe/utils'
const dogNames = ['Riley', 'Annie', 'Marvin'];
const selectedDog = ref('');

const glob = import.meta.glob('@/assets/doggos/*.jpg', { eager: true })
const images = Object.fromEntries(
  Object.entries(glob).map(([key, value]) => [filename(key), value.default])
)
</script>

<template>
  <div>
    <label v-for="doggo in dogNames" :key="doggo" style="margin-right: 2rem">
      <input type="radio" :value="doggo" v-model="selectedDog" />
      {{ doggo }}
    </label>
    <img
      :src="images[`${selectedDog.toLowerCase()}`]"
      width="500"
      :alt="selectedDog"
    />
  </div>
</template>

To see the code in action, you can also check out the StackBlitz.

And we achieve a similar result to the

• Caching: As vite will add a hash to the name of each image, we can change the image without changing the file name and the cache will be busted.
• Image optimization: The image can be optimized by vite plugins like
  vite-plugin-image-optimizer
  , so we don't have to do it manually.

But it has also some downsides:

• Image name: The image name will be changed, so linking it outside of your app will be nearly impossible
• Perf-overhead: Importing the modules via glob add some overhead to the computed time, which is not optimal.

The solution

Both approaches have their pros and cons as you can see. I'd recommend using the

The

Conclusion

If you want to replicate a webpack-like behavior in Vite, loading images with dynamic paths is not as easy as it might seem at first glance. But with the help of

Still have questions? No problem, drop me a Tweet (or however it is called now) at @TheAlexLichter, reach out on the Vue/Nuxt Discord or write me a mail (blog at lichter dot io).

I hope you enjoyed this article and learned something new! If you did, please consider sharing it with your friends and colleagues. Thanks for reading!

And I’m sure that you’ve asked yourself: How to change this page? You likely want to brand this error page similar to your client side error pages, so that your users aren’t as confused whenever a server-side error occurs and have info available how to proceed further.

Testing the server-side error page

Let’s create a new dummy page called

export default {
  asyncData() {
    throw new Error(':(')
  }
}

To see the page you have to boot up the project in production mode. Otherwise

Okay… changing time!

Changing text

Do you like the style and only want to change the text there? No problem! You can do this through your

export default {
  messages: {
      loading: 'Loading...',
      error_404: 'This page could not be found',
      server_error: 'Server error',
      nuxtjs: 'Nuxt.js',
      back_to_home: 'Back to the home page',
      server_error_details:
        'An error occurred in the application and your page could not be served. If you are the application owner, check your logs for details.',
      client_error: 'Error',
      client_error_details:
        'An error occurred while rendering the page. Check developer tools console for details.'
  }
}

I’ve highlighted the lines that influence the text of the default server error page. Let’s change them and see what happens!

export default {
  messages: {
      server_error: 'Oh no! Server error',
      nuxtjs: 'Is this Nuxt.js?',
      back_to_home: 'Cmon, back home!',
      server_error_details: 'Uh uh :| Server errorrrrr',
  }
}

Looks great so far! But as you may think, this isn’t everything ?

Completely replace the error page

Surprise folks! Similar to an own

All you have to do is to create a folder called

I’ll add a small unstyled piece of HTML for demo purposes.

<h1>Oh No :(</h1>

There we go!

Conclusion

It was easier than you thought, wasn’t it? Now it’s your turn! ? I’d love to see some nice error page designs, so if you built a great one and want to share it be sure to send it to me as well.

As usual, I hope the article helped you out somehow. If you’ve spotted typos, wrong code or have questions, feedback or ideas, please send me a message!

You can reach out on Twitter (@TheAlexLichter) or through email (blog at lichter dot io). Stay tuned for more content ?

In this article we will take a look at possible reasons, explain what the error means and furthermore go through solutions and debugging opportunities:

What is Vue Hydration?

When I heard the term Hydration for the first time, it felt very abstract to me and I couldn’t think of the meaning. Eventually, I realized it’s not as complex as the term sounds at first:

Hydration is the process where Vue is transforming server-side rendered markup and makes it reactive so it can reflect dynamic changes from Vue.

If Vue is expecting a different markup compared to the rendered HTML, the hydration will fail (also called “Vue will bail hydration”). You can read more in the official Vue SSR docs about it.

How to recognize failing hydration

We now know what hydration is and when it fails. But how can we developers discover that hydration did not work as expected? Well, there are two error messages which definitely point to failing hydration but both come with constraints.

The first one appears only in development regardless of the mode:

Parent:  <div class="container"> client-hook-3.js:1:16358
Mismatching childNodes vs. VNodes: NodeList(3) [ p, p, p ]  Array [ {…} ]
    
[Vue warn]: The client-side rendered virtual DOM tree is not matching server-rendered content.
This is likely caused by incorrect HTML markup, for example nesting block-level elements inside <p>, or missing <tbody>. 
Bailing hydration and performing full client-side render.

The second error message shows up only in production and when using static site generation:

Error: [nuxt] Error while mounting app: HierarchyRequestError: Failed to execute 'appendChild' on 'Node':
This node type does not support this method. at some-file.js:1

As we know, hydration only happens when the page is rendered by the server in the first place, so usually only on the initial request to your application.

This makes it even more difficult to spot hydration problems because they are not visible when navigating between pages through a

Thus, hydration errors are sometimes only discovered on the staging system or worse - only in production. And in rare case, there isn’t even a console error logged but some components simply stop working.

Common Causes

Now that we know how to spot failing hydration we will look into typical causes for Vue to bail hydration. We can’t cover every possible reason because they vary a lot and depend a lot on your code.

For the upcoming chapters, every time the server or server-side is mentioned, it is relevant for both scenarios - dynamic SSR and static site generation - as both have technically a server rendering content (unless stated otherwise).

Invalid HTML

Invalid HTML is the first thing you should check for when the hydration error pops up. This is also what one of the error messages suggest.

This is likely caused by incorrect HTML markup, for example nesting block-level elements inside <p>, or missing <tbody>

Unfortunately, invalid HTML is often not the reason for the failing hydration. Nevertheless, you should double-check your markup. Also make sure you check your minification settings, as aggressive HTML minification could lead to invalid HTML.If you have user-generated output or content coming from a CMS, it’s worth verifying that this content is valid HTML too. Finally, also third-party plugins or services could influence and manipulate the HTML. A common example for the latter is Cloudflare, when you’ve enabled their services like HTML minification, the “Rocket loader” or other features altering the page content.

I’ve created a simple example codesandbox containing invalid HTML and triggering a hydration failure.

Scripts altering the HTML

Talking about scripts: If you have added third party javascript files to your Vue application, these can also alter the HTML (e.g. by embedding a form) before Vue can take over and hydrate the HTML coming from the server.

Different state on the server and client

Having a different state on the server and client is the most common reason for hydration. As usual, reasons for the inconsistencies can vary a lot.

Dates, Timestamps, and Randomizing

When you include dates or timestamps on your website you should be careful and make them as static as possible, especially if your site is generated statically. If the client evaluates an expression like

export const deterministicRotate = (arr) => {
  if (arr.length <= 1) {
    return arr
  }
  const rotations = (new Date()).getMinutes() % arr.length

  return rotations ? arr : arr.reverse()
}

The plan was to reverse the array if the minute where the user opened the page is odd. That worked very well when using dynamic SSR. But when switching to a JAMstack site which is statically generated, the feature turned into a bug. You can try it out by clicking on the link above and refresh after a minute. What happens is that names and text of the people are swapped correctly but the images stay the same. Horrible! And it happens because of the date mismatch between the server and the client. After removing the deterministic shuffle code everything worked again as usual.

Authentication

Another common reason for inconsistencies is user authentication. This applies to both, dynamic SSR and static site generation.

When storing the authentication state only on the client side (e.g. in the localStorage), the server “does not know about the authentication”. This will inevitably lead to hydration issues because the server and client information is fundamentally different when you are logged in. Thus, you should not render any authentication-related component on the server-side if the server is not aware of the authentication state or your are generating your page statically.

You may wonder why it always applies to static sites: Because when you generate your site, it’s HTML and serialized code is “stateless”. We can’t take the “logged in user state” into account during the build phase. This means you have to exclude all authentication-related components from rendering on the server.

And there is still more

Besides these two scenarios, there are even more edge cases that could hit you and cause inconsistencies. Even if it’s not listed here, we will solve the hydration error! At first, we will narrow it down to the DOM element causing the problem.

Solving the hydration failure

Find the element causing the hydration error

To narrow down the problem to a specific component or DOM element we can use the devtools of your favorite browser!

Setting up the debuggers

1. Ensure you are in dev mode
2. Open up the DevTools (usually by pushing F12)
3. Trigger a hydration warning (usually by reloading the site)
4. Unfold the
   [Vue Warn] The client side ...
   error message to see the stack trace (depending on the browser, also unfold the “VueJS” list popping up)
5. Click on one of the
   hydrate
   calls. This will open up the source code of Vue’s hydration function.
6. Now, set a debugger whenever the function returns
   false
   . By the time of writing, this happens three times:

if (process.env.NODE_ENV !== 'production') {
  if (!assertNodeMatch(elm, vnode, inVPre)) {
      return false //HERE
  }
}


    if (process.env.NODE_ENV !== 'production' &&
          typeof console !== 'undefined' &&
          !hydrationBailed
    ) {
        hydrationBailed = true;
        console.warn('Parent: ', elm);
        console.warn('server innerHTML: ', i);
        console.warn('client innerHTML: ', elm.innerHTML);
    }
  return false //HERE
}


  if (process.env.NODE_ENV !== 'production' &&
      typeof console !== 'undefined' &&
      !hydrationBailed
  ) {
    hydrationBailed = true;
    console.warn('Parent: ', elm);
    console.warn('Mismatching childNodes vs. VNodes: ', elm.childNodes, children);
  }
  return false //HERE
}

Time to debug

1. Last but not least, let the hydration error appear again. Often, this is possible by reloading the page again but sometimes it’s more difficult.
2. You now see that one of our breakpoints was triggered and script execution is stopped . Now open the DevTool’s console and write
   elm
   to get the DOM element where hydration fails. With the DOM element, you 1should be able to trace back the hydration error to one of your Vue components
3. Continue with the next steps

PS: This is an adapted workflow of this StackOverflow answer by user budden73.

Ensure your HTML is valid

Now that you found the code causing the problem, the first thing you should do is to verify that your markup (possibly coming from an API) is valid. Code like

Be aware, that

Resolving state inconsistencies between server and client

During the debugging, you were able to take a look at the results from the server and the (re-rendered) client-side part. If these are different, you can take a look at how you fetch data and what you render on the server/client-side. One common issue is authentication for static pages. Because the HTML generated at build time is stateless, thus not knowing about any authentication state, all parts of your application that are related to authentication should only be rendered on the client-side. Otherwise, the client, which has the authentication status of the user, expects different HTML from the server because the user is logged in. Then there is only one option left…

Final escape hatch:

<ClientOnly>

The last option to resolve hydration errors is to avoid them at all for the component. This is mandatory for authentication-related components on statically generated pages and sometimes also for components delivering content you can’t change but must embed, e.g. from 3rd party applications.

As we have learned at the beginning of the post, hydration only happens when the component is rendered on both, client and server side. To avoid hydration, we avoid rendering the component on the server-side by wrapping it in a

The only drawback: The component is not included in the HTML returned by the server and not helpful for SEO.

Conclusion

Let’s wrap it up! Now you know more about:

• What hydration is and what it does
• How hydration can fail and how to spot hydration errors
• Common reasons for bailed hydration
• How to debug your hydration error and fix your application

I hope that this post was insightful and you’ve learned a thing or two. Are you experiencing causes for hydration errors I haven’t described here or did I miss a common reason? Feel free to message me on Twitter or by mail.

And as usual - I’d be glad if you could spread the word and share the blog post with colleagues ?

See you around!

This article is written for Vue 2 and Nuxt 2.

If you are looking for the Nuxt 3/Vue 3 version of this article, please follow this link to the updated Nuxt 3 / Vue 3 version.

Importing images from the

Static images

Imagine a component called Doggos that should show an image of a cute puppy. I mean, we all love puppies, don’t we?

The only thing our components needs is a template with a single image tag pointing to the path. Ideally by utilizing an alias:

<img src="@/assets/doggos/riley.jpg">

(with an alias for the source directory)

<img src="../assets/doggos/riley.jpg">

(relative path without alias)

But what if we have a list of cute puppies and the user can decide which image to display on the page?

The typical first idea

A common attempt to load a dynamic image source in Vue or Nuxt is to utilize Vue’s binding system. Imagine we have a small component set up where we can select a puppy:

<template>
  <div>
    <div>
      <label v-for="doggo in dogNames" :key="doggo" style="margin-right: 2rem">
        <input type="radio" :value="doggo" v-model="selectedDog">
        {{ doggo }}
      </label>
    </div>
    <!-- Here should be the dog image -->
  </div>
</template>

<script>

export default {
  data () {
    return {
      selectedDog: "",
      dogNames: ["Riley", "Annie", "Marvin"]
    }
  }
}
</script>

All that is left to do is to retrieve the correct image for the

<img :src="`../assets/doggos/${selectedDog.toLowerCase()}.jpg`" :alt="selectedDog">

Let’s add that line quickly and see what happens when we push the button mapped to Riley…

Bummer, a broken image and only the alt tag! Let us take a look at the DOM. It contains the following image tag:

<img src="../assets/doggos/riley.jpg" alt="Riley">

What does that mean?

It means that the asset path hasn’t been replaced. It is the string that the expression in our template string above evaluates to.

The

public

/

static

folder as a possible workaround (usually not recommended)

If we move our dog images into the

Content in the

While it is sometimes necessary, for example for preview images which need a fixed URL, it brings no benefits for our use case. What if we want to swap out the image for Marvin when he grew up a little? We might hit caching issues. Let’s dig a bit deeper and find the root cause instead of going for the “quick fix” which will consume more time on the long run. You likely know that pattern

Vue and Webpack asset handling

All single file components (with the

Webpack will import static assets like

After being processed, our initial image tag example

createElement('img', {
  attrs: {
    src: require('../assets/doggos/riley.jpg'), // this is now a module request
    alt: 'Riley'
    }
})

The image path has now been replaced with a Webpack module request. This works fine for static assets because their paths are known at build time. When it comes to dynamic content, including Vue’s

What can we do then?

If we take a closer look at the compiled code of our simple image tag with the static source attribute, we can find out what we need to solve the issue.

The solution

To tell Webpack which images should be loaded, we have to issue a module request on our own. This is done by calling

<img :src="require(`../assets/doggos/${selectedDog.toLowerCase()}.jpg`)" :alt="selectedDog">

Instead of binding the

We can now extract that nasty part into an own computed property for better readability.

export default {
  // ...
  computed: {
    dogImage () {
      if (!this.selectedDog) {
        return
      }

      const fileName = this.selectedDog.toLowerCase()

      return require(`../assets/doggos/${fileName}.jpg`) // the module request
    }
  }
}

It is very important that you are as strict as possible when it comes to the possible image file name. If we use the code from above, the final build will include every image with a

That happens because webpack cannot guess which of the images will actually be used at runtime, so it includes them all to prevent errors. The less strict you are, the more files will match and will be included in the bundle by webpack, leading to a larger bundle size.

We solved it! With

Bonus - using srcset

Nowadays, responsive images are a must-have on your website. They don’t only save bandwidth but also time of your users and are good for SEO. But how do we use

Almost the same way we do with the normal

<template>
  <img :srcset="this.dogSourceset" sizes="(max-width: 600px) 480px, 800px" :src="dogImage">
</template>

<script>
export default {
  // ...
  computed: {
    dogSourceset () {
        const baseName = this.selectedDog.toLowerCase()
        return `${require(`@/assets/img/${this.baseName}_480.jpg`)} 480w, ${require(`@/assets/img/${this.baseName}_800.jpg`)} 800w`
    },
    dogImage () { /* ... */ }
  }
}
</script>

There we go! A working image with srcset definition. And that’s not the end: You could even go further and create

Conclusion

Loading images with dynamic paths isn’t that difficult if one knows what’s going on behind the scenes. By using

If you want some further reading, I suggest checking out the vue-loader docs and the Webpack documentation.

Still have questions? No problem, tweet me at @TheAlexLichter, reach out on the Vue/Nuxt Discord or write me a mail (blog at lichter dot io).

I really hope you’ve enjoyed that article! If you know some people who also have trouble with dynamic image loading in Vue or Nuxt, I’d gladly ask you to spread the word and help them out!

It all started with my portfolio which consists of one larger page and two pages for privacy and legal notice. All three pages have actually no dynamic data involved (as you can see in the source code). The text, the images and everything else are completely hardcoded. Last year, the page was served from one of my Virtual Private Servers (VPS) by always running Node.js server. The only purpose of it was to respond with the same content again and again.

At some point, I thought that there must be a better way, so I started using Nuxt.js as Static Site Generator. Now no Node server was involved anymore, only plain HTML files that were served by the VPS. Not too bad, but… why do I need a server at all for managing a simple static page? Correct, I do not! But more about that in a second.

Jamstack?

So, the title of the article is “Going Jamstack with Netlify and Nuxt 2”. But you might ask yourself: “What the heck is Jamstack?”. Fair enough! Jamstack is a new and modern way of web development based on Javascript, APIs and Markup.

A Jamstack project will be pre-built at deploy time, mostly with the help of a Static Site Generator. The markup itself is static and won’t be dynamically created or modified by the server. All the dynamics will be handled by client-side Javascript, and it doesn’t matter which framework or library you use for that.

Last but not least: All page interactions, like submitting forms or retrieving more content, are handled through APIs that are called via HTTP(S). Most of the time, microservice-based APIs or serverless functions are used in combination with the Jamstack approach.

Further information about Jamstack can be found on the official Jamstack.org page.

Why going Jamstack

Okay, so far so good. Now you might have another question: “Why should I go for Jamstack?”. There are four main reasons in my opinion.

Simplicity

As mentioned briefly in the introduction, you don’t need a server anymore to host your website. Instead, you can use platforms like GitHub Pages or Netlify and let them grapple with the underlying infrastructure and maintenance. No more server management!

It gets even better: No more difficult deploys as well. As the markup will be pre-built you could set up webhooks to re-build your website when data changes, e.g. when you update a blog post.

Security

Guess how often websites are being targeted by hackers? A Forbes article from 2013 shows that back then, more than 30,000 Wordpress pages were hacked every day, which is an insane number. With Jamstack, you decrease your attack surfaces a lot because your site isn’t served by a server anymore. Sure, you still have the APIs as possible targets but as they are decoupled and isolated from each other, at least most of the time, it’ll give the attacker a harder time, too.

No system is 100% secure but with Jamstack, things get less attractive for potential adversaries by default. And even if you are using a content management system like Wordpress through an API to populate your upcoming website: Ideally^1 you wouldn’t expose your API at all because you could prefetch all the data needed and persist them as JSON files.

Performance

As your entire page is purely consisting of static assets like HTML documents, Javascript files and images, you should put all your files on a Content Delivery Network (CDN), so they are present on servers all across the world. This will reduce the “Time to first Byte” for your users because they don’t have to connect to the server your page is hosted, which could be at the other end of the world, or at least in another continent. Instead, the users will retrieve the data from their nearest CDN server. Netlify has their own CDN in place, while Cloudflare is another great CDN I’m using.

Also, because your page is re-built every time you change something, you can always invalidate the cache directly. This is a huge win because cache-invalidation is actually a hard thing as some of you probably experienced already.

Last but not least, don’t forget one thing: Static HTML is faster than, or at least as fast as, dynamic HTML returned from your server.

Cost

Jamstack also means cutting costs in most of the cases. No server means no server fees and also no server management needed. If you host your page, Netlify, this is free for a 100GB bandwidth soft limit per month. Also you can possibly reduce the resources needed for your APIs by transforming them into serverless functions.

Nuxt as Static Site Generator

Most of you might know Nuxt.js as “the framework on top of Vue that can do server-side rendering”. For those of you who don’t know Nuxt.js at all yet, make sure to check out the official website. But Nuxt.js is way more than that.

Sure, server-side rendering (SSR), is one part of it, but being a Static Site Generator is another. That means, it will take a “snapshot” of your pages and export them as HTML. I often describe it as the best of both worlds between a traditional single page application and a server-side-rendered project. While keeping the search engine optimization benefits provided by the HTML, you don’t need a Nuxt.js instance running all the time.

To generate the page, all you have to do is to run

Netlify

Before writing about how I moved three of my websites over to Netlify and Jamstack and what I experienced during that process, I want to give a rough overview of what Netlify actually is, what they are doing and why I chose them.

Netlify is an all-in-one platform for hosting static websites and a pioneer of the Jamstack tech. With Netlify, you can deploy your page in under a minute. No joke! They provide automatic deployments after commits to your Git repository or via webhooks, deploy previews for Pull Requests, form handling, serverless functions, A/B testing through different branches, one-click SSL, a CDN, a managed DNS and that all with a generous free tier.

Experience reports

lichter.io

My portfolio page was the first one I moved to Jamstack, as said in the beginning, and moving it to Netlify was a breeze. I switched to the

thanks.lichter.io

With my donation page it was not that easy because I had to think about how to manage the “donate” feature (using the Stripe API). Setting up a server just for that one function would be possible but a waste of resources. Why not giving Netlify Functions, a convenient wrapper around AWS Lambdas, a shot? As the code for the donation logic itself was always kind of “isolated”, transforming it into a serverless function was no big deal. After the “standard” procedure, converting the function, changing the URLs and testing it, thanks.lichter.io was ready as well.

blog.lichter.io

The last experience report is about this blog. When I wrote the first lines of code for it I already puzzled my head over which approach I should take. Markdown files and a static blog or powered by an API? I decided for the latter because I wanted to have the option for more dynamics, like showing a “Trending Posts” section based on Google Analytics data. I built the API with Laravel (yes, PHP) and the frontend with Nuxt.js as you could already guess. The blog ran on server-side rendered for a long time because the Markdown coming from the API had to be parsed “on the fly”.

But the more I thought about in the last weeks, the more I was convinced that a Jamstack approach would work here as well. So I started to fiddle around. The transition took a bit longer than for the other pages but that was because of the size of the project and the dynamic data. What I did, in the end, was to set up webhooks that triggered a page rebuild when changing one of my articles or updating trending posts. Furthermore, I had to change my pagination from a query string based approach (

When not to go for Jamstack

I haven’t ported all my projects to the Jamstack approach. Some of them, including Brotli.pro, are relying too much on dynamic data and their near-real-time availability but still need the SEO benefits. In case you have a page where data could change every few seconds (or even faster) and where you need good SEO, I would not suggest going for Jamstack for that particular project. This does depend heavily on the situation and use case though.

Netlify features I’m missing and why I still use Cloudflare

Though I switched over to Netlify, I still use Cloudflare in front of most of my pages. The Netlify CDN is excellent but Cloudflare provides a few features that Netlify doesn’t have at the moment and that I have to rely on.

Brotli

Speaking of Brotli.pro, Netlify does not support the Brotli encoding yet. This feature is planned and will come to Netlify in the future but there is no ETA for it yet.

PS: If you don’t know what Brotli is, check out the info page

Analytics

Update: Netlify Analytics is available since a few months as a paid feature.

While more and more people are using anti-tracking measurements and ad blockers, it’s hard to get a unique visitors number close to reality when I’d only rely on client-side analytics. Cloudflare provides them and also gives more info regarding the country of the user. Whether these numbers are “more accurate” or including bots and crawlers, I’d love to see some analytics coming for Netlify.

Essentially Broken HTTP2

While this is a thing that affects the majority of the CDNs right now, it’s still something I want to list. If you did not know yet, HTTP2 is essentially broken on many CDNs, including Netlify (to the time of writing). As this issue is a bit more complex, I won’t go into detail here. More information can be found on this repository

Conclusion

Jamstack, especially in combination with a custom API or a headless CMS** is terrific. Easy deployments, no servers to worry about and a free performance boost. Thanks to Netlify for investing time and resources in this whole architecture and style. Netlify itself as a platform is steadily growing. The current features are solid and make the whole process of getting up and running with Jamstack very friction-less. A few things are missing here and there but they are mostly related to convenience or are planned in the future.

If you are building your next project, be it a side project or something for a client, you should consider taking this way. And if you are looking for a neat Static Site Generator, you know my choice now ?

Thanks for reading!

* This isn’t possible in Nuxt (without the help of modules) at the moment but we are working on it.

** Whoops, haven’t mentioned them a lot in this article. Maybe in a future one 😉

This blog post will cover my take on that question. Disclaimer: My take does not mean “always the right way”. It’s just what I found out to be the best way for me ☺️ Also be aware that this post is not about Nuxt 3.

Three common approaches

There are three main approaches when it comes to using an API with Nuxt.js. Before telling you my opinion I’ll go through each of them.

• Leveraging Nuxt’s
  serverMiddleware
• Using Nuxt programmatically
• Working with a standalone API

serverMiddleware

Nuxt.js provides so-called

Another use case would be a server-side logger which is closer to the “middleware” term you might be familiar with.

You don’t need another server running for it and can combine Nuxt and your features in one instance.

A small example (play around with it here):

export default {
  path: '/test',
  handler(req, res) {
    res.end('Everything ok!')
  }
}

export default {
  serverMiddleware: [
    '~/serverMiddleware/ok'
  ]
}

Hitting

Using Nuxt programmatically

In the

If you already have an Express instance running and need Nuxt only for parts of your routes (for example while transitioning from your old stack) this seems like a compelling idea!

Nuxt will be used as a middleware in such cases. Below is an example with Express:

const express = require('express')
const consola = require('consola')
const { Nuxt, Builder } = require('nuxt')
const app = express()
const host = process.env.HOST || '127.0.0.1'
const port = process.env.PORT || 3000

app.set('port', port)

// Import and Set Nuxt.js options
let config = require('../nuxt.config.js')
config.dev = !(process.env.NODE_ENV === 'production')

async function start() {
  // Init Nuxt.js
  const nuxt = new Nuxt(config)

  // Build only in dev mode
  if (config.dev) {
    const builder = new Builder(nuxt)
    await builder.build()
  }

  // Give nuxt middleware to express
  app.use(nuxt.render)

  // Listen the server
  app.listen(port, host)
  consola.ready({
    message: `Server listening on http://${host}:${port}`,
    badge: true
  })
}
start()

Working with a standalone API

In case you are using another programming language for you API (say PHP, Python or Go), the only option you have is to separate the API and the Nuxt instance and to call your API via

My take on it

Okay, there we go! My workflow and practices with APIs depend largely on:

• Will the page be statically generated or not?
• Is the project small or rather larger (and how will this probably change in the future)?
• Am I building a proof of concept or similar?
• How is the actual API I want to use / I’ve built being implemented?

Small APIs

Static pages

While 3 months ago, most of my pages were powered by Nuxt’s dynamic

When using static sites though, the API is lightweight most of the time. In such cases, I prefer to use serverless functions to isolate my API and remove the need for a server completely. A great example is a contact form endpoint, which was previously powered through Nuxt’s serverMiddleware but is now decoupled as a serverless function.

Apps with server-side rendering

For apps that are highly dynamic (like brotli.pro) but have a small number of API endpoints or for projects that are either proof of concepts or small-scaled I tend to use Nuxt’s built-in

Medium-sized APIs and above

Most of my projects involving more complex or a non-trivial amount of API endpoints are built on

I see some huge benefits in using this approach:

• No single point of failure - Have the API and Nuxt instance on two different servers, ideally with a backup one for each
• Separation of Concerns - The Nuxt instance does not “own” the business logic and DB access (and vice-versa)
• Easier Scaling - For the API you can use functions. Even if you don’t, you can put up load balancers and add more servers more easily
• Testing each side standalone
• Language-agnostic - Write your API in Python, Go, PHP, Elixir, Brainf*ck, …

When using a standalone API (and having control over the server), please do not forget to set up a reverse-proxy, like NGINX, in front of your Nuxt instance and API, so you can:

• proxy the API to
  /api
  or whatever route you want to avoid CORS issues (use the official proxy module in dev mode to mimic the behavior)
• add compression and caching headers
• enable HTTPS, HTTP2, and HTTPS-only-connections

(and so on). As I’m hosting all my SSR-based apps and APIs on my own servers, this is a crucial point for me and improves perf a lot if done right.

The missing approach

Some of you might have noticed that I use only two out of the three ways I introduced. The one that is missing is using Nuxt programmatically. But why is that the case?

Well, because I do not see any advantage in it. Quite the opposite! To me, it feels a bit awkward mixing Nuxt and a framework like Express. For example, because you can’t use the ESM syntax (import/export) in your

Especially newcomers could easily come to wrong conclusions (like that Express will handle all route calls, even when the app is past the SSR step and behaves like a traditional SPA). Also, there is no “common interface” to communicate between the underlying framework and Nuxt (which doesn’t mean it’s impossible).

There are some exceptions where this combination does make, for example when using Nuxt.js with AWS or in another serverless context. If you know more, please tweet me!

Conclusion

You can’t go wrong with using a standalone API. It could mean a bit more effort to configure all the things but it will be worth it in the long run. If you need a way to bootstrap your app fast (eg. working on an MVP), and want to use Javascript in the backend too, utilize Nuxt’s

But as usual, I suggest try out all approaches once to see what fits best for you. If you’ve found out the approach you like most, feel free to check out how to organize APIs in Nuxt.js properly!

Did I miss something or do you have a question? Tweet me at @TheAlexLichter, reach out on the Vue/Nuxt Discord or write me a mail (blog at lichter dot io).

Hope this article cleared up the ways to integrate an API with Nuxt.js!

2018 lies in the past and I felt that this was by far the most productive year I had. On the other hand, I’m somewhat certain that this is not the end of the road. Though it was a great year, there are always things one could have done better, more professional, faster or just not at all.

Personal Life

The last year brought some bigger changes to my life. I started a half-year long internship at Xilinx Ireland, beginning at the end of summer. But before, I had to move out of my current flat which was on the 5th floor and there was no elevator. (PS: can't recommend) and also to take some very important exams in university. Though it was a little stressful because the dates were all close together, the exams were very “intense” (read: a lot of topics to learn and not much time to learn) and work for my own company was also always calling, I managed the situation somehow and I’d say, not too badly. I passed the exams, moved out on time, finished a large contract project and then went abroad. After roughly 4 months in Dublin, I must admit that I love the warmth and friendliness of the people, the city, the landscape but definitely not the weather.

Working full-time and not being self-employed - and not being a student in the meantime - forced me to re-schedule almost everything because time is even more rare now. Luckily I still have time for my girlfriend (who isn’t abroad with me), open source, going to the gym - hopefully regularly again, friends, my own company and to explore the country.

Speaking of open source…

Nuxt.js (and friends)

I started using Nuxt already back in December 2017 when I decided to rebuild my personal page with it. However, the relation between Nuxt.js (the framework and the team) and me really evolved in 2018. With small steps, like showcasing my page and creating some bug reports in the first months, I was able to make first contributions to the Nuxt.js ecosystem in march. For example to:

• the Nuxt PWA Module
• to my favorite CSS Framework, TailwindCSS to make it usable with Nuxt,
• vue-meta (used by Nuxt.js for the head tag management)
• the (now somewhat neglected) auth module
• and several more…

This was followed by an invite to the Nuxt Community GitHub organization and the Nuxt.js Slack (PS: we use Discord now!). I really felt honored and had the chance to contribute even more, which I did. In April, I released my first two nuxt modules for redirects and RSS/ATOM/JSON feeds (out of 8 modules this year). Both are still maintained mainly by me and have over 10k total downloads each. I’ve also created my first open-source Vue components:

• vue-if-bot to show or hide sth. for crawlers (useful to hide cookie banners)
• vue-link for unifying external and internal links
• vue-next-level-scroll for the best scroll experience

These components haven’t been adopted in large scale but that’s fine. I’ve created them to abstract logic that I had to use in a hand full of projects. Because nobody likes to copy and paste component code over and over again.

After passing my exams and before moving to Dublin I spent a lot of time with Contributions to Nuxt. It was really addictive to propose new changes, squash bugs and talk to the core team directly. Alone in August, I was able to propose 19 PRs of which were 14 merged into the Nuxt.js core.

And then there was the Vue.js London conference. Again, thanks to the Nuxt.js team (and my manager at Xilinx who allowed me to go) I was able to attend the conference. And not only that, my ticket was funded by the open collective money from Nuxt to thank me for my steady contributions. I was incredibly happy when Sebastien told me that, especially because I then would meet the Nuxt brothers in person.

It happened. 10 minutes before the legendary live-release (which I did not know of) presentation at Vue.js London I met these two awesome guys and they said: “Oh, you know what? You are in the slides. Welcome to the Core Team!”

That was definitely one of the most significant moments in 2018. No joke. It meant so much to me (and it still does)!

The conference itself was my first Vue conference and it was a blast. So many interesting, clever and kind people in one place. New connections and new friends. Very well-prepared and informative talks and a nice after-party. This won’t be my last conference, no doubts!

Nuxt has evolved since then as well. More features, smart ideas, and also a more thoughtful progress. It was the 4th fastest growing open source project in 2018. And my prediction for 2019 is that Nuxt will grow further, will evolve further, will mature further.

PS: Becoming a core maintainer isn’t impossible at all, even if you don’t have decades of experience. If you are willing to invest time, eager to learn new things, ready to help people and, if you want, available to take a few responsibilities you just have to show that you are interested in it. That means you can start helping out where help is needed: Triaging issues, answering questions on several platforms, improving the docs, and so on. Contributing to the code itself is important but not everything!

Blogging

One of my Goals for 2018 was to finally start blogging! I even had a list with topics that got longer and longer but I had no time to actually build the blog. Of course, I wanted to build it completely on my own with my favorite tech stack. In Summer I finally had the time to do so and at the end of August, the first blog posts had been released.

In 2018 I wrote “just” 7 blog posts, which is barely more than 1 per month. But I’m quite relieved that almost all the feedback was positive. People told me that the blog posts helped them and that they learned new things. Exactly what I wanted to achieve! With more than 7.000 unique visitors just in December, this goal is also validated (thought visitor count is not the only metric which is important here).

Twitter

I haven’t been using Twitter at all for a longer time (until 2016). Thanks to my friend and colleague Max Langer I finally joined Twitter and regretted it to be late to the party a few weeks after. Since then I was most of the time a silent reader that likes stuff and throws in a few comments here or there.

Since I started to dig into Nuxt (and had no blog or another platform) I released small tips regarding the framework. Thanks to them I achieved the 500 follower milestone in 2018. Here applies the same as for my blog post. I’m happy if these tips help people and if people like them (and spread them of course ☺️)

Speaking

Thankfully I had the chance to gave a few talks in my university at the beginning of the year. These were about Functional Programming and why PHP isn’t dead (yeah, it is not).

In May I held another PHP talk at the local PHP Usergroup (thanks to PHPUGDD for having me!).

After arriving in Dublin I was on the look for Vue.js meetups and was glad that there was one group that did recurring meetups. The first meetup with them was terrific! A smaller group with, again, very welcoming people. We all introduced each other and went for a beer after two great talks and delicious pizza. Of course, I wanted to give something back to the community as well. So it came that I held the 5th and last talk of the year, an Introduction to Nuxt.js in November. Nothing went wrong, the questions during the Q&A were sophisticated and the people were happy. What a nice end (with regards to speaking) for that year!

PS: If you are in Ireland, please come around and say hi at the meetup! We are always looking for speakers too ☺️ PPS: The new VueJS Dublin website will be made with Nuxt too. But it’s still WIP.

Developmint

My own company (that I lead together with Max I mentioned above) turned three in August. I can’t really tell a lot because most contracts are under an NDA or the results already published on our company page (which has been rebuilt with Nuxt too). 2018 was a great year for the company. Though I’m abroad I still do some work when I find the time. Since I also offer hourly billed Nuxt.js consulting when I can, this is no wonder.

Shipping

Besides contract work, I also shipped a few things. Some secretly, some quite public.

As you know, I built my blog and rebuilt my personal page and my company's page. What also happened is that I built a small donation page for me (because it was requested by people who wanted to donate). A great chance to fiddle around with Stripe, build things in the open and create another learning repository that includes a Nuxt project. Tada, thanks.lichter.io has been built.

There is also Brotli.Pro which is still in testing phase but is publicly available (and was shipped secretly). With it, you can test if your website properly uses Brotli compression or not. This can make a huge size difference for your files! I’m still working on some content for the page. This one isn’t open-sourced (like my blog isn’t [yet?]).

Summary and Goals

Wow! This post is now way longer than expected. Okay, quick: Here are my goals:

• Blogging more frequently (Blogging has become one of my favorite tasks. I like writing more and more and there are still so many things to write about)
• Keeping up the gym routine throughout the year (I don’t want to get too lazy again, especially when I’m back in Germany)
• Improve my organization - More lists, written stuff, timeboxing!
• Look into Elixir (I like functional programming and Elixir looks quite nice. Why not trying it out?)
• Complete another awesome Hacktoberfest (This year I opened 56 PRs in October and 54 were merged. I want to keep that up)

That’s it, folks! Thanks for reading and a happy 2019 with a lot of success to you!

This article is written for Nuxt 2.

If you are looking for the Nuxt 3 version of this article, please follow this link to the updated Nuxt 3 version.

Hey Nuxt friends! As you might already have experienced, SSR comes with certain caveats, including no access to browser-specific APIs, like the local storage, on the server-side. But what if you could enable SSR only for pages where SEO is needed and use the “traditional” SPA mode elsewhere, say in a “member area” in your Nuxt 2 application.

Guess what? You can do that! In the following post I’ll show you how to selectively disable SSR or SPA mode based on the page url.

The Nuxt Source Code

Before going into detail on how to enable SSR selectively we should look into the Nuxt.js source code to see how Nuxt makes such a distinction possible. The responsible snippet can be found in the vue-renderer package. Let’s dissect it one line after each other!

1. Extract
   req
   and
   res
   (the request and response object from the request to the server) from the context object.

const { req, res } = context

1. If
   context.spa
   (might have been set through other internals before rendering pages) or
   res.spa
   (can be modified otherwise!) is truthy, treat the page that’ll be rendered as SPA.

const spa = context.spa || (res && res.spa)

1. In case SSR is disabled or the page should be treated as SPA, only load metadata and render the page as SPA (with JavaScript files but no HTML included) through an early return.

if (!this.SSR || spa) {
  const {/* ... */} = await this.renderer.spa.render(context)
  const html = this.renderTemplate(/* ... */)
  return { html, getPreloadFiles: this.getPreloadFiles.bind(this, { getPreloadFiles }) }
}

And that’s all the magic ☺️

Implementation

After looking into the source code we found out that all we have to do is to set

1. serverMiddleware
   are a concept that is directly provided through the framework (no 3rd party libs needed)
2. We can freely customize our selection logic.

A minimalist implementation would look like this:

export default function(req, res, next) {
  const paths = ['/', '/a']

  if (paths.includes(req.originalUrl)) {
    // Will trigger the "traditional SPA mode"
    res.spa = true
  }
  // Don't forget to call next in all cases!
  // Otherwise, your app will be stuck forever :|
  next()
}

To see a working example directly, you can check out the CodeSandbox. Be aware that it runs in

Wrapping up

You might ask yourself: Do I need to selectively switch between the modes? The answer is most of the time: No. But there might be some situation where you want to avoid wrapping a lot of page contents in

What did you use the selective SPA/SSR for? Please tweet me at @TheAlexLichter, reach out on the Vue/Nuxt Discord or write me a mail (blog at lichter dot io).

I hope you enjoyed the article and the small Nuxt source code dive. If this is the case, I’d gladly ask you to spread the word!

So, a decent organization of your API calls in your frontend is necessary to stay sane. But how do we do that with Nuxt 2?

The two sides of the Nuxt coin

With Nuxt it seems to be bit more complicated to properly organize your API requests because you have to think about the server side in addition to the client side. You will probably retrieve data from your backend in

The Nuxt axios module

If you are not using the official Nuxt axios module by now, you should really switch over soon (read: now). Instead of importing axios everywhere, the module provides you a convenient interface on the client-side (

But is that it? Of course not! We found a way to centralize our configuration but that’s just one part of the puzzle.

Abstracting our REST API

Now the interesting part begins. For further context, a RESTful API will be assumed. The techniques in the following paragraphs will work for most of the APIs though but have to be adapted slightly.

For our example, we will use parts of the JSON Placeholder API as it covers all HTTP verbs and is not too complex.

Let’s take a look at the

• Create a post
• Show details of a specific post (eg. title and content)
• Show an overview of (all/some) posts, also called a post index (often used on an index page as well)
• Update a post
• Delete a post

If we consider other resources, for example

• Create a user
• Show a user’s details (for example on his profile page)
• Show a list/an index of all users (member list)
• Update a user
• Delete a user

With this knowledge, we can try to abstract our API with a Plain Old Javascript Object (POJO) by creating a method for each verb. A

The design pattern we borrow us here is called Repository Pattern.

Let’s save this file to

export default {
  create(payload) {},

  show(id) {},

  index() {},

  update(payload, id) {},

  delete(id) {}
}

Okay, so we have a basic scaffold for our API abstraction though we still have to fill the methods somehow. Now the

Dependency Injection to the rescue

Another term crosses our way:

If you are depending on a library like axios you usually would import and use it like this:

import axios from 'axios'

export default {
  async index() {
    const result = await axios.get('...')
    return result.data
  }
}

This is fine for many use-cases, but for that one, the approach comes with several disadvantages:

• You can’t easily swap out the implementation for another one if you want to
• The dependency has to be known before runtime

While the former isn’t a huge issue in our case, the latter poses a problem for us. We know the dependency but we can’t actually

Instead, we inject the dependency which means we pass it as a parameter in a function (or to the constructor if you are using a

export default axios => ({
  async index() {
    const result = await axios.get('...')
    return result.data
  })
}

Boom, dependency injected! Let’s fill out our original scaffold and make use of the

export default $axios => ({
  index() {
    return $axios.$get('/posts')
  },
  create(payload) {
    return $axios.$post(`/posts`, payload)
  },
  show(id) {
    return $axios.$get(`/posts/${id}`)
  },
  update(payload, id) {
    return $axios.$put(`/posts/${id}`, payload)
  },
  delete(id) {
    return $axios.$delete(`/posts/${id}`)
  }
})

Generalize our implementation

Okay, so far so good. Currently, the

Instead of adding a second parameter to our default export we will transform the function to a higher order function (a function that returns a function):

export default $axios => resource => ({
  index() {
    return $axios.$get(`/${resource}`)
  },
  // ...
}

Now when we import our function somewhere, we can reuse it for many resources, but we only need to pass in the axios instance once:

import createRepository from '~/api/repository.js'

// First, call the function with the axios object

const $axios = getAxiosMagicallyFromSomewhere // we will find out how to get it further down the road
const repositoryWithAxios = createRepository($axios)

// Now you can create repositories and re-use the `repositoryWithAxios` function

const postRepository = repositoryWithAxios('posts')
const userRepository = repositoryWithAxios('users')
// ...

With this pattern, you don’t have to pass in the options again and again.

Leverage the power of Nuxt.js plugins

There we go. We have abstracted our API resources successfully and found a way to re-use that abstraction properly, but two problems are still unsolved.:

• How can we access the abstraction throughout our Nuxt app?
• How can we properly pass in the axios instance from the Nuxt module?

To solve both problems at once we utilize a Nuxt.js plugin. They are mostly used to add global Vue components or libraries but can be used in many other ways too. Also, they are evaluated before creating the root Vue instance.

Okay, let’s create a file at

If the plugin has a default export function, two parameters will be passed to that function: The Nuxt context and a method called

import createRepository from '~/api/repository.js'

export default (ctx, inject) => {
  // Here we will do it
}

Inside the function, we have everything we need to make our API repositories available across all relevant parts of our Nuxt app and to pass the axios instance to our construct.

Passing in the axios instance

Because the context is available in the plugin default export method, we can pass in the axios instance without any problems:

import createRepository from '~/api/repository.js'

export default (ctx, inject) => {
  const repositoryWithAxios = createRepository(ctx.$axios)

  const repositories = {
    posts: repositoryWithAxios('posts'),
    users: repositoryWithAxios('users')
    //...
  }
}

Inject it

Now the last (and mightiest) step has to be taken. Make the implementation available across our app so it can be used in components,

import createRepository from '~/api/repository.js'

export default (ctx, inject) => {
  const repositoryWithAxios = createRepository(ctx.$axios)

  const repositories = {
    posts: repositoryWithAxios('posts'),
    users: repositoryWithAxios('users')
    //...
  }

  inject('repositories', repositories)
}

Then

• Add the key-value pair to the Vue prototype (so
  this.$key
  can be used in components and store
• Add the key-value pair to the
  ctx.app
  object (so it can be used in
  asyncData
  ,
  fetch
  and so on)

Use it

We’ve completed our whole setup, so the only thing left is to actually use it. I’ve built a small live demo with CodeSandbox so you can directly play with it.

Make sure to check out the Vue API query plugin by Robson Tenório which provides an advanced query builder for your API. That package can definitely save you some work!

Conclusion

Using an API repository to organize your calls is a mighty tool to keep track of your endpoints, call them uniformly, reduce duplicate code and also to have an easier time debugging or changing them!

The idea of injecting objects in the context and injecting other dependencies in a Nuxt plugin is a recurring pattern that can be used in a variety of scenarios. Keep that one in mind!

Still have questions? No problem, tweet me at @TheAlexLichter, reach out on the Vue/Nuxt Discord or write me a mail (blog at lichter dot io).

Have you learned something by reading this post? Awesome, then I’ve reached my goal ? Also, please spread the word if you liked the article!

If you ever want to switch to an SSR-based approach or share your component with people who do, this knowledge will definitely make your life easier! As a library/plugin author, this is a must in my opinion. And guess what, it isn’t even hard!

Common pitfalls

There are three very common and very problematic caveats that developers should think about when writing universal components. We’ll go through all of them one by one, showing examples of wrong and right implementations!

We will use this CodeSandBox for the examples.

window, document, and friends - platform-specific APIs

When the component is processed on the server-side, no dynamic updates will occur. That’s why only two lifecycle hooks will be executed on the server:

But on the server-side, there is no

This is by far the most common problem with “normal” components or 3rd party libraries in a server-side-rendered environment.

Rule of thumb: Don’t call browser-specific APIs in

export default {
  created () {
    if (typeof window !== 'undefined') {
        window.scroll(/*...*/)
    }
  }
}

But in most situations, it is completely fine to call them in

Also, you can sometimes leverage

An example component of correct usage can be found under

Lifecycle hooks and side effects

Speaking of lifecycle hooks! There is another thing you should think about:

To avoid memory leaks, you do not want to have side-effects in your

Rule of thumb: Don’t use code with

The examples can be found under

But when will it be server-side rendered? The answer is: every time a user enters the app over the

Because the first page-request to the app will be server-side-rendered and all subsequent requests (through page navigation, on-page redirects and so on) will be rendered by the client. Page refreshes and other external redirects to the app count as “entry points” and will be server-side rendered.

No data reactivity

This is usually no big problem but it’s not bad to mention it anyway. There is no reactivity between the values on the server-side and on the client side.

If you manipulate your

Directives

Custom Vue directives are often used to manipulate the DOM (eg. revealing elements on scroll or make them stick to a specific position). This won’t work on the server-side as we now know. But what can be done there?

Well, the easiest way is: Don’t use directives as the abstraction, use components. I did this with components like VueNextLevelScroll or vue-if-bot because it is way easier to make them universally usable and they can be code-split as well! You don’t lose anything by choosing components as an abstraction.

If you really want to use directives, you can add a server-side equivalent of this directive. In Nuxt, this is possible by setting up a

Attention: Be aware to pass in your directives in

The matching example will show you why you definitely should use components or server-side directives. Do you notice the flickering for the client-side-only directive example? It will be noticeable for all users that use this page as an entry point.

Conclusion

Alright, let’s wrap it up, folks! If you want to go through the example code line by line, please take a look into the CodeSandBox.

• Be careful when using platform-specific APIs, especially
  window
  and
  document
• Keep in mind that
  created
  and
  beforeCreate
  are executed on the server and client side. No side effects, no
  window
• There is no reactivity on the server side
• Using directives isn’t always the best abstraction. But if you do use them, provide a server-side directive

If you want further reading, I suggest reading the official vue-ssr-docs!

Still have questions? No problem, tweet me at @TheAlexLichter, reach out on the Vue/Nuxt Discord or write me a mail (blog at lichter dot io)

I hope you enjoyed that article and are now a bit more aware of server-side-rendering compatibilities! If this is the case, I’d gladly ask you to spread the word!

Introduction

If you’ve ever heard compression related to the web,

Other compression methods were introduced in that time but for long none was able to show up better compression results, browser support, and compression speed.

This changed when

So, why shouldn’t we use

Add Brotli to Nuxt.js

Already earlier in 2018 I thought this might be a good idea and now we are here! Adding

Before we continue

Important notice: In general, I highly recommend to configure your platform provider, e.g. Heroku or AWS, or web server, like Apache or NGINX, to handle Brotli and GZIP compression because it will be way more performant. If you can’t for any reason, then setting it up in Nuxt is a decent option.

Compression middleware

Every time Nuxt.js renders a page it will call a bunch of middleware (f.ex. the error middleware to handle possible server-side errors). An important middleware that will be called is the compression middleware which will, as the name hints, compress the response. By default, the

This package does not support

Swap out the middleware

What if we could swap out the middleware for another… would this solve our problem? At least it would bring us one step further to the goal.

And as I said above, with Nuxt 2 it’s possible.

Now we have to find a suitable middleware!

During my research, I found a package called shrink-ray which is actually a fork of the

Insert the middleware

Alright, all prerequisites fulfilled. Let’s get into the code!

First, install the packages (

Now edit your

import shrinkRay from 'shrink-ray-current'

export default {
  render: {
    compressor: shrinkRay()
  }
}

Be careful to actually invoke

And that’s it! Start your app (in production mode, otherwise no compression will take place) and open your browser. Jump into your developer tools, select your network tab and reload the page. Now click the table header in the network tab and add the

If you see

Firefox network tab displaying different scripts loaded with Brotli compression

Compatibility

Oh right, before we forget it! What happens if a user with an older browser (say IE 11) wants to connect to our app? Will they get an error?

No! That’s not a problem. Our

Troubleshooting

Proxies

If you are using a proxy (likely the

I usually create a mapping from

export default {
  modules: ['@nuxtjs/axios'],
  render: {
    compressor: shrinkRay()
  },
  // ...
  proxy: {
    '/api/': { target: 'api.myurl.com', pathRewrite: { '^/api/': '' } }
  }
  // ...
}

You now have to exclude all requests starting with

export default {
  modules: ['@nuxtjs/axios'],
    render: {
    compressor: shrinkRay({
      filter: (req, res) => {
        if (/^\/api/.test(req.originalUrl)) {
          return false
        }
        return shrinkRay.filter(req, res)
      }
    })
  },
  // ...
  proxy: {
    '/api/': { target: 'api.myurl.com', pathRewrite: { '^/api/': '' } }
  }
  // ...
}

Now we exclude all

Final Testing

To ensure that Brotli is enabled on your site now, you can use an online tool called Brotli.Pro which will tell you whether your website supports Brotli compression or not!

Brotli encoded XHR requests

UPDATE: Outdated!

Now you might think the next would be setting up

On the client-side, axios will delegate the decoding to the browser (and most modern browser support

Closing remarks

Once again, we did it! As a personal summary, I’ve decreased my blog’s index page size from 210kB to 170kB, which is a total of 19% decrease in size.

As soon as you finished your setup (which should be soon because you reached the end of the post) be sure to tell me how many kilobytes you saved!

I’ve uploaded a sample setup for you on GitHub. All you have to do is to clone the repository, install the package and you are good to go!

All in all, I hope this article helped you a little. If so it would be awesome if you could spread the word (for example by using the buttons below the article).

Questions left? Critics? Have you successfully stepped through the setup?

Hit me up on Twitter (@TheAlexLichter) or write me a mail (blog at lichter dot io).

Fear no more! It’s possible to send emails almost directly through Nuxt but only in SSR mode with a Node.js server running. No more additional API server necessary if you want to send a mail with data coming from a contact form.

Before diving into the implementation and ideas behind it, here is the full source code I’m referring to through this blog post. It’s from my company’s website developmint.de.

The main goal was a simple API endpoint accessible through Nuxt.js to handle the three contact form fields (name, email and message) and to send an email with the data if everything is alright.

Let’s get it on - serverMiddleware

While developing the redirect-module for Nuxt 2, I came in touch with serverMiddleware. Those run before the actual

But as they are highly customizable and flexible, why not use them as endpoints instead?

This is possible. An example middleware could look like this:

export default (req, res) => {
  res.write('Hey!')
  res.end()
}

When saved to

export default {
  // ...
  serverMiddleware: [
    { path: '/api/test', handler: '~/api/test' },
  ],
  // ...
}

If you rebuild your project in dev mode (

We can use server middleware to serve content… But there must be a drawback, right?

Right one could think…

As Nuxt uses connect as middleware layer (to reduce overhead as it suffices the complexity needed), we are missing some “critical” features in comparison to express.

Besides typical convenience features and routing (which isn’t even mandatory in our case), we can’t get the passed parameters from our

We could use the body-parser package and apply it to the route before we use our custom middleware but then we’d face more “problems” like decoding JSON or setting headers “correctly” sooner or later. Likely it would work from a certain point on but there must be a better way. If we could just use express…

Express in Nuxt.js?

Possibly you have heard it the other way: An express app with Nuxt.js as renderer (like in express-template).

But did you know that you can use

import express from 'express'
const app = express()

app.post('/', (req, res) => {
    // Validate, sanitize and send
})

export default {
  path: '/api/contact',
  handler: app
}

We declare the express app as the middleware handler and Nuxt is magically gluing everything together.

Now we can save this short snippet under

export default {
  // ...
  serverMiddleware: [
    '~/api/contact'
  ],
  // ...
}

Still missing: the mailer

The last coding part might be less spectacular for everybody who already set up nodemailer in an express app.

Fun fact: Before this implementation I did not as I mostly write backends in Laravel (♥️).

Inserting the body-parser

Since version 4.16.0, express has its own JSON middleware based on body-parser. To get our JSON parameters out of the POST body, we will need it:

import express from 'express'
import nodemailer from 'nodemailer'

const app = express()

app.use(express.json())
// ...

Validate and sanitize

Now we can get back to our

import express from 'express'
import validator from 'validator'
import xssFilters from 'xss-filters'

const app = express()

app.use(express.json())

app.post('/', (req, res) => {
  const attributes = ['name', 'email', 'msg'] // Our three form fields, all required

  // Map each attribute name to the validated and sanitized equivalent (false if validation failed)
  const sanitizedAttributes = attributes.map(n => validateAndSanitize(n, req.body[n]))

  // True if some of the attributes new values are false -> validation failed
  const someInvalid = sanitizedAttributes.some(r => !r)

  if (someInvalid) {
    // Throw a 422 with a neat error message if validation failed
    return res.status(422).json({ 'error': 'Ugh.. That looks unprocessable!' })
  }

  // Upcoming here: sending the mail
})

Let’s take a look at the

const rejectFunctions = new Map([
  [ 'name', v => v.length < 4 ],
  [ 'email', v => !validator.isEmail(v) ],
  [ 'msg', v => v.length < 25 ]
])
const validateAndSanitize = (key, value) => {
  // If map has key and function returns false, return sanitized input. Else, return false
  return rejectFunctions.has(key) && !rejectFunctions.get(key)(value) && xssFilters.inHTMLData(value)
}

Each possible attribute receives a

Send it out

After validating and sanitizing, we are confident that we can send the mail out!

import express from 'express'
import nodemailer from 'nodemailer'
import validator from 'validator'
import xssFilters from 'xss-filters'
// ...

app.post('/', (req, res) => {
  // ...

  if (someInvalid) {
    return res.status(422).json({ 'error': 'Ugh.. That looks unprocessable!' })
  }

  sendMail(...sanitizedAttributes)
  res.status(200).json({ 'message': 'OH YEAH' })
})

We use the ES6 spread syntax to pass the sanitized values to the

const sendMail = (name, email, msg) => {
  const transporter = nodemailer.createTransport({
    sendmail: true,
    newline: 'unix',
    path: '/usr/sbin/sendmail'
  })
  transporter.sendMail({
    from: email,
    to: 'support@developmint.de',
    subject: 'New contact form message',
    text: msg
  })
}

Inside we create a nodemailer transporter and send the email out. We could do this through

Finally we can send emails - A conclusion

So, we did it! If we now send a POST request (e.g. with

Was it worth it? - Definitely! Instead of blocking another port for such a simple API, we can run it together with our Nuxt server (in SSR mode).

Should I adapt my whole API to leverage Nuxt server middleware now? - You could do this, but I would rather not recommend it, as pointed out in a recent article. It’s a great solution for simple and small APIs, but as soon as complexity or the request count increases, better go with own API servers (not only because of performance, also because of better scalability and no “single point of failure”).

Closing remarks

I hope you enjoyed the article! If so it’d be cool if you could spread the word ☺️

Questions left? Critics? Hit me up on Twitter (@TheAlexLichter) or write me a mail (blog at lichter dot io). I’m curious to hear from you!

Update (19.08.2018): Improved the code by using Map

Introduction

I held a code review on a clients project recently, as usual when the team has been implemented a new feature. The code was ‘working’, but far from optimal because a naive approach has been taken. This is totally fine, as reviews are for such situations. But after writing code I suggest to look over it once again and to refactor it on the fly (after the tests are passing).

Let me outline the context for the code:

Think about taking a course or participating in a seminar. After people have signed up for such a seminar, they receive an email with a confirmation link. After confirming that they are participating, they get a confirmation mail with a link to cancel the participation. Both links will call a website, which calls then an API with the submitted tokens. The response of this API call is the condition for the text that will be displayed on the website. Then our function comes in. It will return the text shown depending on the API response. Also, it is a pure function (no side-effects). Catching request errors has been done before.

Initial code

Now here goes the code. Try to read over it just once:

const evaluateResponseOld = response => {
  let text = ''
  if (response.valid) {
    if (response.type === 'Confirmation') {
      if (response.used) {
        text = 'This token has already been used'
      } else {
        text = 'Thanks for your subscription'
      }
    } else if (response.type === 'Cancellation') {
      if (response.used) {
        text = 'This token has already been used'
      } else {
        text = 'You have been unsubscribed successfully'
      }
    }
  } else {
    text = 'The provided code is invalid'
  }
  return text
}

Problems of the initial code

Were you able to find out all the different cases and returns after one read? I wasn’t back then, though I read code every day.

High cognitive load

So, as you likely have recognized, the code is unnecessarily complex and has, therefore, a high cognitive load. You always have to remember which condition was fulfilled. Also, the

Difficult Maintainability

Now imagine that an additional state must be handled because the API will respond to another scenario now (for example

Code duplication

Code duplication per se is better than a wrong abstraction but in this case the code is unnecessarily duplicated and therefore more error-prone. Think about you have to change

Iterations

So… how can we do better? We will look into some techniques I use to transform this code in a more readable snippet. It only takes six small iterations!

First iteration - Remove temporary variables

Motivation

So, why should we remove temporary variables from the code (as far as possible)? Well, first of all, it reduces cognitive load. When almost all variables are immutable (or no variables exist), you don’t have to think about their state! In our scenario, we can even omit the

Code

const stepOne = response => {
  if (response.valid) {
    if (response.type === 'Confirmation') {
      if (response.used) {
        return 'This token has already been used'
      } else {
        return 'Thanks for your subscription'
      }
    } else if (response.type === 'Cancellation') {
      if (response.used) {
        return 'This token has already been used'
      } else {
        return 'You have been unsubscribed successfully'
      }
    }
  } else {
    return 'The provided code is invalid'
  }
}

Second iteration - Invert guarding if-statements

Motivation

Guarding

Code

const stepTwo = response => {
  if (!response.valid) {
    return 'The provided code is invalid'
  } else {
    if (response.type === 'Confirmation') {
      if (response.used) {
        return 'This token has already been used'
      } else {
        return 'Thanks for your subscription'
      }
    } else if (response.type === 'Cancellation') {
      if (response.used) {
        return 'This token has already been used'
      } else {
        return 'You have been unsubscribed successfully'
      }
    }
  }
}

Third iteration - Remove else

Motivation

Okay, this might be a bit controversial but I usually consider

Normally I’d replace all

Code

const stepThree = response => {
  if (!response.valid) {
    return 'The provided code is invalid'
  }

  if (response.type === 'Confirmation') {
    if (response.used) {
      return 'This token has already been used'
    }
    return 'Thanks for your subscription'
  } else if (response.type === 'Cancellation') {
    if (response.used) {
      return 'This token has already been used'
    }
    return 'You have been unsubscribed successfully'
  }
}

Fourth iteration - Deal with duplications in the logic

Motivation

Now we should focus on the “leftovers”. As the code is more readable we can take a look and find possible duplicates in the code branches.

If we look over our transformed code we now see clearly that the

Code

const stepFour = response => {
  if (!response.valid) {
    return 'The provided code is invalid'
  }

  if (response.used) {
    return 'This token has already been used'
  }

  if (response.type === 'Confirmation') {
    return 'Thanks for your subscription'
  } else if (response.type === 'Cancellation') {
    return 'You have been unsubscribed successfully'
  }
}

Fifth iteration - Lookup table

Motivation

One criterion was that we should be able to add new response states easily. To do this, we should minimize the code we would need for it. Currently, we’d have to add another

To reduce the changes when adding a

We will create a

Code

const stepFive = response => {
  if (!response.valid) {
    return 'The provided code is invalid'
  }

  if (response.used) {
    return 'This token has already been used'
  }

  const responseLookup = {
    Confirmation: 'Thanks for your subscription',
    Cancellation: 'You have been unsubscribed successfully'
  }

  if (responseLookup.hasOwnProperty(response.type)) {
    return responseLookup[response.type]
  }
}

You could also use a

const stepFiveWithMap = response => {
  if (!response.valid) {
    return 'The provided code is invalid'
  }

  if (response.used) {
    return 'This token has already been used'
  }

  const responseMap = new Map([
    ['Confirmation','Thanks for your subscription'],
    ['Cancellation','You have been unsubscribed successfully']
  ])

  if (responseMap.has(response.type)) {
    return responseMap.get(response.type)
  }
}

Placing the lookup object outside would also be viable as long as the lookup object don’t change through the function. This makes your function impure though, because it’ll then depend on an outside object and not only on it’s inputs.

To solve this, you could take both parameters (the

const responseMap = new Map([
  ['Confirmation', 'Thanks for your subscription'],
  ['Cancellation', 'You have been unsubscribed successfully']
])

const higherOrderStepFiveWithMap = lookupMap => response => {
  if (!response.valid) {
    return 'The provided code is invalid'
  }

  if (response.used) {
    return 'This token has already been used'
  }

  if (lookupMap.has(response.type)) {
    return lookupMap.get(response.type)
  }
}

const stepFiveWithMap = higherOrderStepFiveWithMap(responseMap)

// Now use stepFiveWithMap(yourResponseObject)

While I’d prefer this version because of the reusability, purity and low coupling, let’s stick to the simple and impure map version:

const lookupMap = new Map([
  ['Confirmation', 'Thanks for your subscription'],
  ['Cancellation', 'You have been unsubscribed successfully']
])

const simpleAndImpureStepFiveWithMap = response => {
  if (!response.valid) {
    return 'The provided code is invalid'
  }

  if (response.used) {
    return 'This token has already been used'
  }

  if (lookupMap.has(response.type)) {
    return lookupMap.get(response.type)
  }
}

Sixth iteration - Invalid state

Motivation

Alright! The code looks readable, has no duplication and is easily maintainable. One thing is missing though: Handling invalid states. Even if you think that this will never ever happen, it won’t hurt to throw an error if it does. In the best case, your monitoring/reporting tool will pick it up and tell you. It’s worth to write tests for invalid states as well, especially when it comes to user input!

Code

const lookupMap = new Map([
  ['Confirmation', 'Thanks for your subscription'],
  ['Cancellation', 'You have been unsubscribed successfully']
])

const simpleAndImpureStepFiveWithMap = response => {
  if (!response.valid) {
    return 'The provided code is invalid'
  }

  if (response.used) {
    return 'This token has already been used'
  }

  if (lookupMap.has(response.type)) {
    return lookupMap.get(response.type)
  }

  throw new Error('Invalid state while evaluating response')

  /*
    we could also 'shorten' that a little with short-circuit:

    const invalid = () => { throw new Error('Invalid state while evaluating response') }

    return lookupMap.get(response.type) || invalid()
  */
}

Wrapping it up

We did it! Before wrapping everything up, let’s compare the initial and the final code:

Initial code

const evaluateResponseOld = response => {
  let text = ''
  if (response.valid) {
    if (response.type === 'Confirmation') {
      if (response.used) {
        text = 'This token has already been used'
      } else {
        text = 'Thanks for your subscription'
      }
    } else if (response.type === 'Cancellation') {
      if (response.used) {
        text = 'This token has already been used'
      } else {
        text = 'You have been unsubscribed successfully'
      }
    }
  } else {
    text = 'The provided code is invalid'
  }
  return text
}

Final code

const lookupMap = new Map([
  ['Confirmation', 'Thanks for your subscription'],
  ['Cancellation', 'You have been unsubscribed successfully']
])

const simpleAndImpureStepFiveWithMap = response => {
  if (!response.valid) {
    return 'The provided code is invalid'
  }

  if (response.used) {
    return 'This token has already been used'
  }

  if (lookupMap.has(response.type)) {
    return lookupMap.get(response.type)
  }

  throw new Error('Invalid state while evaluating response')
}

Conclusion

As you see, the final code is has a maximum depth of one (previously four), only three branches (previously five) and is even shorter than the initial one (five source lines of code less). The cyclomatic complexity, which measures the amount of independent paths the function can take on execution, decreased by two.

The techniques utilized in a nutshell:

1. Remove temporary variables and try to avoid shared state where you can
2. Invert guarding ifs and use early returns to reduce cognitive load and complexity/depth
3. Remove else if you always return early
4. Find and deal with duplicated code in leftover logic
5. Use a lookup table/lookup object when you can
6. Proper handling of invalid state

I hope you liked the content! If so it would be neat if you could spread the word (f.ex. with the buttons below).

Questions left? Critics? What is your opinion on those techniques?

Hit me up on Twitter (@TheAlexLichter) or write me a mail (blog at lichter dot io).