Use serverless to serve your server-side rendering project (Vue, Quasar)

In the Vue JS (or React) community, there are still many questions about server-side rendering (SSR) and when to use it, there are a few points that we’ll cover right now in this article. Also, I am going to showcase to deploy a server-side rendering project in AWS lambda with serverless. Let’s dive in now!

Image for post
Image for post

Frameworks and tools we will be -

  1. Vue Js (https://vuejs.org/)
  2. Quasar Framework (https://quasar.dev)
  3. Serverless (https://serverless.com/)

First, you need to understand the basics of SSR and CSR:

The main difference is that for SSR your server’s response to the browser is the HTML of your page that is ready to be rendered, while for CSR the browser gets a pretty empty document with links to your javascript. That means your browser will start rendering the HTML from your server without having to wait for all the JavaScript to be downloaded and executed. In both cases, React will need to be downloaded and go through the same process of building a virtual dom and attaching events to make the page interactive — but for SSR, the user can start viewing the page while all of that is happening. For the CSR world, you need to wait for all of the above to happen and then have the virtual dom moved to the browser dom for the page to be viewable.

From upwork.com

For CSR application, the client needs to wait for all the response come back from your server, and have to wait for all the javascript to be downloaded and executed, then the browser starts to get the HTML of your page render. On the flip side, in the SSR world your server’s HTML response is already to be rendered, thus have the virtual dom moved to the browser dom for the page to be viewable.

There are two main benefits of using server-side rendering application:

  1. Performance benefit for your visitor
  2. Consistent performance for various devices and browsers

Making a scalable SSR application is challenging as SSR throughput of your server is significantly less than CSR throughput, which stands that more resources would be consumed, and is need more efforts to set up and maintain, compared to you can host a CSR application in a static content bucket and it works in a flick! Serverless computing comes to the party in this case, it offers greater scalability, more flexibility and quicker time to release, all at a very minimal cost, also you never have to deal with servers or runtime to keep your website run fast 24/7.

Vue.js are frameworks for building client-side applications. By default, Vue components produce and manipulate DOM in the browser as output. However, it is also possible to render the same components into HTML strings on the server, send them directly to the browser, and finally “hydrate” the static markup into a fully interactive app on the client.

In the following demo, I will be using Quasar Framework to create a Vue SSR application, if you never user Quasar Framework before —

Quasar is a high performance, Material Design 2, full front-end stack for Vue.js.

It’s an MIT-licensed, simple-to-use but powerful UI kit that supplements Vue.js to provide a full-featured toolset for building responsive front-end apps without having to delve too deep into the scaffolding and configuration.

feel free to look at a short article I wrote before, I will using the same code base to set up an SSR project

From here I assume everyone has a Quasar app set up and ready to get our hands dirty!

Let’s go to the Quasar app folder

Image for post
Image for post

In the directory, you will have to create a serverless.yml file, in which all the lambda functions in your serverless service can be found. In this example, only one service will be created.

To get the serverless dependencies installed

$ npm install --save-dev serverless serverless-apigw-binary serverless-offline@^5.11.0
$ npm install --save serverless-http

SSR in a Quasar project is served by a Node web server, we will be proxying all routes from serverless function into the Node server,

handler: handler.serverevents:    - http: ANY /    - http: ANY /{proxy+} <- catch any path that match

Secondly, we will have to install SSR mode into our quasar app by running-

$ quasar mode add ssr

Then jump right back into development

$ quasar dev -m ssr

Once the page is rendered in the page, try to inspect the HTML response sent back, the APP div should be hydrated with the server.

Image for post
Image for post

Boom!! Your SSR app is now ready, what next?

Serverless function is not supported by Quasar framework out of the box, we would need to make some change with the node web server scripted just created. Adding SSR mode to a Quasar project means a new folder will be created: /src-ssr, which contains SSR specific files which define your production Node webserver:

└── src-ssr/    
├── index.js # Production Node webserver serving the app
└── extension.js # Common code for production & development server

To make the node web server work correctly with AWS Lambda, you need to generate AWS Lambda wrapper. We will be replacing the HTTP web server with serverless-http the module.

Go into src-ssr/index.js replace the very last bit where the express app starts listening, inside lambda function an HTTP event entry point has been defined already.

Image for post
Image for post

We are just a few steps away to get the application to be deployed in AWS hang on! Before setting up the serverless handler, I assume you already understand API gateway and AWS Lambda. Also, to let all the content and assets served properly by AWS API gateway, binary modes need to be enabled, and the function will base64 encode a response body if the Content-Type or Content-Encoding matches a known binary type/encoding. This means you can gzip your JSON or return a raw image, but it requires advanced configuration within API Gateway and sees the handler file I have set up.

Add the file below into the project folder at handler.js

You should be noticing I used the web server file in dist folder so we will require the build files to be ready before we can test locally.

After this, we are all set and run

quasar-ssr-example / $ sls offline start

Your app should now be rendered at http://localhost:3000, and all the files and assets should be served by local serverless function!

Image for post
Image for post

Full source code is available at https://github.com/gordonlkc/quasar-ssr-example

What next?

  1. Set up CICD pipeline to get it deployed to AWS
  2. Set up a custom domain in AWS

After making this example, I have moved my personal portfolio into a same configuration, there is a 50% load time improved mainly the load and scripting time of the page have been increased for >50%!!

Image for post
Image for post

My updated portfolio at https://me.gordonlam.space

In the next chapter, I will go through how to deploy this SSR with Github actions so it is fully CICD integrated. Stay tuned for part2!

If you have a question, if I have forgotten something to address, leave your comment, share your experiences with SSR. see you in the next post.

Written by

Full stack developer | Working @ https://resolution.systems | https://me.gordonlam.space

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store