DEV Community: Dominique Péré

8 simple steps to add a serverless back end to a Vue.js project

Dominique Péré — Tue, 23 Jun 2020 10:01:26 +0000

It's often recommended in the JAMstack best practices to delegate to serverless cloud functions the dynamic parts of an app. To that end, let me introduce you WarpJS, a new serverless approach. It's a JavaScript engine to develop back ends, to bridge the gap with the front end and to deploy it as serverless functions in no time. Made for JavaScript developers with love!

Without any further ado, let's get started!

(If you don't feel like reading, we've also created a video tutorial for this!)

1. Initialize project

Starting from scratch, with a freshly created Vue.js project.

https://cli.vuejs.org/

$ npm install -g @vue/cli @vue/cli-service-global
$ vue create <project-name>

Alternatively, you can fork the project right here and skip all the code source copy/pasting steps.

2. Create the back end

Let's create a server directory at the root of your main project and initialize a new Node.js project inside it:

$ cd <project-name>
$ mkdir server
$ cd server
$ npm init

Here we will create a Basic HTTP Proxy in Node.js in order to:

Fetch data from a REST API (https://jsonplaceholder.typicode.com/users)
Filter data to avoid to request too much data as client side
Add random avatar in response

To do so, we first need to install the Axios library we need:

$ npm install axios

3. Create a serverless function

Then I create an index.js, and I retrieve first with Axios the flow. I will reduce the attributes, keeping only the id, the email… and a couple of others. I've also added a Lego random portrait (because.).

const axios = require("axios");

const getUsers = async () => {
  // fetch users from API
  const { data } = await axios.get("https://jsonplaceholder.typicode.com/users");

  // Pick attributes and add photo
  return data.map(({ id, name, email, phone, company, address }) => ({
    id,
    name,
    email,
    phone,
    city: address.city,
    work: company.name,
    photo: "https://randomuser.me/api/portraits/lego/" + (id % 10) + ".jpg",
  }));
};

But most importantly I export this function:

// getUsers will be the function that you will can call directly in the framework
module.exports = { getUsers };

This will tell WarpJS: "okay, I need this function to be turned serverless and to be hosted as a serverless function". That way we don't have at all to deal with HTTPS, we don't deal with the arguments, the errors, the endpoints, or anything else.

So now let's see how to set it up!

4. Configure WarpJS

In my server project, I need to create a WarpJS configuration file, warp.config.js as follows:

module.exports = {
  project: "project-server-name",
  output: {
    format: "node-module",
    // path to the "node_modules" directory of your main project
    projectPath: "../",
    // module name to import it in your main project
    name: "warp-server",
  },
};

Thanks to the node-module output format, WarpJS will generate an npm package named warp-server.

Why this option?

node\_modules is a safe directory: each framework uses tools like Babel, ESLint, … and here, you are sure that the generated code will not be transpiled or something else.

Really easy to import: no relative path to know, you can directly do: import WarpServer from "warp-server&quot;

5. Setup WarpJS in project

We now need the WarpJS CLI in the main project to:

Start the WarpJS emulator in development mode to simulate serverless function on localhost
Build the WarpJS client helper module in order to call the serverless function
Deploy the serverless function and optionally the static build of the main project

In the client project, you can now install the engine with all the dependencies.

You can request a WarpJS account by following this [link]https://scaledynamics.io/warpjs) 😬

$ npm install @warpjs/engine
$ npm install warp npm-run-all --save-dev

About the parent project, I want to change the way the project is served for local run, and built for deployment. To do this, I add scripts in package.json.

So we will go from this :

"scripts": {
  "serve": "vue-cli-service serve",
  "build": "vue-cli-service build",
  "lint": "vue-cli-service lint"
},

To this:

"scripts": {
  "postinstall": "cd ./server && npm install",

  "serve:client": "vue-cli-service serve",
  "serve:server": "warp start-emulator -w ./server",
  "serve": "run-p serve:*",

  "build:client": "vue-cli-service build",
  "build:server": "warp build ./server",
  "build": "run-s build:server build:client",

  "deploy": "warp deploy --asset-dir dist/ ./server",

  "lint": "vue-cli-service lint"
},

Let's break it down a bit to understand it clearly:

I'm turning the existing serve command to serve:client, because now I will basically build at once the server and client.

"build:client": "vue-cli-service build",

So here I have the warp emulator, helping me to emulate the serverless function:

"serve:server": "warp start-emulator -w ./server",

And here, I have the serve command, that will serve both the client and server on two distinct HTTP ports:

"serve": "run-p serve:*",

Then I'm adding whatever is needed to build the clients and the server for deployment:

"build:client": "vue-cli-service build",
"build:server": "warp build ./server",
"build": "run-s build:server build:client",

The client doesn't change, it's still my Vue project. The server will build with Warp because it's Warp serverless function.

I'm finally adding the "deploy" command, we'll how it works a bit later

"deploy": "warp deploy --asset-dir dist/ ./server",

6. Create the front end

Let's see now how we can call this serverless function from our front-end project.

First, you have to import the WarpJS engine, once for all in the app. We recommend to initialize it in the entry point of your main project:

// src/main.js

import "@warpjs/engine";

Now we create a new component — let's call this users.vue — and paste the template that you can find right here.

There is a CSS and a bit of JavaScript which will do the trick for us. So the only part of JavaScript we need is this:

<script>
// init WarpJS
import WarpServer from 'warp-server'
const { getUsers } = new WarpServer()
export default {
  name: 'Users',
  data: function() {
    return {
      users: null
    }
  },
  mounted: function() {
    getUsers().then((data) => {
      this.users = data
    })
  }
}
</script>

And actually the very part of WarpJS is

const { getUsers } = new WarpServer()

and

getUsers().then((data) => {

where we are actually calling the function. It feels like we're calling a local function but it's not, we are calling the serverless function.

Last thing I need to do is to call that component in my application, so I just replace the "HelloWorld" component from the template project, by my users component, I import the component itself, and I call the JavaScript.

<script>
import Users from './components/Users.vue'
export default {
  name: 'App',
  components: {
    Users
  }
}
</script>

So last thing to log in into WarpJS to be able to build and deploy this!

$ npx warp login

7. Run locally

It's pretty easy as we prepared the command line, we just have to type npm run serve, and then we serve both client and server. It opens a browser tab, and it's working!

We got everything, our users, filtered by the proxy, with the email addresses, the names…

8. Deploy front on CDN and back on Serverless

Let's see out deployed is now online. Actually, this is one of the simplest things to do with WarpJS. You just need to build, first, your project with the build command line we prepared

$ npm run build

and then we type in another command:

$ npm run deploy

We prepared it just before in be package.json. Let's have another look to that one:

"deploy": "warp deploy --asset-dir dist/ ./server",

This means I want WarpJS to deploy the server part from the "server" directory, and the asset directory to a CDN from the "dist" folder, which has just been built.

The server project is obviously deployed with WarpJS, on the cloud, here on Google functions, the front-end is deployed on a Google CDN (more options with AWS and Cloudflare are coming though)

Your project is now live!

So we got a URL, with our client and server: everything is hosted. We did not have to deal with the HTTPS security, the CORS, anything. Everything is just under control there.

You can find the full project code on GitHub under WarpJS/samples.

So we have examples with Angular as well with REACT, and obviously the full code for Vue.js I just did with you!

I hope you enjoyed this tutorial, and if you have any questions, please feel free to ask in the comment section!

Next in this series is a REACT and an Angular tutorial! So stay tuned ;)

Credits

Big thanks to Nicolas Pennec who developed the app we took as an example. He is a JavaScript Expert in ScaleDynamics. He co-organizes RennesJS, a French JavaScript Meetup, so if you come by Brittany you're more than welcome to join us!

Implementing a serverless API proxy in 10 minutes

Dominique Péré — Fri, 28 Feb 2020 15:49:58 +0000

This article has been updated on May 26th, 2020, following the latest release of WarpJS serverless.

Serverless has become a hot topic lately, as it offers auto-scaling, flexibility, and a shorter time to release. If like me you don't want to manage servers on a daily basis but rather focus on the features' code, serverless is an option you might want to consider.

Serverless is most commonly used for web applications and back ends, but also for data processing. By the way, there is a lot of noise and confusion about what serverless is, so, to be precise, I only mean Function-as-a-Service (or FaaS) when speaking about serverless here.

Most JavaScript full-stack developers develop their applications with React, Vue.js, or Angular, served by Node.js + Express. With the serverless approach, I see the opportunity of making development iterations shorter to free up time for what matters: the features' code.

In this post, I will explain how to implement a proxy server for REST APIs within a few minutes using a serverless platform.

Why would I implement a serverless API proxy?

In my use case, I wanted to create an app to request the GitHub Search API and NPM at once. I wanted to perform a search on JavaScript + TypeScript repositories to display GitHub stars and the NPM weekly downloads in the same view. It's useful to make a basic evaluation of package popularity.

We could do all this job in a browser. So why should we create a serverless HTTP proxy on top of the GitHub and NPM APIs?

Reason 1: security. API keys cannot lie in the front-end code. Malicious developers could use it to access my account, I would expose myself to renew it frequently or to be blocked by the API provider. Also, the Cross-Origin Resource Sharing (CORS) is blocked by many providers. In both situations, there's no choice than to implement a proxy server.

Reason 2: performance. To make my GitHub+NPM data feature available, we need to request GitHub twice and NPM a lot. My browser would then perform multiple requests for each user search. A proxy server in the cloud will have much lower latency and larger bandwidth to perform these requests faster. Additionally, the JSON returned by APIs contains much more data than we need. We only need from the GitHub API 7 properties and not the 50+ the original endpoints return for each repo.

Reason 3: separation of concerns. Whenever an API is updated, go down or I want to switch for another instead, my client code remains unchanged, I will only change my serverless functions' code.

Some other reasons to implement a proxy server include API modernization, caching, resilience, and error management, but it's another topic.

You may argue those are reasons to implement a proxy, not reasons to run it on a serverless platform, and you may be right. However, an API proxy is by definition a piece of our architecture that needs to be very elastic. It takes the first hit behind a user click so it needs to be ready to scale as the number of users grows. Good news: serverless scales horizontally by design, we won't need to know anything about Docker or Kubernetes to scale and fit with the traffic.

Now, let's see how we can implement that API proxy. To this end, I could use any serverless platform, such as AWS Lambda or Google Functions. However, I recently joined the company powering WarpJS serverless and I have to admit that their stack, built on top of the cloud providers, saves many steps like the serverless function declarations, the endpoint management or the deployment to a public URL. This JavaScript serverless platform is kind of all-in-one: front end and back end are deployed at once.

Let's get to it now!

Steps to turn a native JavaScript function into a serverless function

Prerequisites

Linux, macOS or Windows
Node.js >= 8
Git
A GitHub account

Stack

Vue.js
Axios
WarpJS serverless

Together, we will go through the different steps of initializing our GitHub Search project, walk through the specific GitHub+NPM search feature we want, and see how to turn a pure JavaScript function - here the search function - into a serverless function that will behave as an HTTP proxy. We will run everything on our local computer before deploying both front end and back end on a cloud platform with a command-line to get a live URL.

We have developed a small Vue.js application to list the repositories matching a certain keyword. Here is what it looks like:

We can download this project using the following command-line

$ git clone https://github.com/WarpJS/github-repo-search.git

...and set up our project

$ cd github-repo-search
$ npm install

While it's downloading, let's have a look under the hood. If you have any trouble with node-gyp after install, see the official "node-gyp" installation doc.

The back-end serverless function

First, the back end. The script api/index.js contains only the server-side logic, No HTTP, no endpoint, no argument control, no serialization: only the function "juice".

/**
* Search repositories
*
* @param {string} query
* @param {number} page
*/

const search = async (query, page = 1) => {
  ...
};

module.exports = { search };

The "search" function needs to be exported to tell WarpJS it needs to be exposed as a serverless function. After deployment, such functions will run on Node.js on your preferred serverless platform, such as AWS Lambda, Google functions, or others as long as WarpJS serverless supports it.

The helper module to call the serverless function

Next, we need a way to tie our front end to our soon-to-be-deployed serverless function. This is the job of WarpJS. To do this, we first need to create a WarpJS account, as the builder also deals with cloud serverless FaaS providers: that’s why you need a cloud account (this step also prevents you from creating an AWS or a GCP account).

If you don’t already have one, you request a WarpJS serverless account. As I write these lines, WarpJS is in private beta, so I just gave you my personal invitation link. Please make good use of it ;) Then you just need to log in to WarpJS within your terminal:

$ npx warp login

It saves your credentials to a local file so you only need to do this once for all your projects.

The following command-line calls "npx warp build", which creates a JavaScript helper module for the client (a "stub") according to the configuration set in the api/warp.config.js. Here, we generate it as an npm module in the parent project, but we could output it as a JavaScript file as well, and import it with a tag, as <a href="https://warpjs.dev/docs/api/cli#output-formats">detailed in the doc</a>. Run this command-line to generate a serverless adapter as a module in our client project: <div class="highlight"><pre class="highlight shell"><code>$ npm run build </code></pre></div> This is replacing the HTTP layer. We don’t need to refer to an API doc nor to code any HTTP request. Our client file is now ready to be imported into any JavaScript project. <h3> <a name="the-front-end" href="#the-front-end" class="anchor"> </a> The Front end </h3> The front end is a classic <a href="https://vuejs.org/">Vue.js</a> single page app with a search box followed by a list when the results come. We would find details about the front-end app in the app.vue file. We import the "github-repo-search-api" module, a "stub" to call our serverless function. <div class="highlight"><pre class="highlight javascript"><code>// init WarpJS import Warp from 'github-repo-search-api'; const api = new Warp(); ... // fetch api with warp const { repositories, total, error } = await api.search(this.search); </code></pre></div> The "api" object, an instance of Warp, is our FaaS adapter - our helper module - to call our serverless function. This way it is super easy to call any back-end function with no HTTP headache, no endpoint codification, no argument serialization, and no response deserialization. <h2> <a name="how-to-run-a-serverless-function-on-a-local-environment" href="#how-to-run-a-serverless-function-on-a-local-environment" class="anchor"> </a> How to run a serverless function on a local environment </h2> Before we can run this code, we first need to generate an access token for GitHub <h3> <a name="generate-a-github-access-token" href="#generate-a-github-access-token" class="anchor"> </a> Generate a GitHub access token </h3> We need to authenticate to generate a GitHub access token that will be used in our application. <ul> <li>Navigate to GitHub to <a href="https://github.com/settings/tokens/new">generate a new access token</a></li> <li>Give it a name</li> <li>Only check the "public_repo" scope (this is all we need in our example)</li> <li>Generate Token</li> <li>Get back to the api/index.js and replace YOUR_API_TOKEN with yours. </li> </ul> <div class="highlight"><pre class="highlight javascript"><code>// ./src/api.js // GitHub auth token const GITHUB_ACCESS_TOKEN = 'YOUR_API_TOKEN'; </code></pre></div> <h3> <a name="local-run" href="#local-run" class="anchor"> </a> Local Run </h3> We're all set, let's now test locally. We open a terminal in the project folder and run <div class="highlight"><pre class="highlight shell"><code>$ npm run dev </code></pre></div> This opens our app in a new browser's tab. We can take a minute to play with it... At any time, we can change the code and save, the session refreshes the browser, so we don't have to relaunch our local server thanks to a live reload feature. Actually, in development mode, the <a href="https://warpjs.dev/docs/api/cli#start-emulator">WarpJS serverless emulator</a> dynamically injects the functions in the server to prevent it from rebuilding and restarting. This saves us a lot of time on the development/debugging phase. Feel free to make any changes you wish to customize our little app. The local run is cool to test, but let's deploy now. <h2> <a name="how-to-run-a-proxy-in-a-serverless-environment" href="#how-to-run-a-proxy-in-a-serverless-environment" class="anchor"> </a> How to run a proxy in a serverless environment </h2> All we need now is to build our project, front and back ends: <div class="highlight"><pre class="highlight shell"><code>$ npm run build </code></pre></div> ... and then, the awesome command-line to deploy it all at once 🤓 <div class="highlight"><pre class="highlight shell"><code>$ npm run deploy > github-repo-search@1.0.0 deploy /Users/dom/src/github-repo-search > warp-deploy --asset-dir=dist . Deploying.............................. Deployed project 'github-repo-search' at: https://warpjs-xxxxxxxxxxxxxx.storage.googleapis.com/index.html </code></pre></div> And it's done! Our web app is now live on a public URL. We can copy/paste the last line in our favorite browser and share it with coworkers or friends. As we can see in the URL, it's deployed on GCP. WarpJS runs above the cloud providers, so we can run it where we need to. Regarding the cloud credits, the beta version does limit usage with a strict limit, just "fair use". Whatever, it's all free for now 🤑 If you want to get inspiration to develop some other kind of serverless app, we have a bunch of serverless <a href="https://github.com/WarpJS/samples">code samples</a> to deal with authentication, storage, and even in-browser Machine Learning... As I write this article, WarpJS is still in the beta stage but the platform will soon offer options to: <ul> <li>deploy on a customized domain name (removing the banner by the way)</li> <li>deploy on multiple clouds for the same function such as AWS Lambda and Azure function serverless platforms,</li> <li>deploy on-premise or on hybrid cloud.</li> </ul> Those are probably topics for a next post 😁 I hope you enjoyed this reading, learned, had fun, and you now like serverless as much as I do. Feel free to comment on this article to let me know what you think or to share your experience. <h4> <a name="credits" href="#credits" class="anchor"> </a> Credits </h4> Big thanks to <a href="https://twitter.com/NicoPennec">Nicolas Pennec</a> who developed the app we took as an example. He is a JavaScript Expert in ScaleDynamics. He co-organizes RennesJS, a French JavaScript Meetup, so if you come by Brittany you're more than welcome to join us!