Creating a Quasar Framework application with AWS Amplify services (Part 1/4)
Update 2/14/2022 — Please try https://github.com/mfreeman451 to find my repository for this tutorial.
In this tutorial, you will learn how to create and deploy a Quasar V1.0 (beta) application using the AWS amplify CLI. We will bring in authentication using AWS Cognito, a GraphQL API layer from AWS AppSync configured for a DynamoDB back-end and AWS ElasticSearch, cloud hosting through AWS CloudFront and AWS S3, and more.
While you may have already seen many of the concepts and instructions in this tutorial, this document attempts to combine them all into one place and give the reader a clear and concise path forward to Quasar Framework with AWS Amplify and a reference implementation.
Quasar Framework is a pragmatic, Material Design, full front-end framework built on top of the immensely popular VueJS Javascript library. Quasar allows you to maintain one codebase and easily create web, desktop, mobile, and native mobile applications using Electron and Cordova.
AWS Amplify is a framework from Amazon AWS that attempts to make it easy to create and configure scalable web applications powered by AWS. Amplify is used to provision and create cloud resources and also provides Javascript libraries for React, Vue, and others. Amplify is comprised of multiple components, including the Amplify CLI, Javascript library, and Amplify Console.
The AWS Amplify Javascript libraries provide the following:
- Authentication hooks into AWS Cognito
- AppSync/GraphQL support
- Drop-in analytics using AWS Pinpoint
- Storage hooks for AWS S3
- Push notifications
There are more services advertised on the Amplify homepage but these are the ones we are going to be concerning ourselves with for now.
The AWS Amplify CLI is a toolset for creating, deploying, and updating these resources, it allows you to:
- Create new Amplify projects
- Setup and configure your AppSync service and deploy a schema
- Create and configure Static hosting from AWS CloudFront using AWS S3 buckets
- Automatically create Cognito authentication rules and roles, and the appropriate associations with the components you’re deploying**
Before we get started, please keep in mind that there are a lot of moving parts here, I will attempt to explain those that I think are important or will help you understand how things fit together, but for the sake of brevity, I will try to link to important resources that will probably offer better explanations than I can provide.
“The key to understanding complicated things is to know where not to look, what not to compute, what not to think..” — Gerald Jay Sussman (SICP)
Getting Started
The first step is to create the Quasar application. We will be using the Quasar V1-beta release and Quasar CLI to create our initial project. There are a few different ways of using Quasar, but I think this makes the most sense.
Installing Quasar CLI:
$ npm uninstall -g quasar-cli
$ npm install -g @quasar/cliWe will uninstall any legacy versions and then create our Quasar project using the CLI:
$ quasar create quasar-demo -b devIf you are familiar with the legacy CLI, you will notice that we added ‘-b dev’ to tell the CLI that we want to build a V1 project.
Follow the prompts, we will be assigning the project name, description, author, and the features needed for your project. We will include ESLint, Vuex, and Axios.
That’s it! We now have a working Quasar application that by default produces a Single Page App (SPA), but can easily be configured for SSR and/or Progressive Web Applications (PWA). If you’re confused about SPA/PWA, check out this link for a gentle introduction.
SSR-based mobile applications offer speed advantages by rendering content server-side and then delivering pre-rendered and pre-hydrated html, css and js to the client, also helping to improve your SEO by making the content searchable or discoverable by search engine crawlers. Another often overlooked benefit of SSR is that protected routes can be enforced on the server, so the interface (and obviously content) isn’t even available to the browser.
This comes at a price, however, because SSR requires more infrastructure, scaleable architecture, and caching systems to support all that server-side rendering.
On a final note, the crawlers have evolved and offer better support of Javascript powered websites, so the impetus to use SSR has lessened.
We will be developing our Quasar application in “SPA” mode but will ultimately configure it to be a PWA when deployed. You will find that out of the box, when built and deployed, Quasar gives you a great LightHouse score. You can easily develop your application as SPA and then switch to PWA when deploying to production environments. Testing PWAs becomes a nuisance as well since everything is cached by service-workers in the browser, so if you’re developing and testing a live PWA, you will need to do a lot of refreshing and cache clearing (or install a testing harness like Cypress via the quasar-testing extension, which takes care of that for you).
Starting up your Quasar development environment
To get started with Quasar, lets bring up the development environment (SPA mode):
$ cd quasar-demo
$ quasar dev
Open a web browser and navigate to http://localhost:8080
The default Quasar application should look something like this:
Amplify it!
Next we will add the AWS Amplify CLI and initialise our new Amplify project from the command-line.
$ npm install -g @aws-amplify/cli
$ amplify configureFor a full walk-through on how to use ‘amplify configure’, see this link.
Let’s go ahead and install some of the other AWS npm modules we’ll need as well:
$ npm install --save aws-amplify
$ npm install --save aws-amplify-vue
$ npm install --save aws-appsync
$ npm install --save graphql
$ npm install --save graphql-tag
$ npm install --save vue-apolloCreate a new Amplify project
After configuring the Amplify CLI, we will initialise our project:
$ amplify initChoose a project and environment name (dev or prod, generally), and your default editor:
Next choose the type of application that you’re building, we are using ‘Javascript’:
When prompted to choose a framework, choose ‘none’:
Choose the defaults for your Source Directory and Distribution Directory Path:
It is important to change the default Distribution Directory Path to dist/pwa
Next, you will be prompted to choose your build commands. Since we are building a PWA, we will tell the Quasar CLI to build us one.
Build Command: quasar build -m pwa
Start Command: quasar serve --history dist/pwa
When prompted, select the default to continue using your AWS profile:
After this, the AWS amplify CLI will start deploying the AWS CloudFormation templates it has created (and stored somewhere in the amplify/ directory). This may take some time, be patient as interrupting this process comes with manual cleanup consequences.
Adding AWS Amplify resources to our project
Next we will use the Amplify CLI to add our API (AppSync) layer, auth (Cognito), and hosting (S3/CloudFront HTTPS):
$ amplify add auth
Select the default configuration, we will do more with Cognito later.
Before we continue, let’s check the status of our Amplify deployment:
We can tell by the ‘Operation’ column/row data that the Auth component has not been deployed yet. We will add more services and then push and publish our application when we’re finished.
Adding the AppSync API layer
$ amplify add apiChoose the ‘GraphQL’ option:
Provide the API name (quasarDemo) and select Amazon Cognito User Pool for the API authorization type.
This configures a Cognito User Pool that we will later use to manage the users that will sign-up and login to our application and is used to authenticate our calls to the AppSync GraphQL layer.
Next we will be asked to create a schema. You will be asked if you have an annotated Schema, select N for now. In the real-world, it is a good idea to do this once and then save that schema off into a file that you can refer to in case you need to build this project again. We will walk through the process of creating a very simple GraphQL schema to get us started.
Next, select the default ‘Single object with fields’ and then select the option to edit the schema now.
I am building my project with Microsoft VS Code on MacOS, after selecting the option to edit the schema, a window is presented in VSCode that allows us to edit the schema:
Modify the defaults — we will be adding the @searchable transformer to the type, and two new fields, owner and dateTime. The @model transformer tells Amplify/AppSync to create a table in DynamoDB modeled after our GraphQL schema, and @searchable does the same in AWS ElasticSearch. Finally, the @auth transformer says only the owner can query or mutate their own data and also eliminates the need for us to define our own custom resolver for the queries and mutations. You may have noticed how we are using a scalar type specific to AppSync. You can read about additional scalar types for the AppSync schema here.
After we’re done making our changes, save the file in your editor and we’ll switch back to the terminal window to continue the configuration process:
In part 2 of Creating a Quasar Framework application with AWS Amplify services, we will finish our AWS amplify deployment.
My name is Michael Freeman, I am a member of the Quasar Framework staff and a full-stack developer working with VueJS, GraphQL, Kafka, and Apache Spark. I also specialize in Network Management Systems.
More information
If you need more information about Quasar, here are a few links that you can check out for your consideration:
