In this article, you’ll learn how to integrate this type of authorization with Permit.io in Nuxt.

Table of Contents

• Table of Contents

• What is the Difference Between Authentication and Authorization?

• What is Role Based Access Control (RBAC)?

• What are the Benefits of Using Authorization As A Service?

• What We’ll Be Building

• How to Plan RBAC with Permit.io

• How to Setup Permit.io in Nuxt

• How to Control API Access with Nuxt Middleware

• How to Test RBAC in the Community Dashboard

• Summary

What is the Difference Between Authentication and Authorization?

When building applications, we often carry out authentication together with authorization. However, these two concepts are essentially different.

Authentication is verifying who a user is. During the authentication process, the user usually needs to log in with some identifier like email, phone, username, with Google, with Microsoft, and so on.

Authorization specifies the resources an authenticated user can view and what they can do in the application. Authorization tells a user's access rights after that user has been successfully authenticated.

For example, authentication is a user logging in with email and password or verifying their phone number with SMS. On the other hand, authorization is a writer creating and editing posts while only admins can approve and publish those posts.

The primary purpose of authentication is to establish a user's identity before granting them access to the system. The main goal of authorization is to control user actions and protect sensitive data or resources.

What is Role Based Access Control (RBAC)?

Role-Based Access Control (RBAC) is an authorization model that you can use to manage and restrict access to system resources. It is based on the responsibilities, duties, or roles of users.

In RBAC, roles represent predefined sets of permissions that tell which actions a user can execute in an application. These roles are then assigned to users based on their job functions or responsibilities.

In common systems, anyone can assign permissions to individual users. In RBAC, we group permissions into roles. In turn, we assign these roles to users. For example, in a community dashboard, users might have roles like “Admin”, “Mentor”, or “Member”.

Aside from Role-Based Access Control, other popular authorization models exist such as Attribute-Based (ABAC) and Relationship-based (ReBAC) access controls. Attribute-Based Access Control uses a wide range of attributes and fits constantly changing systems. You could also combine it with Role-Based Access Control. For more info, see the Permit.io article on RBAC vs. ABAC.

What are the Benefits of Using Authorization As A Service?

You can build authorization models yourself in your application. But it may be time-consuming and cost-ineffective in the long run.

Using an external provider for authorization allows you to focus on the business logic in your applications. The benefits of outsourcing authorization are similar to using a third party like Auth0 or Firebase for Authentication.

Authorization as a Service provides a solution for managing user access and permissions in applications. When you use such an authorization solution, you enjoy enhanced security, granular access policies’ control, auto-scaling policies, reduced maintenance burden, faster upgrades, robust logging, and so on.

Permit.io is free to use for up to a 1000 Monthly Active Users, and has a UI and API for RBAC, ABAC, and ReBAC.

To Get Started with Permit.io:

• Go to app.permit.io

• Create an account

• Create a workspace (in your account)

What We’ll Be Building

A community dashboard connects members within a community or forum. It is a platform where they can interact and access resources.

For demo purposes of RBAC, we’ll build a simple community dashboard that will include 3 types of content (entities): posts, materials, and announcements.

The code we will be using is at https://github.com/obumnwabude/rbac-community-dashboard. It consists of a Nuxt repo with its server configured for API calls and its front end built with Vue. Clone it with git and explore the code in an editor/IDE.

In the server, we will expose GET, POST, and DELETE endpoints for each entity (posts, materials, and announcements). In Nuxt, you can use the HTTP verb in the file name for the endpoint handler. So we can have posts.get.ts*, posts.delete.ts, materials.post.ts,* and so on, with each file containing the respective handler for the involved API endpoint.

In addition, the server files store and retrieve entities from JSON files. You should have a robust database setup in your product. For this project, we’ll use local JSON files to build a minimum reproducible example with focus on roles and authorization.

In the front end, we have four pages: three for the entities and a settings page. There is also a simple navigation: a bottom bar on smaller screens and a sidebar on wider ones. Each entity page shows a list of its items and a small form to create new ones.

Furthermore, the demo code uses tailwindcss to style everything quickly. The settings page contains hardcoded user examples and roles for the demo. When testing, toggle the current user and see the roles in action.

This article focuses on the parts of the code that deal with authorization. For the backend and the UI specifics of the community dashboard, we will only overview them. After that, we will deep dive into RBAC touchpoints.

How to Plan RBAC with Permit.io

Overall, planning authorization means mapping out “who” can carry out an action on “what”. In RBAC, we define roles and then assign them to users. The roles and users combo is the “who” part of the authorization.

The “what” side refers to the entities or resources that your application provides or manages. For this article’s example, we’ve chosen our resources as Posts, Materials, and Announcements.

Actions are user activity. The most common actions are “create”, “read”, “update”, and, “delete”. Per resource in your application, you can use these four actions, add more, or omit some. In this article, our resources will each have all four actions.

When planning authorization, define resources alongside the “actions” users can execute on each resource. After that, define roles. For each role, specify what actions a user holding that role can carry out on each resource. The mapping of resources, actions, and roles allows you to define the authorization policies of your application.

Permit.io makes it easy to edit policies. In Permit.io, you have an intuitive dashboard where you can create resources and their actions, create roles, and merge both with policy tables.

For our Community Dashboard example, we will create three roles with incremental access: member, mentor, and admin. For each role, we’ll allow read access to all resources. However, each role has different management access levels to the resources as follows:

• Members can view all entities but can only create or delete posts.

• Mentors can view all entities and can create or delete posts and materials.

• Admins can create, view, and delete all entities.

Assigning roles to actions in resources is the same as editing policies.

How to Setup Permit.io in Nuxt

For our demo project, you need to run npm install, create a .env file, and export your Permit token.

However, if you are building a new project, to setup Permit in Nuxt, first install it with npm.

npm install permitio

After that, create a .env file and add your PERMIT_TOKEN. Get the token from the dashboard.

PERMIT_TOKEN=permit_key_XXXXXXXXXXXXXXXXXXXXX

To make this token available to the Nuxt runtimeConfig, add it to the nuxt.config.ts file. Also, add permitio (alongside other dependencies) in the transpile array of the build property of the Nuxt config file.

This addition is to account for Nuxt’s specific optimizations. Your nuxt.config.ts file should look like the following:

// https://nuxt.com/docs/api/configuration/nuxt-config
export default defineNuxtConfig({
  // ... other properties

  build: {
    transpile: ['axios', 'permitio', 'pino']
  },
  runtimeConfig: {
    permitToken: process.env.PERMIT_TOKEN
  }
});

After these, Permit.io should be available to your server code in Nuxt. You can now use in it middleware code to check for permissions.

How to Control API Access with Nuxt Middleware

In simple terms, middleware is code that runs before a target handler. In Nuxt, you can add middleware for API endpoints by creating necessary files in a middleware directory contained in the top-level server directory.

Since we are dealing with permissions, we will name our middleware file permissions.ts. Here, you’ll check if a user is permitted to take an action on a given resource.

Permit.io makes this easy with a simple .check method that returns a Boolean indicating if the user is permitted.

await permit.check(user, action, resource);

For this simple example community dashboard, our middleware code will first try to determine the user and action from the request properties. The example code achieves that in crude ways. They are enough to explain the concept and you should use more robust industry-standard methods for this.

After that, in the example code below, we construct the Permit object using our permit token and the default public PDP (Policy-Decision-Point microservice)’s endpoint. The Permit PDP is open-source. If you wish, you can set up your local/personal PDP by following the steps here.

import { Permit } from 'permitio';

export default defineEventHandler(async (event) => {
  // Only check permissions if the request is a POST or DELETE request
  const { method, path } = event;
  if (method !== 'POST' && method !== 'DELETE') return;

  // Ensure authorization header is present
  let authorization = event.node.req.headers['authorization'];
  if (!authorization) throw new Error('Unauthorized');

  // Extract the user from the authorization header. This is for example
  // purposes only. In a real application, you would use a JWT library or
  // better authentication methods in your API.
  const user = authorization.split(' ')[1];
  if (!user) throw new Error('Unauthorized');

  // Extract the resource from the path. This is for example purposes only.
  let resource = path.split('/').reverse()[0]; // get the last part of the path
  resource = resource.slice(0, -1); // remove the trailing 's' 
  // Capitalize the first letter
  resource = resource.charAt(0).toUpperCase() + resource.slice(1);

  // Set the action on the resource from the request method. 
  // This is for example purposes only. In a real application, you would
  // have a more robust way to determine the action. 
  const action = method === 'POST' ? 'create' : 'delete';

  // Construct the Permit object. Use the token from runtime config.
  const config = useRuntimeConfig(event);
  const permit = new Permit({
    pdp: 'https://cloudpdp.api.permit.io',
    token: config.permitToken
  });

  // Check if the user is permitted to create the resource. 
  // If not, throw an error.
  const isPermitted = await permit.check(user, action, resource);
  if (!isPermitted) throw new Error('Unauthorized');
});

As you can see, if the Permit checker fails, an error will be thrown. This will make Nuxt to prevent unauthorized resource management in your system. Such separation of concerns is efficient, especially in Authorization.

How to Test RBAC in the Community Dashboard

The settings page works together with the stores/permissions.ts file to complete the flow in the front end. We hardcoded the roles and the “user IDs” to ease toggling and testing. You definitely won’t have this in a production application. You can integrate CASL for permission checks in a frontend.

In this demo community dashboard, the UI touchpoints only allow edits of entities for which the acting user has the right roles. In other words, you can only add or delete an entity if the current role in the settings page allows that. Let’s see this in action.

In the Permit.io dashboard, create three test users: “example-member”, “example-mentor”, and “example-admin”. Assign the respective roles to each user.

Start up the Nuxt app by running npm run dev. Visit localhost:3000 in your browser and explore the role-based authorization in the demo community dashboard.

You can see that when you set the Current User to admin, you can create and delete announcements, but when set to guest, you can only view entities and not manage them. With this, we’ve fully implemented authorization.

Summary

You can be more efficient in building your application by focusing on business logic and outsourcing crucial parts like authorization.

In this article, you learned how you can use an authorization solution (Permit.io) to implement Role-Based Access Control in a demo community dashboard with Nuxt. You can also use Permit in any other kind of application (not just community dashboards).

When planning authorization, define resources alongside the “actions” users can execute on each resource. After that, define roles as the permissions the users can have.

Cheers!

Laravel is built upon PHP, a popular web programming language that’s used in over 75% of websites on the web. So knowing how to use a framework like Laravel can help make you a sought-after developer – and it also makes building websites and applications more seamless.

Nuxt is a Vue.js framework used for building rich and interactive web applications. It lets you choose between different rendering modes depending on the application requirements you want to build. You can choose between building a fully server-rendered app or client-rendered app. Nuxt also offers a mixture of both rendering modes, making applications much more powerful, efficient, and interactive.

In this article, you'll learn how to build full-stack applications using Nuxt and Laravel by building a Book Library App. The app will comprise a library API that we'll build using Laravel and a frontend using Nuxt.

We’ll talk about:

• Installing and setting up Laravel
• Creating database models
• Migrations
• Controllers
• API Testing
• Form Validations
• Data Fetching in Nuxt

And more. Get ready, and let's dive in.

Table of Contents:

• Prerequisites
• How to set up Laravel on your machine

• How to build the Book Library API

  • Setting up our database
  • Creating our Book Model
  • Creating our Book Controller
  • Defining our API Routes
  • Testing our API
    • Creating a new book
    • Getting our list of books
    • Editing our book

• How to Build the Nuxt Frontend

• How to Integrate the Laravel API in the Frontend
  • Getting all books in our library
  • Creating a new book
  • Editing a book
  • Deleting a book
• Conclusion
• Resources

Prerequisites

1. PHP and Composer are installed on your local machine.
2. Node.js is installed on your local machine.
3. yarn or npm installed on your local machine (npm comes pre-installed with Node).
4. A text editor installed, like VSCode.
5. Basic knowledge of HTML, CSS, JavaScript, and the terminal.
6. Basic knowledge of PHP, Vue.js, and TypeScript.

How to Set Up Laravel on Your Machine

To begin the Laravel installation, open your terminal and bootstrap a new Laravel project using the command below:

composer create-project laravel/laravel library-api && cd library-api && code .

This command creates a new Laravel project in your directory. cd's into it, and open up VSCode using the code . command. (If you happen to be using a different editor, you can remove that command and open the directory manually).

To test your Laravel server and ensure everything works, let’s test the server by using the php artisan serve command in the terminal. This should make your API available on port 8000 and accessible in your browser.

Laravel Starter Application

How to Build the Book Library API

We will be creating a simple CRUD endpoint for our book library, that is the API should be able to achieve the following:

• Create new book entries
• Get a list of all the book entries in the database
• Edit previously added book entries
• Delete book entries from the database

Setting up the database

Laravel comes with a variety of databases you can use during development. By default, it automatically creates a configuration setup for MySQL. But for simplicity, we’ll be making use of a SQLite database in this tutorial.

Open the .env file in your root directory, change the DB_CONNECTION value from mysql to sqlite, and comment the remaining database configurations as you can see below:

Environmental Variables (available in .env file)

Laravel automatically helps create the SQLite database when the migrations command is run. We’ll do that in a bit after creating our database models.

Creating the Book model

When you're building backend APIs, a model acts as a template that’s used to set up your database tables. It contains high-level instructions for how the tables and columns should be created.

In Laravel, you can use the command below to create a Book model:

php artisan make:model Book -m

This creates your Book model in the app/models directory and also creates a new migration file for you in the database/migrations directory.

Navigate to the migrations directory and open the newly created migrations file. It should be in the format current_date_create_books_table.php like you can see below:

Default Migrations

Edit the up function and add the following content:

$table->string('title');
$table->string('author');
$table->string('isbn');
$table->date('published_date');
$table->text('cover_image')->nullable();
$table->foreignIdFor(User::class);

Your migrations file should look like this now:

Updated Migrations

In summary, you added new fields to be created for the Book tables. Title, author, and isbn all have a data type of string, while published_date and cover_image have data types of date and text, respectively.

You also made the cover_image nullable, that is the field can be left out whenever a new book entry is created.

Lastly, you imported the User class and made it a foreign key to your Book table, creating a many-to-one relationship with the User table.

Now, let’s create your tables by running the migrations file with the command below:

php artisan migrate

You should get a prompt in the terminal asking if you want to create your SQLite database before the migrations. Select yes and press enter to proceed with the migrations.

Once the migration has been run successfully, navigate to the Book model and paste in the following code:

 /**
* The attributes that are mass assignable.
*
* @var array<int, string>
*/

protected $fillable = [
    'user_id',
    'title',
    'author',
    'isbn',
    'published_date',
    'cover_image'
];

This will allow mass assignment when passing data into the model (passing the data as a whole instead of individually). Your Book model should look like this now:

Updated Book Model

Creating the Book controller

The controller is responsible for housing the business logic for any API being created. The implementation logic for how we want to perform any CRUD operations with the library API will live here.

Laravel also provides a command for you to make this easier for developers. Paste the command below in your terminal to create our book controller:

php artisan make:controller BookController

This should be accessible at app\Http\Controllers\BookController.php. Replace the content of your BookController class with the code snippet below:

<?php

namespace App\Http\Controllers;

use App\Models\Book;
use Carbon\Carbon;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Log;
use Illuminate\Support\Facades\Storage;


class BookController extends Controller
{
    public function store(Request $request)
    {
        $data = $request->validate([
            'title' => 'required|string',
            'author' => 'required|string',
            'isbn' => 'required|string|unique:books',
            'published_date' => 'required|string',
            'cover_image' => 'nullable|image|max:2048',
        ]);

        try {
            $published_date = Carbon::parse($data['published_date'])->toDateString();
            $data['published_date'] = $published_date;
            $data['user_id'] = 1; // Making the assumption the id of the user is 1 
        } catch (\Exception $e) {
            return response()->json(['Error' => 'Bad Request'], 400);
        }

        $book = new Book($data);

        if ($request->hasFile('cover_image')) {
            $coverImage = $request->file('cover_image');
            $coverImageName = time() . '.' . $coverImage->getClientOriginalExtension();
            $coverImage->move(public_path('images'), $coverImageName);
            $book->cover_image = $coverImageName;
        }

        $book->save();

        return response()->json(['message' => 'Book added successfully'], 201);
    }

    public function index()
    {
        $books = Book::all();

        return response()->json(['books' => $books], 200);
    }

    public function update(Request $request, $id)
    {
        $book = Book::findOrFail($id);
        $data = $request->all();

        try {
            $published_date = Carbon::parse($data['published_date'])->toDateString();
            $data['published_date'] = $published_date;
            $data['user_id'] = $book->user_id;
        } catch (\Throwable $th) {
            Log::error('Error ', $th);
            return response()->json(['Error' => 'Bad Request'], 400);
        }

        $book->update($data);

        if ($request->hasFile('cover_image')) {
            // Delete the previous cover image if it exists
            if ($book->cover_image) {
                Storage::delete('public/images/' . $book->cover_image);
            }

            $coverImage = $request->file('cover_image');
            $coverImageName = time() . '.' . $coverImage->getClientOriginalExtension();
            $coverImage->storeAs('public/images', $coverImageName);
            $book->cover_image = $coverImageName;
            $book->save();
        }

        return response()->json(['message' => 'Book updated successfully'], 200);
    }

    public function destroy($id)
    {
        $book = Book::findOrFail($id);

        // Delete the cover image if it exists
        if ($book->cover_image) {
            Storage::delete('public/images/' . $book->cover_image);
        }

        $book->delete();

        return response()->json(['message' => 'Book deleted successfully'], 200);
    }
}

Defining the API Routes

Routing is one of the most important parts of building an API. Routes serve as access points through which developers, clients, or any other services can access an API.

The Laravel router allows you to register any routes that correspond to any HTTP verb being requested.

Route::get($uri, $callback);
Route::post($uri, $callback);
Route::put($uri, $callback);
Route::patch($uri, $callback);
Route::delete($uri, $callback);
Route::options($uri, $callback);

Navigate to the routes/api.php file and create the following routes for your API:

Route::post('/books', [BookController::class, 'store']);
Route::get('/books', [BookController::class, 'index']);
Route::put('/books/{id}', [BookController::class, 'update']);
Route::delete('/books/{id}', [BookController::class, 'destroy']);

Testing the API

Now, it’s time to test your API and ensure all your endpoints are accessible and working as expected.

Run the Laravel server using the command below:

php artisan serve

You can test the API using any API client of your choice. We have quite a number of popular options to choose from – Postman, Insomnia, Thunder Client, and so on. I’ll be using Thunder Client here.

We’ll test for all CRUD operations in your API client by confirming if all your objectives for your API are met.

Creating a new book

Create book endpoint

Getting a list of books

Get books endpoint

Editing a book

Edit book endpoint

How to Build the Nuxt Frontend

Setting up a new Nuxt app is as simple as running the command below:

npx nuxi@latest init nuxt-library-frontend

Open the newly created project when you’re done installing all the dependencies and start the development server using this command:

npm run dev

Your Nuxt app should now be accessible on port 3000:

Nuxt Starter Page

This is what your frontend should look like at the end of the tutorial:

Sample of our completed application

I’ve created some boilerplate code to help with the Nuxt frontend setup. This will enable us to focus on the implementation logic for consuming the Laravel API rather than spending time setting things up and styling.

For knowledge's sake, I created the UI components for the app using shadcn-vue. It consists of an amazing collection of accessible, reusable UI components that you can customize to your taste. Check out the installation steps for more details on how easy it was to set up for the Nuxt app.

It also comes with an installation of the Tailwind CSS utility library that’ll we'll use for styling in this tutorial.

Clone the boilerplate setup from the GitHub repo here so we can get started.

Navigate to pages/index.vue and replace the content of the index page with this:

<template>
 <main class="bg-white p-10 min-h-screen">
   <div class="max-w-4xl mx-auto">
     <header class="flex justify-between items-center mb-20">
       <h1 class="font-semibold text-4xl">My Library</h1>
       <Button>Add New Book</Button>
     </header>


     <div v-if="isLoading">
       <p class="italic text-2xl font-medium text-center">Loading...</p>
     </div>
     <div class="mt-8">
       <div class="flex flex-col gap-8">
         <div class="flex gap-4" v-for="book in books">
           <div
             v-if="book.cover_image"
             class="rounded-lg w-32 h-44 flex items-center justify-center"
           >
             <NuxtImg
               :src="`${API_BASE_URL}/images/${book.cover_image}`"
               :alt="book.title"
               class="w-full h-auto"
             />
           </div>
           <div v-else class="bg-slate-300 rounded-lg w-32 h-44"></div>
           <div class="flex items-center justify-between flex-1">
             <div>
               <h3 class="font-medium text-xl mb-4">{{ book.title }}</h3>
               <p class="mb-2">
                 <span>by:</span>
                 <span class="italic"> {{ book.author }} </span>
               </p>
               <p>
                 <span>Published:</span>
                 {{ book.published_date }}
               </p>
             </div>
             <div class="actions flex gap-4">
               <Button>Edit</Button>
               <Button variant="destructive"> Delete </Button>
             </div>
           </div>
         </div>
       </div>
     </div>
   </div>
 </main>
</template>


<script lang="ts" setup>
import { API_BASE_URL } from "@/utils/constants";
import type { BookProps } from "@/utils/types";


const isLoading = ref(false);
const books = ref<BookProps[]>([]);
</script>

We’ll need to create a new folder called utils in your root project which will contain two files: constants.ts and types.ts. Paste the following code snippet in your constants.ts file:

export const API_BASE_URL = "http://localhost:8000";

And the following in your types.ts:

export interface BookProps {
     id?: number;
     title: string;
     author: string;
     isbn: string;
     published_date: string;
     cover_image?: string;
     user_id?: number;
     created_at?: string;
     updated_at?: string;
}

Save the pages/index.vue file. You should be able to see this result in your browser:

Scaffolding the library frontend with Nuxt

Now, we need to create a side drawer and a dialog for adding new books and deleting added books from the database, respectively.

Create a new file called BookDrawer.vue in the component's root and add the following code in there:

<script setup lang="ts">
import type { BookProps } from "@/utils/types";


type PickedProps = "title" | "author" | "isbn" | "published_date";
interface CustomBookProps extends Pick<BookProps, PickedProps> {
 cover_image?: string;
}


const props = defineProps<{ open: boolean; book?: BookProps }>();
const emit = defineEmits(["update:open", "refresh-data"]);


const isSubmitting = ref(false);
let form = reactive<CustomBookProps>({
 title: "",
 author: "",
 isbn: "",
 published_date: "",
 cover_image: undefined,
});


const onFileChange = async (e: any) => {
 form.cover_image = e.target.files[0];
};


const onSubmit = async () => {};


const closeDrawer = (openState: boolean) => emit("update:open", openState);
</script>


<template>
 <Sheet :open="open" @update:open="closeDrawer">
   <SheetContent class="w-full bg-white">
     <SheetHeader>
       <SheetTitle>
         <template v-if="book"> Edit Book </template>
         <template v-else>Add New Book</template>
       </SheetTitle>
       <SheetDescription>
         Make changes to your profile here. Click save when you're done.
       </SheetDescription>
     </SheetHeader>
     <div class="grid gap-4 py-4">
       <div class="grid grid-cols-4 items-center gap-4">
         <Label for="bookTitle" class="text-right"> Book Title </Label>
         <Input
           v-model:model-value="form.title"
           type="text"
           id="bookTitle"
           class="col-span-3"
           required
         />
       </div>
       <div class="grid grid-cols-4 items-center gap-4">
         <Label for="author" class="text-right"> Author </Label>
         <Input
           v-model:model-value="form.author"
           type="text"
           id="author"
           class="col-span-3"
           required
         />
       </div>
       <div class="grid grid-cols-4 items-center gap-4">
         <Label for="isbn" class="text-right"> ISBN </Label>
         <Input
           v-model:model-value="form.isbn"
           type="text"
           id="isbn"
           class="col-span-3"
           required
         />
       </div>
       <div class="grid grid-cols-4 items-center gap-4">
         <Label for="published_date" class="text-right">
           Published Date
         </Label>
         <Input
           v-model:model-value="form.published_date"
           type="date"
           id="published_date"
           class="col-span-3"
           required
         />
       </div>
       <div class="grid grid-cols-4 items-center gap-4">
         <Label for="cover_image" class="text-right"> Book Cover </Label>


         <Input
           type="file"
           @change="onFileChange"
           id="cover_image"
           class="col-span-3"
           required
         />
       </div>
     </div>
     <SheetFooter>
       <Button type="submit" @click="onSubmit">
         <template v-if="isSubmitting">Saving...</template>
         <template v-else> Save changes </template>
       </Button>
     </SheetFooter>
   </SheetContent>
 </Sheet>
</template>

Create another file called DeleteBookDrawer.vue and add the following code content to it:

<script lang="ts" setup>
const emit = defineEmits(["refresh-data", "update:open"]);
const props = defineProps<{ open: boolean; book?: BookProps }>();
</script>


<template>
 <AlertDialog
   :open="open"
   @update:open="(openState) => $emit('update:open', openState)"
 >
   <AlertDialogContent>
     <AlertDialogHeader>
       <AlertDialogTitle>Are you absolutely sure?</AlertDialogTitle>
       <AlertDialogDescription>
         This action cannot be undone. This will permanently delete your book
         and remove your data from the server.
       </AlertDialogDescription>
     </AlertDialogHeader>
     <AlertDialogFooter>
       <AlertDialogCancel @click="$emit('update:open', false)"
         >Cancel</AlertDialogCancel
       >
       <AlertDialogAction>Continue</AlertDialogAction>
     </AlertDialogFooter>
   </AlertDialogContent>
 </AlertDialog>
</template>

Import the newly created files in your index page as you can see below:

<template>
 <main class="bg-white p-10 min-h-screen">
    ...

   <BookDrawerDialog
     v-if="isBookDrawerOpen"
     :open="isBookDrawerOpen"
     @update:open="(open: boolean) => isBookDrawerOpen = open"
     :book="currentBook"
     @refresh-data="fetchBooks"
   />
   <DeleteBookDialog
     v-if="isDeleteBookDialogOpen"
     :open="isDeleteBookDialogOpen"
     @update:open="(open: boolean) => isDeleteBookDialogOpen = open"
     :book="currentBook"
     @refresh-data="fetchBooks"
   />
 </main>
</template>

Now, we need to create a system for opening and closing the drawer and dialog, respectively. We’ll be creating a ref to track the open/closed state for the drawer and dialog components in your index page. Paste the following code content in the script stage to enable that:

<script lang="ts" setup>

...

const currentBook = ref<BookProps>();


const isBookDrawerOpen = ref(false);
const isDeleteBookDialogOpen = ref(false);


const toggleAddBookDrawer = () => {
 isBookDrawerOpen.value = !isBookDrawerOpen.value;
};


const toggleEditBookDrawer = (book: BookProps) => {
 currentBook.value = book;
 isBookDrawerOpen.value = !isBookDrawerOpen.value;
};


const toggleDeleteDialog = (book: BookProps) => {
 currentBook.value = book;
 isDeleteBookDialogOpen.value = !isDeleteBookDialogOpen.value;
};
</script>

Update the Edit and Delete buttons in your index page to include the toggle handler:

    ...

             <div class="actions flex gap-4">
               <Button @click="toggleEditBookDrawer(book)">Edit</Button>
               <Button @click="toggleDeleteDialog(book)" variant="destructive">
                 Delete
               </Button>
             </div>

           ...

Include the toggleAddDrawer in your Add Book button too:

<Button @click="toggleAddBookDrawer">Add New Book</Button>

Save the file changes and view in your browser. You should have the drawer active now:

Add New Book Drawer

Moving on, we need to be sure the EditDrawer and Delete Dialog work. We’ll create a temporary array of mock book data to test that so you can see the result on your page. Update the value of the books ref to the data you have below (and don’t forget to update the books ref value to an empty array – that is books = ref<BookProps>([])):

const books = ref<BookProps[]>([
     {
       title: "Atomic Habits",
       author: "James Clear",
       isbn: "XYEOUIUEHEJ2902",
       published_date: "2020-09-01",
       cover_image: "",
     },
     {
       title: "The Power of Habits",
       author: "Charles Duhigg",
       isbn: "WIUIQUEWHSDBSD28",
       published_date: "2012-02-28",
       cover_image: "",
     },
]);

Save the changes and check out the EditDrawer and DeleteDialog in action:

Delete dialogue

EditDrawer

How to Integrate the Laravel API in the Frontend

Getting all books in the library

So far, we only have the UI of our frontend working, and the data being displayed is not from the API. To make the app fully dynamic, you'll need to make an HTTP request to the server to get all the data you need for your page.

Update the body of the fetchBooks function in the index page to the following code:

const fetchBooks = async () => {
 try {
   isLoading.value = true;
   const response = await $fetch<{ books: BookProps[] }>(
     `${API_BASE_URL}/api/books`
   );


   books.value = response.books.sort(
     (a, b) =>
       Number(new Date(b.created_at as string)) -
       Number(new Date(a.created_at as string))
   );


 } catch (error) {
   console.log(error);
 } finally {
   isLoading.value = false;
 }
};


onMounted(() => {
 fetchBooks();
});

Basically, you're calling your fetchBooks function when the page mounts using one of the lifecycle hooks available in Vue.js. When the function is called, it executes the instruction you created in the body:

• Set the loading state of the app to true.
• Make a GET HTTP request to the books endpoint of your API and set the response to the books ref you created earlier.
• When the request-response has been completed, set the loading state of the app back to false to indicate to the user the process has been completed.

Save the changes, and you should see the results in the browser:

Fetching the book list

Creating a new book

For your book creation to be successful, you need to include the logic for creating a book in your BookDrawer. Add the following code in the BookDrawer.vue file:

...

const isSubmitting = ref(false);


const addNewBook = async (data: any) => {
 const response = await $fetch(`${API_BASE_URL}/api/books`, {
   method: "POST",
   body: data,
   headers: {
     Accept: "application/json",
   },
 });
 return response;
};


const onSubmit = async () => {
 try {
   const formData = new FormData();
   Object.keys(form).forEach((key) => {
     // @ts-ignore
     if (form[key]) {
       formData.append(key, form[key as never]);
     }
   });
   isSubmitting.value = true;
   const data = await addNewBook(formData);
   closeDrawer(false);
   emit("refresh-data");
 } catch (error) {
   console.log(error);
 } finally {
   isSubmitting.value = false;
 }
};

...

Similar to the implementation for fetching your books, the only difference here is that you're making a POST HTTP request instead. You use this method whenever you need to mutate data on the server.

Creating a new book

Editing a book

Update your BookDrawer with the following code to enable editing of the books that have been added:

<script setup lang="ts">

...

onMounted(() => {
 if (props.book) {
   form = props.book;
 }
});


const editBook = async () => {
 try {
   isSubmitting.value = true;
   const resp = await $fetch(`${API_BASE_URL}/api/books/${props?.book?.id}`, {
     method: "PUT",
     body: formData,
   });
   closeDrawer(false);
   emit("refresh-data");
 } catch (error) {
   console.log(error);
 } finally {
   isSubmitting.value = false;
 }
};

...
</script>

Update the save button with the toggle handler also:

<Button
  type="submit"
  @click="() => (book?.id ? editBook() : onSubmit())"
>
  <template v-if="isSubmitting">Saving...</template>
  <template v-else> Save changes </template>
</Button>

And here's the result:

Updating a book

Deleting a book

Paste the following in the DeleteBookDialog.vue file:

const refreshData = () => emit("refresh-data");
const closeDialog = () => emit("update:open", false);


const deleteBook = async () => {
 await $fetch(`${API_BASE_URL}/api/books/${props?.book?.id}`, {
   method: "DELETE",
 });
 closeDialog();
 refreshData();
};

This works fine also:

Deleting a book

Conclusion

Building full-stack web apps with Laravel and Nuxt is a very rewarding experience as you can enjoy the benefits and rewards from the best of both worlds.

Since Laravel is a feature-rich backend framework, it comes with many modules and packages that you can install whenever a feature or implementation needs to be worked on.

And Nuxt, as a Vue framework, gives you the superpower of building single-page applications that are fast, accessible, and responsive, giving end-users a delightful experience.

In this tutorial, we went over how we can build full-stack applications using Nuxt and the Laravel framework. I hope you were able to learn something new and are excited to explore this further. Feel free to reach out if you have any questions or ideas.

The full code for the tutorial can be found in the GitHub repo here.

Resources

• Laravel Docs
• Nuxt Documentation
• Shadcn-vue, ready-made UI components that can be copy-pasted anytime
• Vue Docs

We just posted a full course on Nuxt 3 on the freeCodeCamp.org YouTube channel. Guillaume Duhan created this course. Guillaume is a seasoned front-end developer with a decade of experience in the field and he is the perfect guide for those looking to learn about Nuxt.

Why should you learn Nuxt? Nuxt.js is a progressive framework built on top of Vue.js, designed to create modern web applications with ease. It simplifies the development process, handling tasks like routing, state management, and server-side rendering.

If you're building a web application that requires SEO optimization, Nuxt is a great choice due to its server-side rendering capabilities. Additionally, if you want a scalable and performance-optimized application, Nuxt's modular architecture and rich ecosystem can come in handy.

The course is structured to cater to both beginners and those with a foundational understanding of web development. Here's all the sections in the course:

• Nuxt Basics
• Create an App
• Pages
• Components
• Layouts
• Assets
• Composables
• Plugins
• Middlewares
• Modules
• State Management
• Server
• Nitro
• Rendering modes
• useFetch
• useAsyncData
• SEO & Metas
• Hooks
• Nuxt.config.ts
• Nuxt Content
• Build Docs and API

If you have a foundation in Vue.js or are simply curious about the capabilities of Nuxt, this comprehensive guide will provide you with the knowledge and skills to build impressive web applications.

Watch the full course on the freeCodeCamp.org YouTube channel (3-hour watch).

In a real-time chat application, the recipient can view the sender’s message almost immediately. This can either be in a one-on-one conversation between two parties or a group conversation.

And that's what we're going to build in this tutorial. For this application, we will be using Nuxt, the intuitive Vue framework.

Now that we know what we’re going to be building and the technology we’ll be using, let’s go over the chat API we’ll be using.

For this article, we’ll be going with Robin because of its minimal UI and how easy it is to integrate into our app. With that out of the way, let’s get started.

Step 1 – Create the Nuxt App

First, we need to create the Nuxt app with any of the following commands:

yarn create nuxt-app nuxt-chat-app
// OR
npx create-nuxt-app nuxt-chat-app
// OR
npm init nuxt-app nuxt-chat-app

Step 2 – Create a Robin Account

Now that our app is ready, we need to have a Robin account before we can use it. Head over to Robin’s signup page to create a 30-day free trial account.

Robin notifies you 7 days after you've created the account and you can remove your card before the billing date.

After filling out the signup form, you’ll be redirected to a billing page to fill in your card information. On the next page where it redirects you, Robin requests the name of the app you want to create and its authentication type. Feel free to use any name of your choice and either of the auth options.

Step 3 – Get Your Robin Credentials

Now that we have created an app on our Robin dashboard, there is something you should take note of. There are a couple of credentials you need when using Robin in your Nuxt app:

• API key,
• User token,
• User name,
• Users, and
• Keys

Let’s go over each of them individually.

• API key: Robin automatically creates the API key when you create an app. You can retrieve it from either the getting started or the API config page on your dashboard. It is unique for every application.
• User token: The user token is a unique identifier for every user of your Robin app. The token that should be passed to this property is yours since you’re the one using the app on your site. However, it is to be created by you, the user, typically on the server, and then used on the client side.
• User name: The User name is the name of the current user of your Robin app. In this case, it will be your name. If you wanted someone else to include your Robin chat on their site or web app (i.e another user of your Robin app), it should be their name.
• Users: Users is a list of the users on your Robin app. It usually contains their user tokens, profile images, and user names.
• Keys: This fundamentally exists to help us be flexible in describing the user tokens, profile images, and user names in our users list. Here’s an example. If our keys object looks like this:

keys: {
  userToken: 'user_token',
  profileImage: 'profile_image',
  userName: 'user_name'
}

Then our users array should describe the users’ tokens, profile images, and names with the values in the keys object.

Regardless of the users that would be using your Robin App, Robin requires a userToken, profileImage and a userName from them. Robin requires this for the display name and to identify each message sender and receiver uniquely on the platform.

users: [
  {
    'user_token': 'ABCDEF098765GH',
    'profile_image': 'https://url-to-image',
    'user_name': 'Article Reader'
  }
]

Step 4 – Install Robin in Your Nuxt App

Since we have everything we’ll need, we can go ahead and install Robin.

npm i robin-vue
// OR
yarn add robin-vue

Step 5 – Setup the Robin Plugin

In your plugins directory, create a robin.js file with the plugin setup:

import Vue from 'vue'
import RobinChat from 'robin-vue'
import 'robin-vue/dist/style.css'

Vue.use(RobinChat)

Note that we import the CSS because the RobinChat component does not include any CSS itself.

Step 6 – Register the Plugin

The plugins property in the nuxt.config.js file is to let our Nuxt app know about the plugins that it should use. So if we don’t include our Robin plugin there, it won’t be available in our app.

export default {
  // ...
  plugins: [
    { src: '~/plugins/robin.js', mode: 'client' }
  ]
}

Step 7 – Use the Plugin

Now what’s left is for us to include the RobinChat component anywhere in our app and pass those credentials we discussed earlier as props.

Once again, the credentials are:

• API key,
• User token,
• User name,
• Users, and
• Keys

In this list, what we currently don’t have is our user token and the tokens of the users on our app.

Recall that these tokens are usually created on the server. But we don’t have the luxury of that. So we can go ahead and create them with the help of Robin’s JavaScript SDK. The Vue SDK we previously installed depends on this JavaScript SDK. So we don’t need to install it since it already exists in our app.

How to Create the User Tokens

We can go ahead and create the tokens in the page we're going to include the chat UI. Because it’s for learning purposes, we can go ahead and create tokens for 5 users, ourselves included. We need to come up with usernames for each of them.

<template>
  <!-- ... -->
</template>


<script>
export default {
  data () {
    return {
      users: [
        {
          user_token: '',
          profile_image: '',
          user_name: 'idorenyin'
        },
        {
          user_token: '',
          profile_image: '',
          user_name: 'ayo'
        },
        {
          user_token: '',
          profile_image: '',
          user_name: 'elvis'
        },
        {
          user_token: '',
          profile_image: '',
          user_name: 'favour'
        },
        {
          user_token: '',
          profile_image: '',
          user_name: 'enoch'
        }
      ],
    }
  }
}
</script>

Note that the keys in every user object in the users array have to be defined in the keys object that we’ll be passing as a prop to the Robin component.

keys: {
  userToken: 'user_token',
  profileImage: 'profile_image',
  userName: 'user_name'
},

Next, we use the SDK’s createUserToken() function to create the tokens after creating a Robin instance, as it says in Robin’s docs.

<template>
  <!-- ... -->
</template>

<script>
import { Robin } from 'robin.io-js'

export default {
  data () {
    return {
      keys: {
        userToken: 'user_token',
        profileImage: 'profile_image',
        userName: 'user_name'
      },
      users: [
        // ...
      ]
    }
  },
  created () {
    this.createTokens()
  },
  methods: {
    async createTokens () {
      const robin = new Robin('API_KEY', true)
      for (let i = 0; i < this.users.length; i++) {
        await robin.createUserToken({
          meta_data: {
            username: this.users[i].user_name
          }
        }).then((res) => {
          this.users[i].user_token = res.data.user_token
        })
      }
    }
  }
}
</script>

How to Use Credentials on the RobinChat Component

We now have everything we need to display the Robin chat UI on our app. Whew!
We can now go ahead and use the tokens and the other credentials.

<template>
  <!-- ... -->
  <RobinChat
    v-if="tokensAreAvailable"
    :api-key="apiKey"
    :user-token="users[0].user_token"
    user-name="Idorenyin Udoh"
    :keys="keys"
    :users="users"
  />
</template>

<script>
import { Robin } from 'robin.io-js'

export default {
  data () {
    return {
      tokensAreAvailable: false,
      apiKey: 'API_KEY',
      keys: {
        userToken: 'user_token',
        profileImage: 'profile_image',
        userName: 'user_name'
      },
      users: [
        {
          user_token: '',
          profile_image: '',
          user_name: 'idorenyin'
        },
        {
          user_token: '',
          profile_image: '',
          user_name: 'ayo'
        },
        {
          user_token: '',
          profile_image: '',
          user_name: 'elvis'
        },
        {
          user_token: '',
          profile_image: '',
          user_name: 'favour'
        },
        {
          user_token: '',
          profile_image: '',
          user_name: 'enoch'
        }
      ]
    }
  },
  created () {
    this.createTokens()
  },
  methods: {
    async createTokens () {
      const robin = new Robin(this.apiKey, true)
      for (let i = 0; i < this.users.length; i++) {
        await robin.createUserToken({
          meta_data: {
            username: this.users[i].user_name
          }
        }).then((res) => {
          this.users[i].user_token = res.data.user_token
        })
      }
      this.tokensAreAvailable = true
    }
  }
}
</script>

Note that we only display the RobinChat component when all the users’ tokens are available to avoid errors.

This is what the result looks like:

The app is available here.

Note that I used previously-created user tokens for this app because you wouldn’t be able to view messages if tokens are created every time the app loads. Permanent tokens are what make the messages on Robin persist.

Also, I created another app for the user Ayo. You can check it out too. This way, you can test the real-time communication between Idorenyin and Ayo.

Conclusion

You just learned how to implement real-time communication on a Nuxt application with Robin.

The ease of integration makes it super fast to implement a chat system in your app and focus on building/maintaining it.

If you make sure to create your users’ tokens on the server, then implementing the integration on the frontend wouldn't be too hard.

Happy building!

Making your Nuxt web app static can potentially save you the time and money of setting up a server-rendered app. It may also offer superior performance.

But what if your app needs dynamic data? The most popular solution is to set up an API alongside your static app that can deliver dynamic data via AJAX.

In this article, I'll show you another possible architecture - using a flat-file database. This architecture might save you the hassle of setting up an API and offers superior performance.

What is a flat-file database?

A "flat-file database" is a database architecture where data is stored in a simple text file rather than in database software like MySQL or MongoDB.

In a Nuxt app, this file can be a JSON file that sits in your static files directory and is deployed alongside the markup files.

At runtime, the JSON file is loaded by the Nuxt app. Once the data is parsed as JavaScript data it can be used to power the app.

Why use a flat-file database?

Flat-file databases are advantageous because of their simplicity and low overhead. But they are also insecure and don't offer the performance benefits of conventional database software, which is why they're rarely used.

In the context of Nuxt apps, though, they have another great advantage – they can be stored and accessed from static hosting.

Using a flat-file database may also have a performance advantage over an API service which will have a small latency overhead incurred when requests are processed by the server.

However, flat-file DBs won't always be appropriate to use, as they offer no security and are read-only while in production. This means you'll need to rebuild the site any time you want to write new data.

A type of data that is a good candidate for flat-file storage and retrieval is meta data. For example, on the Vue.js Developers blog, which I built with Nuxt, I use a flat-file database to store meta data about published posts.

This allows me to easily access that data across the site, for example on the home page where the latest blog articles are displayed, and on the topics page which indexes posts based on topic tags applied (both shown below).

Implementing the flat-file database architecture in Nuxt

Now let's see how to implement the flat-file database architecture in your own Nuxt site.

Say we want to create a blog home page which show the latest published article like that on the Vue.js Developers blog.

We'll begin by seeing how flat-file-sourced data gets used in the page, and then work backwards until we can see how the whole architecture works.

Using flat-file data in a page

In our home page component, pages/index.vue, we'll import getArticleSummaries from a soon-to-be-created JavaScript module flatFileDb.

This method will return a Promise containing the article summary data ready for use on the page.

You can, of course, use this data at build time via asyncData, and at run time via the created hook.

pages/index.vue:

const { getArticleSummaries } from "@/assets/js/flatFileDb";

export default {
    data: () => ({
        articleSummaries: []
    }),
    async asyncData () {
        const articleSummaries = await getArticleSummaries();
        return { articleSummaries }
    },
    async created () {
        this.articleSummaries = await getArticleSummaries();
    }
}

Note that the data structure we'll get from getArticleSummaries will be an array of objects like this:

[
    {
        title: "...",
        description: "...",
        published: "...",
        ...
    },
    ...
]

Note: If you have multiple entities (for example, in addition to articles you also store information about videos), each will have its own flat file and its own retrieval method in the app, like getVideoSummaries.

Flat-file database module

We saw above that a getArticleSummary method was imported from the flatFileDb module. Let's see how we can implement that.

Our flat-file database will be included in our static files and should be a JSON file since these are simple to parse as valid JavaScript data.

We'll include this JSON file by using a dynamic import. This feature is designed for importing JavaScript modules, but it works with JSON files out-of-the-box with Webpack. Conveniently, you get the JSON file already parsed as JavaScript.

It's important to call the dynamic import in a try/catch block to prevent the app crashing if the file is missing or the JSON parsing fails.

Before we return the data to the consuming component we need to "decode" it with another custom method decodeArticleSummaries. I'll explain that in a moment.

Finally, note that a JSON file doesn't have a default export, so you'll need to access the default property of the db module to access the data.

assets/js/flatFileDb.js:

import { decodeArticleSummaries } from "dbDecoders";

const getArticleSummaries = async () => {
    try {
    const db = await import(`@/static/article-summaries.json`);
    return decodeArticleSummaries(db.default);
  } catch (err) {
    console.log(err);
    return [];
  }
};

export { getArticleSummaries };

Decoding the database

Above, I said the data provided to the component would look like this:

{
    title: "...",
    description: "...",
    published: "...",
    // etc
}

However, it shouldn't be stored in the database like this because the property names are wastefully long.

In order to keep the flat file as lean as possible we should "encode" each key when the database is created. Then we should decode them before they're consumed by components so they have their full names available to the developer.

So, let's say we make "title" => "t", "description" => "d", and "published" => "p". In a large database, this transformation could reduce the file size by many bytes.

assets/js/dbDecode.js:

const decodeArticleSummaries = db => {
    return db.map(article => ({
        title: article.t,
        description: article.d,
        published: article.p
        // etc
    }));
}

Generating the flat-file database

So now we've seen how the flat-file database is consumed at run time. How is it created?

You could create a flat-file database manually by hand, but usually you'll want to generate it at build time with a Node.js script.

In our example, we'll want to make a script that extracts the meta data of each article and stores it as static/article-summaries.json. Let's assume the articles are stored as markdown and are in an "articles" directory in the project root.

The details of the script will be specific to your implementation, so I'll just give you pseudo code to communicate the basic idea.

scripts/generateDb.js:

const fs = require("fs");
const frontmatterExtractor = require("./frontmatterExtractor");
const encodeArticleSummaries = require("./encodeArticleSummaries");

module.exports = async () => {
    // Load article files
    const articles = await fs.readdir("/articles", (err, filePaths) => {
        // Create the database by reading each file
        const db = filePaths.map(async path => {
            const file = await fs.readFile(path);
            // Extract the meta data
            return frontmatterExtractor(file);
        });
        // Encode the data
        const encoded = encodeArticleSummaries(db);
        // Write the database object to a JSON file
        await fs.writeFile(
            "/static/article-summaries.json", 
            JSON.stringify(encoded)
        );
    });
}

Running the DB generator script before the site build

Now that we've got a database generator script, let's trigger it to run just before the build (or generate) processes which will want to consume it.

To do this, we'll squeeze it into the NPM commands in package.json. Note that by using the && operator we can ensure the Nuxt process doesn't begin until the generator script completes.

package.json:

{
    ...
    "scripts": {
        ...
        "build": "node scripts/generateDb && nuxt build",
        "generate": "node scripts/generateDb && nuxt generate",
        ...
    }
    ...
}

In development, however, I find it easier to manually generate the database on the command line whenever I need to update it:

$ node scripts/generateDb

Further reading

That's the basic architecture explained. Here are a few other articles learn more:

• Going JAMstack with Netlify and Nuxt
• Multiple Ways of API Integration in your JAMStack
• Including Markdown Content in a Vue or Nuxt SPA

TL;DR: Overcome Nuxt.js, Bulma and Sass shenanigans with this quick article to help you start developing your next App in less than 10 minutes.

Hi everyone ❤️! Few days ago I found myself struggling a bit to put Nuxt.js, Bulma and Sass to work correctly and the info I found on google didn't help too much.

Most of the configurations I found were not working, because they were outdated or didn't explain quite well how to do it. So I deep dived a little bit on this subject and decided to write an article to help you do the same in less than 10 minutes.

Let's have some fun and get our hands dirty while grokking a few concepts needed to do this.

1. Scaffolding Nuxt.js

Nowadays, to get started quickly with Nuxt.js we use a scaffolding tool called create-nuxt-app. Please make sure you have npx installed on your machine.

Let's open a terminal and do: npx create-nuxt-app nuxt-bulma-sass, where nuxt-bulma-sass is the name of the project we're scaffolding for the purpose of this article.

create-nuxt-app will ask you some questions before creating the scaffold. For the purpose of this article I've chosen the following setup:

create-nuxt-app init questions

So, the next step will be to change directory into our project folder:

cd nuxt-bulma-sass

and launch the project with: yarn run dev. (you can also use npm if you like it)

At this point we have our project running:

And if we open our browser on localhost:3000 we'll be getting this screen:

localhost:3000 pages/index.vue

So at this point we have the pages/index.vue on the screen, which is the first page to be rendered in your project by default.

Let's replace the content of this file by the following one:

If we inspect our page in the browser we see we got bulma installed because section is formatted according to it.

Easy peasy lemon squeezy.

Let's add a class and choose some colors:

What if we want to nest .hello-nuxt inside .edo-theme? We're going to need SASS to be able to do it.

2. Adding Sass

So, to add Sass to our project we'll need to stop our running app (Ctrl+c) and do the following:

yarn add node-sass sass-loader --dev

These are the two packages needed as dev-dependencies to be able to have Sass in our boilerplate.

Note that we're adding it as a dev dependency because we only need it while developing and at build time. After that Sass is transformed into CSS and we don't need it anymore.

Let's sneak peek my package.json for you to check it:

package.json with sass added to the project

Okay everyone ❤️, at this point we're able to nest the classes we wanted to.

Let's run our boilerplate again: yarn run dev and do the tweaks needed ?

Noice! We already did a lot today! Go grab a coffee ☕, I'll wait for you here ?

Okay, let's abstract things a bit and create this file ~/assets/scss/main.scss and put there some classes and variables:

new ~/assets/scss/main.scss

Nice! It's working!

Now we have two problems:

1. We need to import main.scss into each one of our pages/components, which is not nice. We want to import it only once and have it available in all our

You have decided to build a static site, but where do you start? How do you select the right tool for the job without previous experience? How can you ensure that you succeed the first time, while avoiding tools that won’t help you in the end?

In this article, you will learn how to adjust a Vue.js website to be automatically generated as a static site.

Introduction

I summarized the key differences between an API based website and static sites in my previous article. As a quick reminder, static sites are:

• Blazing fast
• Secure (as they are just a set of static pages)
• Regenerated every time editors update the content
• Compatible with additional dynamic functionality

What is a Static Site Generator?

A static site generator is a tool that generates a static website from a website’s implementation and content.

Content can come from a headless content management system, through a REST API. The website implementation uses one of the JavaScript frameworks like Vue.js or React. The output of a static site generator is a set of static files that form the website.

Static Site Implementation

I chose Vue.js as the JavaScript framework to use. Therefore I will be working with Nuxt.js, which is a static site generator for Vue.js.

If you are using a different framework, look for a static site generator built on top of that framework (for example Gatsby for React.js).

Essentially, Nuxt is a combination of multiple tools that together enable you to create static sites. The tools include:

• Vue2 — Core Vue.js library.
• Vue Router — Handles URL routing for pages within the website.
• Vuex — Memory store for data that are shared by components.
• Vue Server Renderer — Enables server side rendering of pages before the actual static files generation
• Vue-Meta — Manages page metadata info

Nuxt also defines how the website needs to be built in order to generate static files.

Installation

In order to start building websites with Nuxt, you need to install it. See detailed installation instructions on the Nuxt.js webpage. In a nutshell, you need npx (shipped with NPM by default) installed and run:

npx create-nuxt-app <website-name>

You can just use default selections, unless you have preferences otherwise.

Components

In one of my previous articles I explained how to create a template layout and components. All of them were defined within single file components.js. That needs to be changed with Nuxt. All components need to be extracted from components.js file into separate files under folder components. Take a look at my blog-list component and its previous implementation:

Vue.component('blog-list', { props: ['limit'], data: function(){  return {   articles: null  } },

 created: function(){  var query = deliveryClient   .items()   .type('blog_post')   .elementsParameter(['link', 'title', 'image_url', 'image', 'teaser'])   .orderParameter('elements.published', SortOrder.desc);   if (this.limit){   query = query.limitParameter(this.limit);  }  query   .getPromise()   .then(response =>    this.$data.articles = response.items.map(item => ({     url: item.link.value,     header: item.title.value,     image: item.image_url.value != '' ? item.image_url.value : item.image.assets[0].url,     teaser: item.teaser.value    }))   ); },

 template: `  <section class="features">   <article v-for="article in articles">    ...   </article>  </section> ` });

To separate it, you also need to change the component’s syntax to match the following template:

<template> HTML of the component</template><script> export default {  Vue.js code }</script>

Therefore my adjusted Blog-list component looks like this:

<template> <section class="features">  <article v-for="article in blogPosts">   ...  </article> </section></template><script> export default {  props: ['limit'],  computed: {   blogPosts: function(){    return this.$store.state.blogPosts && this.limit && this.$store.state.blogPosts.length > this.limit ? this.$store.state.blogPosts.slice(0, this.limit) : this.$store.state.blogPosts;   }  } }</script>

You see the template stayed the same. What changed is the implementation that is now within export default section. Also, there used to be a function gathering data from headless CMS Kentico Cloud.

That content is now stored within Vuex store. I will explain this part later. Convert all of your components this way, to contain template within <template> tags and implementation within &lt;script> tags. You should end up with a similar file structure as I have:

Note that I have two new components here — Menu and Header. As my aim was to also improve performance, I decided to remove jQuery from my website. jQuery is quite a large and heavy library that was used only for small UI effects. I was able to recreate them using just Vue.js. Therefore, I converted the static HTML representing header to component. I also added the UI related functionality into mounted function of this component.

mounted: function(){ window.addEventListener(‘scroll’, this.scroll); …},methods: { scroll: function(){  … }}

Handling Vue.js Events with Nuxt

I used to leverage Vue events in my website. The main reason was reCaptcha control used for form validation. When it was initialized, it would broadcast the event so that form component can unlock the submit button of the contact form.

With Nuxt, I no longer use app.js or components.js files. Therefore I created a new recaptcha.js file that contains a simple function emitting the event when reCaptcha gets ready. Note that instead of creating new Vue.js instance just for events (let bus = new Vue(); in my old code), it is possible to simply use this.$nuxt the same way.

var recaptchaLoaded = function(){ this.$nuxt.$emit('recaptchaLoaded');}

Layout and Pages

The main frame of the page was index.html, and each page defined its own layout in constants that were handed over to Vue router.

With Nuxt, the main frame including <html> tag, meta tags and other essentials of any HTML page are handled by Nuxt. The actual website implementation is handling only content within tags. Move the layout that is common for all your pages into layouts/default.vue and respect the same template as with components. My layout looks like this:

<template> <div>  <Menu></Menu>  <div id="page-wrapper">   <Header></Header>   <nuxt/>   <section id="footer">    <div class="inner">     …     <ContactForm></ContactForm>     …    </div>   </section>  </div> </div></template><script> import ContactForm from ‘~/components/Contact-form.vue’ import Menu from ‘~/components/Menu.vue’ import Header from ‘~/components/Header.vue’  export default {  components: {   ContactForm,   Menu,   Header  } } </script>

The layout is basically the HTML markup of my old index.html. However, note the <script> section. All of the components I want to use within this layout template need to be imported from their location and specified in exported object.

Page components were previously defined in app.js as constants. Take a look at my old Home page for example:

const Home = { template: `  <div>   <banner></banner>   <section id="wrapper">    <about-overview></about-overview>    ...    <blog-list limit="4"></blog-list>    <ul class="actions">     <li><a href="/blog" class="button">See all</a></li>    </ul>    ...   </section>  </div> `}

All these pages need to be defined in separate files within pages folder. Main page is always called index.vue. This is how my new pages/index.vue (my Homepage) looks like:

<template> <div>  <Banner></Banner>  <section id="wrapper">   <AboutOverview></AboutOverview>   ...   <BlogList limit="4"></BlogList>   <ul class="actions">    <li><a href="/blog" class="button">See all</a></li>   </ul>   ...  </section> </div></template><script> import Banner from ‘~/components/Banner.vue’ import AboutOverview from ‘~/components/About-overview.vue’ import BlogList from ‘~/components/Blog-list.vue’  export default {  components: {   Banner,   AboutOverview,   BlogList  }, }</script>

Where to Store Assets

On every website there are assets like CSS stylesheets, images, logos, and JavaScripts. With Nuxt, all these static files need to be stored under folder static. So the folder structure currently looks like this:

When you reference any resources from CSS stylesheets like fonts or images, you need to use static folder as a root:

background-image: url("~/assets/images/bg.jpg");

Getting Content

With all the components and pages in place, we finally get to it: getting content into components.

Getting content using Nuxt is a bit different than it used to be. The important aspect of this process when using a static site generator is that the content needs to be gathered before all the pages are generated. Otherwise you will end up with a static website, but requests for content would still be dynamic, hitting the headless CMS from each visitor’s browser and you would lose the main benefit.

Nuxt contains two special methods that handle asynchronous data fetching at the right time, that is before the pages are generated. These methods are asyncData and fetch. They are available only to page components (that is files within pages folder) and their purpose is the same, but asyncData will automatically store received data within the component dataset.

This can be beneficial if you have many components on a single page using the same set of data. In my case, I even have multiple pages with many components that need to share the same data. Therefore I would either need to request the same data on each page or use a shared space that all pages and components could access.

I chose the latter. Nuxt makes it very easy for us. It automatically includes Vuex store that enables our components and pages access any data that are within the store. To start using the store all you need to do is create an index.js file within the store folder.

import Vuex from 'vuex'

const createStore = () => { return new Vuex.Store({  state: () => ({}),  mutations: {},  actions: {}, })}export default createStore

You see the instance has a few properties:

• State
  State is similar to data in components. It contains definition of data fields that are used to store data.
• Mutations
  Mutation are special functions that are permitted to change data in State (mutate the state).
• Actions
  Actions are simple methods that enable you to, for example, implement content gathering logic.

Let’s get back to the Blog-list component. This component needs an array of blog posts in order to render its markup. Therefore blog posts need to be stored within Vuex store:

…const createStore = () => { return new Vuex.Store({  state: () => ({   blogPosts: null  }),  mutations: {   setBlogPosts(state, blogPosts){    state.blogPosts = blogPosts;   }  },  actions: {   getBlogPosts (context) {    logic to get content from Kentico Cloud   }  }, })}

After adjusting Vuex store this way, the Blog-list component can use its data:

<article v-for="article in $store.state.blogPosts"> …</article>

I already shared the whole implementation of this component above. If you noticed, it uses computed function as a middle layer between component markup and Vuex store. That middle layer ensures the component displays only a specific amount of articles as configured in the limit field.

Querying the Headless CMS

Maybe you remember the deliveryClient was used to get data from Kentico Cloud into the components.

Disclaimer: I work for Kentico, a CMS vendor that provides both traditional (coupled) CMS and a new cloud-first headless CMS — Kentico Cloud.

The very same logic can be used here in the Vuex store actions with a little tweak. Kentico Cloud has a module for Nuxt.js, install it using following command:

npm i kenticocloud-nuxt-module — savenpm i rxjs — save

With this module you can keep using deliveryClient like before, just with a $ prefix. So in my case the logic to get blog posts looks like this:

…getBlogPosts (context) { return this.$deliveryClient  .items()  ...  .orderParameter('elements.published', SortOrder.desc)  .getPromise()  .then(response => {   context.commit('setBlogPosts', response.items.map(item => ({    url: item.link.value,    header: item.title.value,    image: item.image_url.value != '' ? item.image_url.value : item.image.assets[0].url,    teaser: item.teaser.value   })))  }); },…

If you want to use ordering using the orderParameter, you may need to include another import in the store/index.js file:

import { SortOrder } from 'kentico-cloud-delivery'

Now when the content gathering logic is implemented, it’s time to use the special asynchronous function fetch that I mentioned before. See my implementation in the index.vue page:

async fetch ({store, params}) { await store.dispatch('getBlogPosts')}

The call to store.dispatch automatically invokes getBlogPosts action. Within the getBlogPosts implementation note the call for context.commit. context refers to Vuex store and commit will hand over blog posts data to setBlogPosts mutation. Updating the data set with blog posts changes the state of the store (mutates it). And we are almost finished!

Other content storage options

I used Kentico Cloud headless CMS and its API here, as I am using it throughout all articles in this series. If you want to also check out other options, you can find an independent list of headless CMSs and their features at headlesscms.org.

If you don’t want to use a headless CMS and its API, you may decide to store your content in some other way — usually as a set of markdown files directly stored within your project or Git repository. You can find a nice example of this approach in nuxt-markdown-example GitHub repository.

Nuxt Configuration

The whole application needs to be properly configured using Nuxt.config.js file. This file contains information about used modules, their configuration and site essentials like title or SEO tags. The configuration of my website looks like this:

export default { head: {  title: 'Ondrej Polesny',  meta: [   { charset: 'utf-8' },   ...   { hid: 'description', name: 'description', content: 'Ondrej Polesny — Developer Evangelist + dog lover + freelance bus driver' }  ],  script: [   { src: 'https://www.google.com/recaptcha/api.js?onload=recaptchaLoaded', type: "text/javascript" },   { src: 'assets/js/recaptcha.js', type: "text/javascript" }  ], }, modules: [  'kenticocloud-nuxt-module' ], kenticocloud: {  projectId: '*KenticoCloud projectId*',  enableAdvancedLogging: false,  previewApiKey: '' }, css: [  {src: 'static/assets/css/main.css'}, ], build: {  extractCSS: {   allChunks: true  } }}

The head section describes website essentials like title and meta tags you want to include in header.

Note the modules and kenticocloud configuration. The first one lists all modules your application depends on and the second one is specific module configuration. This is the place where you need to put your project API key.

To see all the options for meta tags, please refer to [https://github.com/declandewet/vue-meta](http:// https://github.com/declandewet/vue-meta)

Running and Generating

Static sites need to be generated before anyone can access them or upload them to an FTP server. However, it would be very time consuming to regenerate the site every single time a change has been made during the development phase. Therefore, you can run the application locally using:

npm run dev

This will create a development server for you and enable you to access your website on http://localhost:8000 (or similar). While you keep your console running this command, every change you make in your scripts will have immediate effect on the website.

To generate a true static site, execute following command:

npx nuxt generate

The output, that is your static site, will be in dist folder. Feel free to open any page in your favorite text editor and see if the source code contains content from the headless CMS. If it does, it was successfully fetched.

Conclusion

Having a generated static site will greatly improve the website’s performance. Compared to traditional sites, the webserver does not need to perform any CPU heavy operations. It only serves static files.

Compared to API based websites, the clients receive requested data instantly with the very first response. That’s what makes them all that fast — they do not need to wait for external content to be delivered via additional asynchronous requests. The content is already there in the first response from the server. That dramatically improves user experience.

Converting the site from Vue.js implementation to Nuxt definitions is very straightforward and does not require deep knowledge of all used components and packages.

Have you successfully created your first static site? Have you experienced any struggles? Please leave a comment.

In the next article I will focus on automated regeneration of static sites and where to host them, so stay tuned.

Other articles in the series:

1. How to start creating an impressive website for the first time
2. How to decide on the best technology for your website?
3. How to power up your website with Vue.js and minimal effort
4. How to Mix Headless CMS with a Vue.js Website and Pay Zero
5. How to Make Form Submissions Secure on an API Website
6. Building a super-fast and secure website with a CMS is no big deal. Or is it?
7. How to generate a static website with Vue.js in no time
8. How to quickly set up a build process for a static site