Building an Interactive Quiz App

We’ll be stepping up the complexity in this chapter by creating a quiz app that has an admin panel and a real-time connection among multiple clients through the use of WebSockets. WebSockets differ from our usual endpoints by keeping the connection open, allowing for continuous updates to be sent from a central socket server to one or more clients. Using these features, we’ll build a small-scale Kahoot clone.

For the admin panel, we’ll use Nuxt (https://nuxt.com/). Nuxt is a framework that was built as an extension of the Vue philosophy but extended with server capabilities. Save for the Electron app in Chapter 7, all of our code can run in the browser of the client. Nuxt allows Vue code to be executed on a server. On top of that, it has a lot of extra capabilities that drastically improve the developer experience (DX). We’ll encounter these capabilities as we progress through this chapter.

In this chapter, we’...

Technical requirements

At the heart of our setup lies the Server Quiz App (SQA), which is scaffolded around Nuxt (https://nuxt.com/), Pinia for state management (https://pinia.vuejs.org/), Supabase for managing quiz data (https://supabase.com/), and Vuetify (https://vuetifyjs.com/) for rendering a management interface.

We’ll build a standalone Socket Quiz Server (SQS) that uses Express (https://expressjs.com/) to process incoming requests and sets up a socket.io server (https://socket.io/) to maintain a real-time connection between clients.

Lastly, our Client Quiz App (CQA) will use Vuetify to render the quiz elements (https://vuetifyjs.com/).

You can find the code complete code for this chapter here: https://github.com/PacktPublishing/Building-Real-world-Web-Applications-with-Vue.js-3/tree/main/08.quiz.

Entities in the quiz app setup

To give you an idea of how our elements will work together, let’s quickly take a look at the following figure:

Figure 8.1 – Overview of the entities in the quiz app setup

The big change concerning our previous projects is that our client (CQA) is not directly communicating with the Supabase database anymore. Instead, it connects via the SQS, where it retrieves questions and scores and sends its answers back to the SQS. The SQS, in turn, communicates with the SQA to retrieve relevant quiz information and centralizes the session of a current active quiz between its clients (CQAs).

The SQA is used to manage the contents of quizzes and interact with the database.

A word beforehand

Since the setup is fairly complex, this chapter will not focus on, and instead leave out, security measures. It is good to realize the limitations of the project and don’t treat this as production-ready code. Where possible...

Setting up the database

As with previous chapters, we’ll start this chapter by setting up our database. We’ll create another project called quiz, set a strong database password, and select a geographically close region.

Remember to note the Project URL and API Key values!

Note

The intent of this chapter is not to focus on database management and the following settings should not be considered a best practice for a production app!

Follow these steps to set up the database:

1. Go to Table Editor and choose Create a new table. Here, do the following:
   1. For the name, insert quiz.
   2. Uncheck Enable Row Level Security (RLS) and confirm the dialog after reading its warning.
   3. In the Columns section, change the type of the id field to uuid.
   4. That’s enough for this table, so click Save.

   We will only use this table as a grouping mechanism for questions, so we’re keeping it as simple as possible.

2. Now, return to Table Editor and click Create a new table. Apply...

The SQA

To organize all our applications, we’ll create subfolders for every project in our chapters’ root folder. Since this app will run on Nuxt, we can use the Nuxi CLI to install our project for us. From the root of our project, we’ll run the following command in the command line:

npx nuxi@latest init server

We’ll simply pick npm as our package manager. Once the installation is done, navigate to the server folder and run npm run dev to start the application. By default, it will run on port 3000. Upon opening the URL in your browser, you should see something like this:

Figure 8.2 – The welcome screen of a fresh Nuxt installation

While this may not look like much, please inspect the source of this page. Instead of rendering a virtual DOM to a <div id="app" /> element, Nuxt runs as a Node.js process, which (among other things) means that it supports server-side rendering of Vue components! This can...

Setting up the SQS

Our next order of business is setting up the server that handles the requests from one or more clients. This will be a small standalone application and it will get its data from our Nuxt server since that already has a connection with the database instance. Creating an endpoint in Nuxt is something we haven’t built yet because our Nuxt application is only capable of presenting a management app!

Nuxt API routes

As I mentioned previously, the Nuxt app runs as a Node process. When we request pages, it acts as a web server that interprets the Vue components and routes to return an HTML response. In addition to that, it can also act as a server at the same time! Nuxt uses the Nitro server engine (https://nuxt.com/docs/guide/directory-structure/server) to process requests on scripts in the ./server folder. It also supports file-based routing and parameters, similar to the ./pages folder.

To server our quizzes as part of a RESTful API, we’ll create...

Creating the CQA

To wrap it all up, we’re going to create the client app as a Vuetify project in our projects’ root folder. Let’s navigate to the root folder by using the terminal and typing npm create vuetify to begin the installation. We’ll use the following settings:

• app as the project’s name
• For the preset, we’ll choose the default of Base (Vuetify, VueRouter)
• We’ll select TypeScript
• To install dependencies, we’ll select npm

Once the installation completes, we can open the folder in our IDE to start editing.

First, we’ll make some changes to the vite.config.ts file, which helps our app to work in our multi-app environment. We’ll add a new property called clearScreen with a value of false. This will prevent the process from clearing the logs (which will also contain our servers’ logs). We can simply add it at the bottom of the file.

Next, we’ll locate the server and...

Summary

This was quite a lengthy chapter that covered three different apps. I hope the distinct roles of the individual apps are clear. I also hope you appreciate the differences between a socket server setup and a RESTful server. We’ve used both in this chapter, each with its strengths.

Also, with the amount of code we’ve written in this chapter, it should be clear that this code is not at the level of sturdiness nor as secure as you would realistically want it to be when it’s production-ready. I want to stress that this wasn’t the focus of this chapter!

One of the new concepts that was introduced in this chapter was Nuxt. As you may have noticed, it has very powerful capabilities that enhance both the final product and the developer experience. You could consider Nuxt a default extension of any Vue application. I can get behind the philosophy of making it easy to do things right while making it hard to do things wrong. The opinionated setup that...