Building a Multiplatform Expense Tracker Using Quasar

In this chapter, we’ll iterate the topics and techniques we covered in Chapter 6. We’ll build a similar app using Vue and rely on Supabase to store our data. In this chapter, however, we’ll focus on building an app that can be deployed on multiple platforms other than the web.

We’ll use Quasar (https://quasar.dev/) as our framework of choice since it allows us to choose multiple different types of platforms. For the sake of simplicity, we’ll focus on creating a desktop application based on Electron (https://www.electronjs.org/). Both Quasar and Electron are well-maintained open source projects with excellent documentation and active communities.

In this chapter, we’ll cover the following topics:

• Solidifying what we learned previously
• Familiarizing yourself with different frameworks
• Understanding the value of platform-agnostic development
• Building a native app using...

Technical requirements

In this chapter, we’ll be reusing most of the requirements from Chapter 6 since we’ll be building an application with similar capabilities. This will help you identify how the framework impacts the architecture of an app.

We’ll be depending heavily on Quasar (https://quasar.dev/) as our foundational framework. Since the framework also offers UI patterns (https://quasar.dev/components), we don’t need Vuetify in this project. We will use Pinia (https://pinia.vuejs.org/) to handle our application state. To store the data, we’ll create a new project in Supabase (https://supabase.com/), an open source database provider with built-in authentication. For the database, I’ve prepared a script to create the databases and another one to add example data. We’ll cover those steps in the Setting up the database section.

The final product is located in this book’s GitHub repository at https://github.com/PacktPublishing...

Setting up the database

We’ll start by fulfilling our database needs. We already have a free account (see Chapter 6). We’ll create a new project called expense-tracker, set a strong database password, and assign a geographically close region.

You’ll be redirected to a view that provides you with Project URL and API Key details, as shown in Figure 7.1:

Figure 7.1 – API settings for our expense-tracker project

Since our application isn’t ready, we need to note the URL and API key down in a safe place or simply revisit this page once we get to the application.

For this project, I’ve prepared a script to create the required tables and settings for our database called example-structure.sql. Open the SQL Editor in Supabase, then paste and run the contents of the script:

Figure 7.2 – Success message after running the example-structure.sql script

Our expense tracker will be able...

Using Quasar to build a project

We’re going to follow the default setup and installation guide at https://quasar.dev/start/quick-start. In the CLI, we’ll run npm init quasar and select the configuration, as shown in Figure 7.4:

Figure 7.4 – Creating a new project using the Quasar CLI

This will install the project and its dependencies. Once the initialization is completed, we can navigate to the project folder and install the Supabase JavaScript client via the CLI:

npm install @supabase/supabase-js

To conclude the initialization, we’ll create a .env file with the Supabase API keys:

VITE_SUPABASE_URL=YOUR_SUPABASE_URLVITE_SUPABASE_ANON_KEY=YOUR_SUPABASE_ANON_KEY

We can verify our installation by running the following command in the command line:

npx quasar dev

The example project will be installed, as shown in Figure 7.5:

Figure 7.5 – The default project using Quasar

Since our...

Authenticating with Supabase and Quasar

Having an application rather than a website means that external hyperlinks, such as the OTP method of signing in via Supabase, will not work out of the box. Handling these issues is a bit too advanced for this chapter, so we’ll opt for signing in via email and password. To have Supabase and our Quasar application integrate nicely, I’m loosely basing our implementation on the following online resource: https://dev.to/tvogel/getting-started-with-supabase-and-quasar-v2-kdo.

The src/boot folder is meant for scripts that need to be executed before we initialize the Vue.js application (https://quasar.dev/quasar-cli-vite/boot-files/). In our case, we need to utilize the boot files because we want to execute logic before we change a route, to see whether a user has access. This means we need to handle our authentication and Supabase client in scripts that are executed before the main scripts of our app.

First, we’ll create...

Building the app with the Quasar CLI

The Quasar CLI offers some commands to quickly build and publish an Electron app. It is important to realize that at this point, the output of the default build script defaults to supporting only your current operating system and architecture! That’s a good way to test the app, so let’s see what happens. We can generate our app code by running the following command in the terminal:

quasar build -m electron

This will take a bit longer to process than spinning up the development server: first, Quasar builds the files for the web and then uses that production-ready code with Electron to compile a native app. Once the processing is done, you can locate the build output files in the /dist/electron folder of your project. You should also be able to execute your app now!

Next, we’ll improve the visual identity of the application by creating and providing our custom app icon.

A custom icon

With any application, an icon...

Summary

In this chapter, we unlocked a powerful capability: we started with what we learned in Chapter 6 and built a web application. Using Quasar’s available features, we processed our code and deployed our web application as a standalone desktop application that’s suitable for multiple platforms.

We also adopted another framework to build an app. Instead of Vuetify, we relied on the default components that Quasar offers. This way, we’ve seen and experienced slight differences in code styles in building applications, using frameworks and build tools. We also experienced similarities, for instance, in the usage of Pinia as a centralized store.

This way of app building is not always the most suitable. There are some limitations and tradeoffs. On the upside, you only have to build one application and can deploy it to multiple targets. The cost efficiency of this development method makes it a serious candidate for multi-platform strategies.

In the next chapter...