Forem: David Parks

Load Test Your Nuxt API on Vercel With k6

David Parks — Thu, 25 Mar 2021 22:43:11 +0000

Intro

Recently, I have been delving into the full-stack side of Nuxt.js and seeing what it can offer in terms of building out a full-fledged API. By leveraging the serverMiddleware property, you can create REST endpoints using Express, all without leaving your project directory. That's powerful!

However, once your application begins to scale and your server and database are put under a more strenuous load, you need to ensure that your API will remain performant for your users. You don't want to be losing potential visitors/revenue if your app goes down! It's important to catch these performance regressions before it's too late!

Thankfully, there is a tool out there that lets you simulate heavy workloads and multiple concurrent user connections. Enter k6!

What's k6?

k6 is a "load testing tool and SaaS for engineering teams". It's an incredibly useful tool that lets you run load tests straight from your command line, using ES6 Javascript syntax! It comes with a CLI tool that's full of a ton of useful features, and actionable metrics that give you a 360° view of your APIs performance. To learn more about all the useful metrics k6 captures, feel free to check out their section dedicated to it

This article will walk you through the process of setting up a basic API endpoint in Nuxt using the serverMiddleware property and Express, deploying that Nuxt application to Vercel using Nuxt Vercel Builder, and finally load testing our production endpoint with k6.

If you want to jump right into the code, check out my repository on Github which mirrors what we will be implementing.

Setup

It goes without saying we'll need a fresh Nuxt application to get rolling! Go ahead and create a new Nuxt project using the command line tool of your choosing (I prefer npx).

npx create-nuxt-app <project-name>

Next, we need to make sure that we are setting our Nuxt deployment target to server since we will be making use of serverMiddleware. We'll also need to edit our nuxt.config.js to specify the directory we wish to use for API routes. Go ahead and add the following lines to your nuxt.config.js file.

export default {
  // ...
  target: 'server',
  // ...
  serverMiddleware: {
    '/api': '~/api'
  }
  // ...
}

Since we will need a server, we also need to install Express.

npm install express

Excellent! Next, make sure k6 is installed to your machine. For your platform specific installation view their section here. For Mac OSX users, simply use Homebrew.

Finally, since we will be deploying our application to Vercel, we need to make use of Nuxt Vercel Builder in order to tell Vercel how to deploy our server side rendered Nuxt application and Express API to their platform.

Create a file called vercel.json in the root of your project.

{
  "version": 2,
  "builds": [
    {
      "src": "nuxt.config.js",
      "use": "@nuxtjs/vercel-builder",
      "config": {
        "serverFiles": ["api/**"]
      }
    }
  ]
}

Creating our API endpoint

For the purposes of this demo, we will only be building a simple "ping" endpoint to load test. In a more full-featured SaaS application, you'd want to also test some CRUD operations paired with a database of your choosing to better simulate the more involved operations your users will be performing.

Go ahead and create a folder in the root of your project called api and inside a file called index.js as well as ping.js. This is where we will be initializing our express server and setting up our route.

In index.js, add the following lines.

const express = require('express')
const app = express()

const ping = require('./ping')
app.use(ping)

if (require.main === module) {
  const port = 3001
  app.listen(port, () => {
    console.log(`API server listening on port ${port}`)
  })
}

module.exports = app

And then in ping.js.

const { Router } = require('express')
const router = Router()

router.use('/ping', (req, res) => {
  res.json({
    message: 'Ping!'
  })
})

module.exports = router

Great! Now if you run npm run dev and navigate to localhost:3000/api/ping you should see our simple JSON response!

It's time to deploy!

Deployment

You will need to push your local project to a Git repository, and follow the deploy instructions on Vercel. Thankfully, our vercel.json file takes care of all the work to deploy our SSR Nuxt app here!

Once you have a publicly accessible URL for your project, navigate to your-project-url.vercel.app/api/ping to make sure our API deployed successfully.

Load testing our endpoint

Now that our SSR Nuxt application with a basic API is deployed to Vercel, it's time to load test our ping endpoint. Create a file in the root of your project called loadtest.js and add the following:

import http from 'k6/http'
import { check, group } from 'k6'
import { Trend } from 'k6/metrics'

let PingTrend = new Trend('Get ping', true)

export let options = {
  vus: 40,
  duration: '15s',
}

const baseUrl = `https://your-project-url.vercel.app/api`
const endpoints = {
  ping: `${baseUrl}/ping`,
}

export default function () {
  group('ping', function () {
    // Get ping
    let getPingRes = http.get(endpoints.ping)
    check(getPingRes, {'status was 200 (ping)': (r) => r.status == 200 })
    PingTrend.add(getPingRes.timings.duration)
  })
}

Make sure to replace the baseUrl variable with the URL for your deployed Nuxt API.

For our k6 options, we are specifying that we will run 40 concurrent virtual users with a test duration of 15 seconds. It's up to you to increase/decrease as you'd like to test expected concurrent load. As you'll see, our API can handle 40 concurrent users in parallel no problem.

In k6, a trend is a custom metric on their platform that calculates different values for your invocation like the minimum, maximum, median and average percentiles of the execution time. In our script we are creating a new trend to track our ping performance. Additionally, we are adding a check that the endpoint was successful with a 200 status code result.

Now, we can run this file from our command line using the command

k6 run loadtest.js

When your load test is finished, you should see something like this

The main metric we are interested in is the first one, our Get ping line. As you can see there are average, minimum, median and maximum values for the API request execution time from request to response.

Making sense of the results

You might be saying, wow, the maximum time to execution is a whopping 4.69s and a minimum of only 88.69ms! Why is the gap that large!

Well, when deploying to a serverless environment there is a well known problem known as a cold start. Since Nuxt Vercel Builder deploys our app as a serverless function, we must first spin up our serverless function after it has not been used for some period of time. This is one of the current drawbacks serverless computing faces. There are some workarounds known as "keeping functions warm" by invoking them on regular intervals (potentially resulting in a larger usage bill depending on your deployment platform), however this blog won't delve into that. Feel free to read more on the topic.

Wrapping up

Excellent! We have successfully created a Nuxt API using Express and serverMiddleware, as well as deployed our application and API to Vercel using Nuxt Vercel Builder and tested the API under a heavy load using k6. It's up to you to extend the API and tailor the load testing script to your projects functionality and expected load, but I hope this gets you started on the right foot!

Thanks for reading, and if you found the article helpful feel free to share on Twitter!

Add Interactive Sound to Your Nuxt Site

David Parks — Tue, 08 Dec 2020 23:14:41 +0000

Intro

Recently, one of the most exciting things to happen to me was Sarah Drasner of Vue, Nuxt, SVG and animation fame tweeting about my website!

I've been really enjoying articles by @dparksdev, like this one about Nuxt Table of Contents with Active States. They're well-explained, plus he has these nice touches on his site like little interactions you can play with! https://t.co/B34W0EztRF pic.twitter.com/llgCatwOTB
— Sarah Drasner (@sarah_edo ) November 16, 2020

It's safe to say that was a crazy day. Out of all the kind words I received, the most frequent piece of feedback I received was about my sites interactions. It's true that interactions like the battery under my table of contents or an interesting train add a sense of joy and intrigue to an otherwise bland site. It gets people to stick around and explore and in turn, read more of your content!

One excellent way to facilitate interesting interactions is by adding sounds.

I'll admit it's a bit jarring sometimes, so it's important to allow the user to choose if they hear these sounds on your site, and then save their preference for subsequent page visits.

This article will teach you how to add sounds to your Nuxt site, and leverage localStorage to save their sound preference!

Setup

Thankfully, our setup does not require any external packages! We can use localStorage to save the users preference which is supported by all browsers, and built-in Webpack features to load audio files into our components.

For more info, check out the official Nuxt documentation on extending Webpack to load audio files

First, lets extend our Nuxt config to allow for loading sounds from our assets folder. Add the following lines to your nuxt.config.js file:

export default {
  build: {
    extend(config, ctx) {
      config.module.rules.push({
        test: /\.(ogg|mp3|wav|mpe?g)$/i,
        loader: 'file-loader',
        options: {
          name: '[path][name].[ext]'
        }
      })
    },
  },
}

This will let us import audio files like new Audio(require('@/assets/sounds/zap.mp3')); for example.

Great! Let's also go ahead and create a sounds folder inside of our assets directory to hold our audio files. If you'd like some sample audio to play with, feel free to check out the ones I am using currently on the site.

That's all of our setup! Let's write some code 🤓.

Initializing the user's sound preference

The first time a user visits our site, we can assume that their preference is they want sound to be played. This is entirely up to you if you'd prefer it to be opt-in or opt-out!

We will be utilizing Vuex to initialize a global variable that we can access in any page or components computed properties!

Create a file inside if your store directory called index.js.

export const state = () => ({
  isSoundEnabled: true,
})

export const mutations = {
  initializeSound(state) {
    const isSoundEnabled = JSON.parse(localStorage.getItem('isSoundEnabled'));
    if(!isSoundEnabled) {
      state.isSoundEnabled = false;
      localStorage.setItem("isSoundEnabled", false);
    } else if(isSoundEnabled) {
      state.isSoundEnabled = true;
      localStorage.setItem("isSoundEnabled", true);
    } else {
      state.isSoundEnabled = true;
      localStorage.setItem("isSoundEnabled", true);
    }
  },
}

Here we setup a Vuex mutation that we can call inside of a page or components mounted hook to read from our localStorage and determine if we already have a preference saved, or if we need to initialize their preference for the first time.

Then, inside of a page, we can simply call this mutation as well as access the preference via our isSoundEnabled state variable!

<script>
export default {
  mounted() {
    this.$store.commit('initializeSound');
  },
  computed: {
    isSoundEnabled() {
      return this.$store.state.isSoundEnabled;
    }
  }
}
</script>

Toggling the user's sound preference

Great! But, what if we want the user to change their sound preference? We'll need to implement another mutation that can allow us to edit this variable in our Vuex store as well as save the new preference to localStorage.

Go ahead and add to our index.js file in our store directory by adding the following method toggleSound:

export const state = () => ({
  isSoundEnabled: true,
})

export const mutations = {
  toggleSound(state) {
    state.isSoundEnabled = !state.isSoundEnabled;
    localStorage.setItem('isSoundEnabled', state.isSoundEnabled);
  },
  initializeSound(state) {
    const isSoundEnabled = JSON.parse(localStorage.getItem('isSoundEnabled'));
    if(!isSoundEnabled) {
      state.isSoundEnabled = false;
      localStorage.setItem("isSoundEnabled", false);
    } else if(isSoundEnabled) {
      state.isSoundEnabled = true;
      localStorage.setItem("isSoundEnabled", true);
    } else {
      state.isSoundEnabled = true;
      localStorage.setItem("isSoundEnabled", true);
    }
  },
}

Excellent! Now, we can create a method inside any page or component which will commit our toggleSound mutation any time we click on a button to change their preference!

<template>
  <button @click="toggleSound">
    Toggle my sound preference!
  </button>
</template>

<script>
export default {
  mounted() {
    this.$store.commit('initializeSound');
  },
  methods: {
    toggleSound() {
      this.$store.commit('toggleSound');
    }
  },
  computed: {
    isSoundEnabled() {
      return this.$store.state.isSoundEnabled;
    }
  }
}
</script>

Conditionally playing sounds

This is awesome! Now, any time a user interacts with a page element we wish to play sound from, we can first determine if the user has indicated they want to have sound enabled, and either play it or skip it entirely.

<template>
  <button @click="playSound">
    Play me!
  </button>
</template>

<script>
export default {
  data() {
    return {
      audio: null
    }
  },
  mounted() {
    this.$store.commit('initializeSound');
  },
  methods: {
    playSound() {
      if(this.isSoundEnabled) { 
        this.audio = new Audio(require('@/assets/sounds/zap.mp3'));
        this.audio.play();
      }
    },
  },
  computed: {
    isSoundEnabled() {
      return this.$store.state.isSoundEnabled;
    },
  }
}
</script>

Wrapping up

As I said before, sound can be a great way to foster some truly unique interactions for your visitors.

This is just scratching the surface, but if you'd like a few more examples of unique sound interactions, be sure to check out Josh Comeau's or Jason Lengstorf's websites!

Thanks for reading, and if you enjoyed it please don't hesitate to share on Twitter below!

5 Nuxt Modules to Use in Your Next Project

David Parks — Thu, 29 Oct 2020 00:00:00 +0000

Intro

The Nuxt team and community has recently released an expansive Nuxt Module Explorer which allows you to filer Nuxt modules by popularity, type, and Github stars.

Until I saw this explorer, I had no idea how robust the Nuxt Module ecosystem had become. I was able to find some really useful modules that I've used on this project and others.

The list can be pretty daunting (in an awesome way), so I figured I would boil it down to five that have helped me immensely. By no means are these the only ones I'd recommend, just five that I think are great!

TL:DR: Just show me the modules!

1. Nuxt/Content

When building this site, I knew I needed to find a headless CMS to manage my content. I wanted to author my content in Markdown, interpolate Vue components, and be able to commit it to version control. Nuxt content has all of this, and more!

Some of the nicest features I've found are:

The ability to inject any variables into the article using a YAML front matter
The automatic injection createdAt, updatedAt, and toc (table of contents) variables to use
"Double click" to edit directly on the page, and see changes reflected immediately
Ability to interpolate Vue components directly into your markdown

There's much more to this module, but I can't recommend it enough!

2. Nuxt/Tailwind

If you are involved in Front-end web development, you've probably heard of TailwindCSS. If you aren't familiar, it's a "utility-first" CSS framework with endless amounts of customization and thoughtful defaults. If you're like me, you know that once you've tried it you can't go back.

This module makes it extremely easy to get Tailwind up and running with your Nuxt project, and allows you to reference the Tailwind config directly in your app. It also plays very nicely with Dark Mode and our next module in the list...

3. Nuxt/Color-Mode

This module makes it incredibly easy to detect the users preferred color scheme when they first visit, or toggle and save their choice for subsequent page visits. It also plays very nicely with Nuxt/Tailwind.

You can read $colorMode.preference directly in your templates or components, and render different content based on their current preference, and changing their color-mode preference is as easy as calling a toggle function like this:

<template>
  <button @click="toggleColorMode">Toggle Color Mode</button>
</template>

<script>
export default {
  methods: {
    toggleColorMode() {
      this.$colorMode.preference = this.$colorMode.value == "light" ? "dark" : "light";
    }
  }
}
</script>

4. Nuxt/Cloudinary

One of the easiest ways to improve your websites performance is through image optimizations. Nuxt/Cloudinary makes this trivial.

Cloundinary is a solution for managing image and video content (with a very generous free plan). The service provides the ability to optimize images on the fly with powerful transformations and even the ability to add text overlays to images.

Maya Shavin maintains this amazing Module that almost feels like magic. The module injects a Cloudinary Instance ($cloudinary) into your Nuxt project which you can use to do some really powerful stuff.

You can fetch images or videos stored in your Cloudinary instance and perform transformations

const url = this.$cloudinary.image.url('sample', { crop: 'scale', width: 200 })

You can even fetch remote images and perform the very same transformations

const url = this.$cloudinary.image
              .fetchRemote(
                'https://icatcare.org/app/uploads/2018/07/Thinking-of-getting-a-cat.png',
                { crop: 'scale', width: 200 })

The module also provides some ready-made Vue components that you can use anywhere in your templates. It's truly magic!

5. Nuxt/feed

This module helps you generate an RSS, Atom or JSON feed from your website's content!

You may be thinking, do people still use RSS feeds? Well Chris Coyier (founder of CSS Tricks & CodePen) does!

Who’s gonna read your personal blog because it has an RSS feed? I’m gonna read your personal blog because it has an RSS feed. pic.twitter.com/mtcyKhEVet
— Chris Coyier (@chriscoyier ) January 7, 2020

The main reason why this is so awesome for me, is that if you decide to crosspost to a platform like Dev.to, you can actually provide your RSS feed URL and have all of your content become drafts which you can immediately publish. It's a well known fact that cross-posting content that is originally published on your site can do wonders for your SEO rankings (provided you define a proper canonical URL for your content).

Also, if you are using Nuxt Content, you can generate a feed using a few methods described in the official documentation!

Wrapping up

Like I said before, there are tons of modules that are amazing, these are just five that I really like.

As of this blog's writing, there are currently 146 Nuxt Modules available for use on modules.nuxtjs.org (and more that simply need to be merged into the site). Go ahead and take a look and find something that sounds interesting or helpful.

Have fun exploring the awesome world of Nuxt modules!

Thanks for reading.

This article was originally posted on my website

Build a Like Counter With Fauna, Netlify and Nuxt

David Parks — Mon, 26 Oct 2020 18:10:29 +0000

Intro

When I was building this website, I constantly sought inspiration from some people involved in tech that I follow and look up to. One of these people is Josh Comeau (@joshwcomeau on Twitter).

On his website, I read an awesome blog titled Building a Modern-Day Hit Counter that shed some light on how powerful serverless functions in tandem with FaunaDB can be on Jamstack sites.

While his post dealt mainly with React/Gatsby, I wanted to use some of those serverless concepts and code he provided to create a "like" counter (in my case a "voltage" counter) on every blog post as a cool little detail (very similar to Josh's "heart" counter on his blog posts). I'll also be re-using and extending some of his code so I would like to give him credit!

The aim of this post is to get you setup using Netlify functions and FaunaDB, and to show you how you can leverage these tools to build a dynamic "like" counter for your personal Nuxt blog.

If you aren't familiar with Fauna, it's a low-latency serverless cloud database with a GraphQL API. We're going to be using it to store "like" counts for each of our blog posts using our blogs slug as the unique identifier.

Setup

Before we begin, we'll need to make sure that we have a Fauna account setup to handle storing and retrieving data, as well as a Netlify account where we'll be deploying our application and bundled serverless functions.

Also, you'll need to pick a headless CMS that you prefer to manage your blog content. I personally use Nuxt Content, but as long as you can leverage or define a unique slug for each blog post you will be fine!

Fauna

Once you've created a Fauna account, you'll want to login and create a new database for your project.

After setting up our database, we'll also need to create a collection which will store the likes for each of our blog posts. Go ahead and create one named "likes".

In order to successfully query our database, we'll also need to setup an Index. Indexes allow us to query documents on document attributes rather than document references, which will be important when we fetch and update our corresponding likes using the blogs slug.

Feel free to read up on Indexes over at Fauna's official documentation, as we're barely scratching the surface of how powerful they are.

Go ahead and create an index named likes_by_slug using our likes collection as the source collection, and data.slug being one of our terms which can be searched.

Amazing! We are almost there. Now we need to generate an API key that we can use in our Nuxt project to securely query our Fauna database. Navigate to the Security section in your Fauna dashboard and generate a new admin key.

We'll be referencing this key using the FAUNA_SECRET_KEY environment variable.

Nuxt

Great! We've got Fauna all setup. Now we can hop over to our Nuxt project and start to pull in some dependencies we'll need to get started.

Go ahead and install the Fauna npm package.

# install using npm
npm install --save faunadb

# install using yarn
yarn add faunadb

We'll also be using Axios to handle our API requests, so go ahead and install the Nuxt module:

# install using npm
npm install @nuxtjs/axios

# install using yarn
yarn add @nuxtjs/axios

And add it to your nuxt.config.js file:

export default {
  modules: ['@nuxtjs/axios']
}

Also, create a .env file in your project's root and pull in your Fauna API Key that you generated earlier

BASE_URL=YOUR_PROD_URL
FAUNA_SECRET_KEY=YOUR_KEY

Great! Lastly, we can now use our BASE_URL environment variable to get Axios setup for both local development and our production deployment.

We'll be using Nuxt's Runtime Config to handle setting our Axios Options. Add this line to your nuxt.config.js file:

export default {
  publicRuntimeConfig: {
    axios: {
      baseURL: process.env.NODE_ENV === 'production' ? process.env.BASE_URL || 'http://localhost:8888/' : 'http://localhost:8888/',
    }
  },
}

When I run my Netlify project locally using Netlify Dev, I run it on port 8888. In order to not have issues when we try to test our serverless functions, we need to tell Axios to call via port 8888, or whatever port you'd like when in local development.

Netlify

If you aren't familiar with Netlify functions, they're essentially Netlify's wrapper on top of AWS Lambda (with a very generous free-tier). To keep it simple, they're fully managed and auto-scaling serverless functions that just work with your Netlify projects.

In order to make sure that our deployed site can successfully query our Fauna database, we'll need to navigate to Netlify and add the environment variables that we defined earlier, so they will be available to our application when we deploy it!

You should also check out Netlify Dev which will allow you to test your functions locally before deployment. This can save you lots of time when debugging your functions and UI. It's a bit of a process so I won't cover it, but definitely recommend getting the Netlify CLI setup and linking your site to your project!

Excellent! We are now completely done with setting up the pieces we need.

We have Fauna to handle our "likes" storage, Netlify Functions to handle updating and retrieving that data via Axios, a Headless CMS of our choice, and of course, Nuxt!

Time to dive into some code!

Writing our functions

Our needs for these functions can be broken down into two pieces.

We need to fetch the current likes of a blog on page load
We need to be able to increment these likes when a user clicks on our "like" counter

Fetching likes function

We'll start with the one that will fetch our blogs like count on page load (or component mount).

Go ahead and create a folder in the root of your Nuxt project called functions. Netlify will automatically look here for any serverless functions each time you deploy.

Create a file called fetch_likes_for_blog.js inside of the functions folder.

// Credit to Josh Comeau 
const faunadb = require('faunadb');
exports.handler = async (event) => {
  const q = faunadb.query;
  const client = new faunadb.Client({
    secret: process.env.FAUNA_SECRET_KEY,
  });

  const { slug } = event.queryStringParameters;
  if (!slug) {
    return {
      statusCode: 400,
      body: JSON.stringify({
        message: 'Article slug not provided',
      }),
    };
  }

  const doesDocExist = await client.query(
    q.Exists(q.Match(q.Index('likes_by_slug'), slug))
  );

  if (!doesDocExist) {
    await client.query(
      q.Create(q.Collection('likes'), {
        data: { slug: slug, likes: 1 },
      })
    );
  }

  const document = await client.query(
    q.Get(q.Match(q.Index('likes_by_slug'), slug))
  );

  return {
    statusCode: 200,
    body: JSON.stringify({
      likes: document.data.likes,
    }),
  };
};

Let's run through it.

First, we are initializing our Fauna client with the secret key we generated earlier
We are checking if the blog slug is provided as a query parameter, if not we return 400
We check if the document in Fauna already exists
If it does not exist, we create a new document within our likes collection and set the initial likes to 1 using our slug as the unique identifier
We query the likes_by_slug index we created earlier using our slug to retrieve the current likes
We return the likes of the blog

Incrementing likes function

This function is extremely similar to the fetch function, except for the fact that we need to increment the existing like count before we return it to the client.

This is the function that we'll be calling when a user interacts with whatever icon/button we want to use to handle liking the blog post.

Create a new file in your functions directory called register-like.js

// Credit to Josh Comeau
const faunadb = require('faunadb');
exports.handler = async (event) => {
  const q = faunadb.query;
  const client = new faunadb.Client({
    secret: process.env.FAUNA_SECRET_KEY,
  });

  const { slug } = event.queryStringParameters;
  if (!slug) {
    return {
      statusCode: 400,
      body: JSON.stringify({
        message: 'Article slug not provided',
      }),
    };
  }

  const doesDocExist = await client.query(
    q.Exists(q.Match(q.Index('likes_by_slug'), slug))
  );

  if (!doesDocExist) {
    await client.query(
      q.Create(q.Collection('likes'), {
        data: { slug: slug, likes: 1 },
      })
    );
  }

  const document = await client.query(
    q.Get(q.Match(q.Index('likes_by_slug'), slug))
  );

  await client.query(
    q.Update(document.ref, {
      data: {
        likes: document.data.likes + 1,
      },
    })
  );

  return {
    statusCode: 200,
    body: JSON.stringify({
      likes: document.data.likes,
    }),
  };
};

As you can see, the code is essentially the same except for the fact that after we query the index, we then run an update on our document and increment the likes by 1.

Using our functions in Nuxt

When we end up deploying our application, they will be available to us at the path: /.netlify/functions/NAME_OF_FUNCTION.

In my case, I created a VoltBatteryCounter component that I plug into the sides of my dynamic blog pages in pages/blog/_slug.vue. In this component, I am passing the slug to the function by utilizing this.$route.params.slug.

Since I am using Nuxt's static mode, I am leveraging the fetch hook with fetchOnServer: false set in order to ensure that the hook is called each time the component is mounted and not only once during build.

<script>
export default {
  data() {
    return {
      initialLikes: null,
    }
  },
  async fetch() {
    const { data } = await this.$axios.get(`/.netlify/functions/fetch_likes_for_blog?slug=${this.$route.params.slug}`);
    this.initialLikes = data.likes;
  },
  fetchOnServer: false,
}
</script>

And then, whenever a user clicks on the Battery I have positioned to the right of my blog post, I will use Axios that we setup earlier to call our servleress function to increment the like count.

<script>
export default {
  data() {
    return {
      initialLikes: null,
    }
  },
  async fetch() {
    const { data } = await this.$axios.get(`/.netlify/functions/fetch_likes_for_blog?slug=${this.$route.params.slug}`);
    this.initialLikes = data.likes;
  },
  fetchOnServer: false,
  methods: {
    addLike() {
      this.initialLikes++;
      this.incrementLikes();
    },
    async incrementLikes() {
      await this.$axios.post(`/.netlify/functions/register-like?slug=${this.$route.params.slug}`);
    }
  },
}
</script>

You might be wondering though, what if somebody decides to just spam my like button thousands of times and completely eat up my free-tier of functions?

There are a few routes you could go with this. One of which would be to introduce some local state like userLikeCount along with a computed property called likesMaxed which only allows a user to increment the counter up to 12 times or so. Ex:

<script>
export default {
  data() {
    return {
      initialLikes: null,
      userLikeCount: 0,
    }
  },
  async fetch() {
    const { data } = await this.$axios.get(`/.netlify/functions/fetch_likes_for_blog?slug=${this.$route.params.slug}`);
    this.initialLikes = data.likes;
  },
  fetchOnServer: false,
  methods: {
    addLike() {
      if(!likesMaxed) {
        this.initialLikes++;
        this.userLikeCount++;
        this.incrementLikes();
      }
    },
    async incrementLikes() {
      await this.$axios.post(`/.netlify/functions/register-like?slug=${this.$route.params.slug}`);
    }
  },
  computed: {
    likesMaxed() {
      return this.userLikeCount >= 12;
    },
  },
}
</script>

However, the user could simply reload the page and increment the counter another 12 times.

In my case, I decided to use localStorage to ensure that users could only increment the like count a maximum of 12 times per blog post which would persist on subsequent page visits (Credit to Lucie for the idea!)

Storing Likes in Local Storage

Start by creating a file called index.js from within your store directory in your Nuxt project.

export const state = () => ({
  storedUserLikes: 1
})

export const mutations = {
  initializeLikes(state, slug) {
    const storedLikes = Math.abs(Number(localStorage.getItem(slug)));

    if(storedLikes) {
      storedLikes >= 12 ? state.storedUserLikes = 12 : state.storedUserLikes = storedLikes;
    } else {
      localStorage.setItem(slug, 1);
      state.storedUserLikes = 1;
    }
  },
  incrementLikes(state, slug) {
    state.storedUserLikes = state.storedUserLikes + 1;
    localStorage.setItem(slug, state.storedUserLikes);
  }
}

First I am initializing the likes on the page by reading from the local storage the associated count.

I'm also adding in some checks to get the absolute value in case a user edits it to be a negative number, allowing them to click infinitely, as well as determine if the number is greater than 12 to only set the storedLikes to 12.

Now, we can extend our previous code to utilize this new piece of global state.

<script>
export default {
  data() {
    return {
      initialLikes: null,
      userLikeCount: 0,
    }
  },
  async fetch() {
    const { data } = await this.$axios.get(`/.netlify/functions/fetch_likes_for_blog?slug=${this.$route.params.slug}`);
    this.initialLikes = data.likes;
  },
  mounted() {
    this.$store.commit('initializeLikes', this.$route.params.slug);
  },
  fetchOnServer: false,
  methods: {
    async addLike() {
      if(this.storedUserLikes < 12) {
        this.initialLikes++;
        this.$store.commit('incrementLikes', this.$route.params.slug);
        this.incrementLikes();
      }
    },
    async incrementLikes() {
      await this.$axios.post(`/.netlify/functions/register-like?slug=${this.$route.params.slug}`);
    }
  },
  computed: {
    likesMaxed() {
      return this.userLikeCount >= 12;
    },
    storedUserLikes() {
      return this.$store.state.storedUserLikes;
    }
  }
}
</script>

We start by calling our Vuex mutation initializeLikes in the mounted() hook since localStorage becomes available to us then, then we use a computed property storedUserLikes to retrieve the likes from our store for that blog (if any exist).

Awesome! We now have a like counter that is persistent across multiple sessions and page visits. It's up to you how you want to render the like count so use your imagination! If you'd want to do something similar to my battery, feel free to check out my source code on Github, as I've decided to open source my site.

If you'd prefer a more traditional "like button" look, here is a simple one with Tailwind to get you started!

<template>
  <button @click="addLike" class="focus:outline-none" :class="{'text-red-600' : likesMaxed}">
    {{initialLikes}}
    <svg class="w-6 h-6" fill="none" stroke="currentColor" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4.318 6.318a4.5 4.5 0 000 6.364L12 20.364l7.682-7.682a4.5 4.5 0 00-6.364-6.364L12 7.636l-1.318-1.318a4.5 4.5 0 00-6.364 0z"></path></svg>
  </button>
</template>

Wrapping up

If you've made it this far, good job! I can't wait to (hopefully) see some more dynamic like counters on statically generated Nuxt sites in the future.

If you do decide to implement one, let me know on Twitter! I'd love to see what you come up with.

Thanks for reading!

This article was originally posted on my blog

Social Share Images in Nuxt Content

David Parks — Tue, 13 Oct 2020 15:15:53 +0000

Intro

When sharing blog content or articles on social media it's important to stand out. In a sea of Twitter posts users might simply scroll by something you've worked hard on if it isn't eye catching enough! In this post, we'll teach you how to generate beautiful sharing cards for your Nuxt Content blog posts!

This post will use concepts laid out in Jason Lengstorfs amazing article where he details how to generate images for posts using Cloundinary's API and a custom template, however we'll be more focused on getting this going with Nuxt Content! I would recommend going and reading his post before continuing, as you will need to setup your own template from within Cloundinary, as well as upload any custom fonts you want to use for your template.

Setup

This post won't go into too much detail about setting up a Nuxt Content blog from scratch, but it goes without saying make sure you have the @nuxt/content package installed and added to your nuxt.config.js modules like so:

modules: [
  '@nuxt/content',
],

In order to begin generating dynamic social media cards, we will also need to install Jason Lengstorf's package @jlengstorf/get-share-image.

# install using npm npm install 
--save @jlengstorf/get-share-image 
# install using yarn 
yarn add @jlengstorf/get-share-image

Once you've gotten everything installed and your template uploaded to Cloudinary, it's time to begin generating your images!

Fetch Blog & Generate Image

From within a dynamic page component in Nuxt (my blog pages are in /blog/_slug.vue) we'll need to use the asyncData Nuxt hook due to the fact that this is called before the head method where we'll need to set our Open Graph and Twitter metadata for the post.

We're going to start by importing getShareImage from '@jlengstorf/get-share-image' and then calling this function from within asyncData after fetching the article for our specific page.

<script>
import getShareImage from '@jlengstorf/get-share-image';

export default {
  async asyncData({ $content, params }) {
    const article = await $content('blogs', params.slug).fetch()

    const socialImage = getShareImage({
        title: article.title,
        tagline:  article.subtitle,
        cloudName: 'YOUR_CLOUDINARY_NAME',
        imagePublicID: 'YOUR_TEMPLATE_NAME.png',
        titleFont: 'unienueueitalic.otf',
        titleExtraConfig: '_line_spacing_-10',
        taglineFont: 'unienueueitalic.otf',
        titleFontSize: '72',
        taglineFontSize: '48',
        titleColor: 'fff',
        taglineColor: '6CE3D4',
        textLeftOffset: '100',
        titleBottomOffset: '350',
        taglineTopOffset: '380'
      });

    return { article, socialImage }
  }
}
</script>

The getShareImage function will generate an image URL via Cloudinary using the specified text, transformations, colors and fonts.

For example, my URL for this post is

https://res.cloudinary.com/dzxp4ujfz/image/upload/w_1280,h_669,c_fill,q_auto,f_auto/w_760,c_fit,co_rgb:fff,g_south_west,x_100,y_350,l_text:unienueueitalic.otf_72_line_spacing_-10:Dynamic%20Social%20Media%20Preview%20Cards%20in%20Nuxt%20Content/w_760,c_fit,co_rgb:6CE3D4,g_north_west,x_100,y_380,l_text:unienueueitalic.otf_48:Beautiful%20social%20sharing%20cards%20for%20your%20Nuxt%20Content%20blogs/template_oxlcmb.png

Since I've created my own template, and included my own font, my settings may be different than yours when setting the textLeftOffset or any other offsets for example. Feel free to check out Jason Lengstorf's Figma template available here and customize it your liking.

Setting meta tags

Great, we are generating our image via dynamic Nuxt Content article attributes! Now how do we inject these variables into our blog pages head so that social media users will see our image and metadata?

To do this, we'll leverage Nuxt.js' built in head method that allows us to set Open Graph and Twitter meta tags. We'll also include some useful information like the time the article was published, and the last time it was modified using the createdAt and updatedAt properties that Nuxt Content automatically injects for us.

<script>
import getShareImage from '@jlengstorf/get-share-image';
import getSiteMeta from "~/utils/getSiteMeta.js";

export default {
  async asyncData({ $content, params }) {
    const article = await $content('blogs', params.slug).fetch()

    const socialImage = getShareImage({
        title: article.title,
        tagline:  article.subtitle,
        cloudName: 'YOUR_CLOUDINARY_NAME',
        imagePublicID: 'YOUR_TEMPLATE_NAME.png',
        titleFont: 'unienueueitalic.otf',
        titleExtraConfig: '_line_spacing_-10',
        taglineFont: 'unienueueitalic.otf',
        titleFontSize: '72',
        taglineFontSize: '48',
        titleColor: 'fff',
        taglineColor: '6CE3D4',
        textLeftOffset: '100',
        titleBottomOffset: '350',
        taglineTopOffset: '380'
      });

    return { article, socialImage }
  },
  computed: {
    meta() {
      const metaData = {
        type: "article",
        title: this.article.title,
        description: this.article.description,
        url: `https://davidparks.dev/blog/${this.$route.params.slug}`,
        mainImage: this.socialImage,
      };
      return getSiteMeta(metaData);
    }
  },
  head() {
    return {
      title: this.article.title,
      meta: [
        ...this.meta,
        {
          property: "article:published_time",
          content: this.article.createdAt,
        },
        {
          property: "article:modified_time",
          content: this.article.updatedAt,
        },
        {
          property: "article:tag",
          content: this.article.tags ? this.article.tags.toString() : "",
        },
        { name: "twitter:label1", content: "Written by" },
        { name: "twitter:data1", content: "David Parks" },
        { name: "twitter:label2", content: "Filed under" },
        {
          name: "twitter:data2",
          content: this.article.tags ? this.article.tags.toString() : "",
        },
      ],
      link: [
        {
          hid: "canonical",
          rel: "canonical",
          href: `https://davidparks.dev/blog/${this.$route.params.slug}`,
        },
      ],
    };
  }
}
</script>

You have noticed above that I am importing getSiteMeta from "~/utils/getSiteMeta.js". This is a utility function that I use to overwrite default meta tags. We will use a computed property to override some default metadata values I've setup in this file if they are explicitly provided. This ensures we are injecting the proper variables from our Nuxt Content Markdown file into our head. That file looks like this:

const type = "website";
const url = "https://davidparks.dev";
const title = "David Parks";
const description = "David Parks is a Front-end Developer from Milwaukee, Wisconsin. This blog will focus on Nuxt.js, Vue.js, CSS, Animation and more!";
const mainImage = "https://davidparksdev.s3.us-east-2.amazonaws.com/template.png";
const twitterSite = "@dparksdev";
const twitterCard = "summary_large_image"
export default (meta) => {
  return [
    {
      hid: "description",
      name: "description",
      content: (meta && meta.description) || description,
    },
    {
      hid: "og:type",
      property: "og:type",
      content: (meta && meta.type) || type,
    },
    {
      hid: "og:url",
      property: "og:url",
      content: (meta && meta.url) || url,
    },
    {
      hid: "og:title",
      property: "og:title",
      content: (meta && meta.title) || title,
    },
    {
      hid: "og:description",
      property: "og:description",
      content: (meta && meta.description) || description,
    },
    {
      hid: "og:image",
      property: "og:image",
      content: (meta && meta.mainImage) || mainImage,
    },
    {
      hid: "twitter:url",
      name: "twitter:url",
      content: (meta && meta.url) || url,
    },
    {
      hid: "twitter:title",
      name: "twitter:title",
      content: (meta && meta.title) || title,
    },
    {
      hid: "twitter:description",
      name: "twitter:description",
      content: (meta && meta.description) || description,
    },
    {
      hid: "twitter:image",
      name: "twitter:image",
      content: (meta && meta.mainImage) || mainImage,
    },
    { 
      hid: "twitter:site",
      name: "twitter:site", 
      content: (meta && meta.twitterSite) || twitterSite,
    },
    { 
      hid: "twitter:card",
      name: "twitter:card", 
      content: (meta && meta.twitterCard) || twitterCard,
    }
  ];
};

Unless there are overrides explicitly provided, it will use the fallback values I've defined at the top of this file. This is great if you want to avoid those cases where you forget to set meta tags!

The computed property meta is then being merged into the head method via a spread operator ...this.meta,. This will ensure that any default values are overridden and your article title, description and images are properly injected inside of your documents head.

Testing with Facebook & Twitter Tools

If all goes well, you should now see these meta tags in your DOM!

The next time your site deploys, you should now see an awesome looking share image when sharing your blog to Twitter, Facebook, Linkedin or anywhere else! Using tools like Twitter's Card Debugger and Facebook's Open Graph Debugger will be essential to tweaking them to your liking and debugging any potentially missing tags.

Wrapping Up

What's great about this approach is that if you decide at some point in the future to update or change your template for your blogs, it will update the preview image for all of them. It also saves you the time and headaches of creating unique preview images for each individual blog in Figma or a design tool of your choosing. Just set it, and forget it!

If you've made it this far, good job. I look forward to seeing some awesome Nuxt Content blogs with beautiful sharing cards on my feeds in the near future. Thanks for reading!

This blog was originally posted on my website

Nuxt Table of Contents With Active States

David Parks — Thu, 11 Jun 2020 00:00:00 +0000

Intro

When reading a blog post online, I've always really enjoyed a table of contents on the side of the page indicating the position you are in the article. To me, it's super helpful for gauging article length and assisting in navigation between topics.

Since I've decided to use the Nuxt Content module for this blog, I wanted to implement something that would indicate the active section of an article since the module injects the incredibly useful toc variable into every .md file in my content folder. This saves a ton of time and energy as you don't need to manually create a table of contents for every article!

This article will teach you how to create a sticky table of contents sidebar with active states based on your current scroll position using the Intersection Observer API and Nuxt Content!

If you'd prefer to jump right into the code, check out the Code Sandbox I've prepared below which mirrors what we'll be implementing.

Setup

Thankfully, this implementation requires very little setup. We just need to initialize a Nuxt project, install Nuxt Content & Nuxt Tailwind (optional), and we're set!

Go ahead and install Nuxt Content and Nuxt Tailwind in your Nuxt project and add the modules to your nuxt.config.js file:

export default {
  modules: ["@nuxt/content"],
  buildModules: ["@nuxtjs/tailwindcss"]
};

Since Intersection Observer is supported by almost every browser (sorry IE users 😭) we can leverage this extremely powerful API to handle detecting when an element scrolls into our viewport! No installation needed!

You will need to ensure that you have a content directory in the root of your project that contains some Markdown files you wish to use. Feel free to use my sample file in Codesandbox as a reference for tweaking the content to your liking.

The Intersection Observer API can also be used to do some really powerful stuff like lazy-loading images, as well as implementing some infinite scroll techniques. It's worth digging into and seeing if it can be a solution to a use-case you need!

Let's go ahead and fetch our blog from our index.vue page. Assuming our markdown file is called main.md inside of the /content directory.

On a blog site, you'd typically want to fetch the post from a dynamic page using the blogs slug as a parameter, but for the sake of brevity we'll focus on the table of contents functionality we're after.

<script>
export default {
  async asyncData({ $content }) {
    const article = await $content("main").fetch();

    return {
      article
    };
  }
};
</script>

And then let's setup up our template, having a section for the article content and one where we will render our table of contents looping through the automatically injected toc variable into our article.

<template>
  <div class="p-4 bg-gray-100 grid grid-cols-3 gap-4">
    <div class="prose lg:prose-lg col-span-2">
      <nuxt-content ref="nuxtContent" :document="article" />
    </div>
    <aside class="col-span-1 lg:flex lg:flex-col">
      <div class="sticky top-16">
        <h2
          class="uppercase text-black font-h2 text-lg lg:mt-16 tracking-wider"
        >
          Table of contents
        </h2>
        <nav class="mt-4">
          <ul>
            <li
              :class="{
                'pl-4': link.depth === 3
              }"
              class="toc-list"
              v-for="link of article.toc"
              :key="link.id"
            >
              <a
                role="button"
                class="transition-colors duration-75 text-base mb-2 block"
                :href="`#${link.id}`"
                >{{ link.text }}</a
              >
            </li>
          </ul>
        </nav>
      </div>
    </aside>
  </div>
</template>

<script>
export default {
  async asyncData({ $content }) {
    const article = await $content("main").fetch();

    return {
      article
    };
  }
};
</script>

Intersection Observer

Beautiful! Since Nuxt Content handles automatically adding ids to each of the headings in our articles, we can use this to our advantage in our pages mounted hook to utilize document.querySelectorAll and only target our Nuxt Content's article h2 and h3 elements that have ids associated, and "watch" these using the Intersection Observer API to determine when they scroll into view.

Let's go ahead and add the following code to our mounted hook and our page data.

<script>
export default {
  data() {
    return {
      currentlyActiveToc: "",
      observer: null,
      observerOptions: {
        root: this.$refs.nuxtContent,
        threshold: 0
      }
    };
  },
  mounted() {
    this.observer = new IntersectionObserver(entries => {
      entries.forEach(entry => {
        const id = entry.target.getAttribute("id");
        if (entry.isIntersecting) {
          this.currentlyActiveToc = id;
        }
      });
    }, this.observerOptions);

    // Track all sections that have an `id` applied
    document
      .querySelectorAll(".nuxt-content h2[id], .nuxt-content h3[id]")
      .forEach(section => {
        this.observer.observe(section);
      });
  },
  beforeDestroy() {
    this.observer.disconnect();
  }
};
</script>

There's lots happening here so let's break it down.

First, we need to track the currentlyActiveToc item we scroll by in order to add some active styles to the table of contents item, as well as setup our observer object which we will use for tracking the h2 and h3 HTML elements that scroll into our viewport, so let us define some data properties to track those.

Also, we need to initialize our IntersectionObserver with a set of options (in my case observerOptions) that define when our observers callback is invoked.

I've set a ref on our nuxt-content article as the root for our observer, and a threshold of 0, which means that as soon as even one pixel is visible, the callback will fire. This is obviously up to you to tweak to your liking!

If you'd prefer to be 50% of the way through the viewport when observing the element, you would use a threshold value of 0.5.

In mounted we are initializing our observer which loops through each of our entries (article headings), and determines that if the entry is currently intersecting with our viewport, we set the headings id as the currentlyActiveToc.

We are also using document.querySelectorAll targeting our .nuxt-content article and get the DOM elements that are either h2 or h3 elements that have IDs, and observe those using our previously initialized IntersectionObserver.

Finally, we are disconnecting our observer in the beforeDestroy hook and informing our observer to no longer track these headings when we navigate away.

Phew! That was a lot. But once you let it sink in, you can see how powerful this API is. No longer do you need to fiddle with the scrollY position of the window compared with the element, you can simply determine which items to observe and apply some logic based on the items position in the viewport.

Applying active styles

Let's go ahead and edit our template to apply active styles to the currentlyActiveToc element in our Table of Contents sidebar.

<template>
  <div class="p-4 bg-gray-50 grid grid-cols-3 gap-4">
    <div class="prose lg:prose-lg col-span-2">
      <nuxt-content ref="nuxtContent" :document="article" />
    </div>
    <aside ref="toc" class="col-span-1 lg:flex lg:flex-col">
      <div class="sticky top-16">
        <h2
          class="uppercase text-black font-h2 text-lg lg:mt-16 tracking-wider"
        >
          Table of contents
        </h2>
        <nav class="mt-4">
          <ul>
            <li
              @click="tableOfContentsHeadingClick(link)"
              :class="{
                'pl-4': link.depth === 3
              }"
              class="toc-list"
              v-for="link of article.toc"
              :key="link.id"
            >
              <a
                :class="{
                  'text-red-500 hover:text-red-600':
                    link.id === currentlyActiveToc,
                  'text-black hover:gray-900': link.id !== currentlyActiveToc
                }"
                role="button"
                class="transition-colors duration-75 text-base mb-2 block"
                :href="`#${link.id}`"
                >{{ link.text }}</a
              >
            </li>
          </ul>
        </nav>
      </div>
    </aside>
  </div>
</template>

I've also decided to add a tableOfContentsHeadingClick method which passes the link to set the currentlyActiveToc as the link that was clicked in order to prevent those weird cases where another heading might be observed when you are jumping to that anchor link. This is entirely optional, but a nice failsafe in case things get weird (I'm still figuring this out too! Haha).

<script>
methods: {
  tableOfContentsHeadingClick(link) {
    this.currentlyActiveToc = link.id;
  },
}
</script>

Caveats & Wrap up

If you opt for scroll-behavior: smooth in your application, when you are smooth scrolling to the link you are clicking in the table of contents the items you scroll past will be "active" as you pass by them.

It's totally personal preference if you want this behavior or not, but it's something to consider.

Also, if you have "small" sections (a situation where the viewport can have multiple headings in the window), you could potentially be reading a different section than one that is active since it only tracks the last heading that has scrolled into the view.

I should also note, this solution is not only limited to Nuxt Content and Nuxt. In a traditional Vue SPA you could easily accomplish the same functionality with a Headless CMS of your choosing and alternative fetching method.

If you find a better solution, feel free to make a pull request (My blog is open source) or message me on Twitter!

Also, feel free to check out the Codesandbox embed I placed in the intro of this article if you want to play around with it or fork it.

Thanks for reading!