Deploy Github Sub Directory To Azure

In this blog post, I would walk you through publishing a sub directory of your Github repository to the Azure.

The first step would be to head over to your desired Resource Group in Azure Portal and Create a Web App Resource.

For sake of demonstration, we would be publishing a web portal build using VueJS. For the same reason, we are using a Runtime of Node 12 LTS.

Once you have created the Web App resource, head over to Deployment Center and choose Github under the Continuous Deployment Section.

If you are doing this for the first, you might be prompted to Authenticate your Github Account. Next, you need to Build Provider. We will choose Github Actions in here.

This would lead you to the following screen, which would help in choosing your repository.

The Add or overwrite workflow definition would generate the Github workflow for deployment. This looks something similiar to the following.

name: Build and deploy Node.js app to Azure Web App

on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: windows-latest

    steps:
    - uses: actions/checkout@master

    - name: Set up Node.js version
      uses: actions/setup-node@v1
      with:
        node-version: '12.13.0'

    - name: npm install, build, and test
      run: |
        npm install
        npm run build --if-present
        npm run test --if-present


    - name: 'Deploy to Azure Web App'
      uses: azure/webapps-deploy@v2
      with:
        app-name: 'yourappName'
        slot-name: 'production'
        publish-profile: ${{ secrets.YourSecretKey }}
        package: .

As you have noticed, the workflow also contains a secret key which would be used for authenticating the publish action.

So far, this has been quite similiar to how you would publish an entire repository in Github to Azure. But as mentioned earlier, we are particularly interested in publishing a sub directory in the Github repository. For this purpose, we will begin by ensuring the npm build actions are done within the particular sub directory.

For the same, we modify the workflow, with the following changes.

    - name: npm install, build, and test
      run: |
        npm install
        npm run build --if-present
        npm run test --if-present
      working-directory: portalDirectory/subDirectory


As you can observe, we have instructed the action to use a particular working directory while running the NPM scripts. However, we are not done yet.

Just like we ensured the npm build is done against the desired folder, we also need to ensure that only the desired sub folder gets published.

If you attempt to use working-directory with the ‘Deploy to Azure Web App’ Step in the action, you would be prompted with an error that working-directory cannot be used with an action that contains a with statement.

The .deployment file comes to our rescue at this point. The .deployment file needs to be created in the root of your repository. We will add the following contends to the file.

[config]
project = portalDirectory/subDirectory/dist

That would be all you need. The .deployment file would instruct the CI/CD process to deploy the contends of the portalDirectory/subDirectory/dist directory to Azure.

I hope that did help you.

Axios Interceptors and Exception Handling

Handling exceptions globally and gracefully is essential part of any application. This reduces the scattered try-catch cases and enable to handle everything from one point.

In this article, we will explore how to implement global exception handling when making Api calls in an SPA design. We will use VueJs for demonstration along with Axios packages to assist the Http calls.

Axios Interceptors

Interceptors in axios provide a great oppurtunity to handle responses at a single point. Interceptors are methods which is invoked for every axios request and hence, allows you to intercept and transform the response before it makes its way to calling method.

To begin with, let us head over to our main.js and import axios

import axios from "axios";

Axios exposes two types of interceptors, one each for request and response.

Response Interceptor

For our purpose, we need the response interceptor (we will breifly speak about the request interceptor later). Axios invokes the response interceptor after the request has been send and response recieved. You could intercept this response using axios.interceptors.response.use, modify it to suit your needs before sending it back to the calling method.

axios.interceptors.response.use(
  (response) => successHandler(response),
  (error) => exceptionHandler(error)
);

The method accepts two parameters (second one is optional), each corresponding to a valid and error Response, which would be invoked depending on whether the request has succeeded or failed.

Let us plugin our interceptor in main.js to intercept the errors.

axios.interceptors.response.use(
  (response) => {
    return response;
  },
  (error) => {
    switch (error.response.status) {
      case 401:
        // Handle Unauthorized calls here
        // Display an alert
        break;
      case 500:
        // Handle 500 here
        // redirect
        break;
      // and so on..
    }

    if (error.response.status == 400) {
    }
    return Promise.reject(error);
  }
);

I ususually handle my BadRequst calls within the component. I could hence write a special response in the switch case for Error Code 400, which does the same for me.

Modifying the switch case,

switch (error.response.status) {
  case 400:
    return {
      data: null,
      hasError: true,
      error: [error.response.data],
    };
  case 401:
    // Handle Unauthorized calls here
    // Display an alert
    break;
  case 500:
    // Handle 500 here
    break;
  // and so on..
}

As seen, the interceptors provides us a global platform the handle exceptions.

Request Interceptor

A word about the request interceptor before signing off – The request interceptors are called each time before the request is made.

This provides an great oppurtunity to inject/modify headers to include authentication tokens. For example,

axios.interceptors.request.use((request) => {
   const header = getHttpHeader(); // get your custom http headers with auth token
  request.headers = header;
  return request;
});

The interceptors could be also used to show busy indicators while the request is being processed as both request interceptor and response interceptor provies us a window of oppurtunity to display a indicator before the request is send out and hide the indictor as soon as the response is recieved.

Hope that was useful.

Private Routes using VueJs

Quite often in your application, you could come across when certain pages/routes could be accessed by only authenticated users. And then there are other pages, which could be access be any one.

I tend to call them by private routes and public routes. Private Routes requires a certain condition to be met, for example, the user needs to be authenticated. We could also have additional conditions like the user needs to have a certain privilege. If the condition is not met, the user attempting to navigate to the private route needs to be redirected to a common route, usually in public route.

In VueJs, the Navigation guards allows you to intercept the navigations and conditionally evaluate whether or not to accept the redirection or cancel it. While there are multiple ways to intercept the navigation process, per-route, in-component, the easiest way would be to use the the Global Guards.

Global Before Guards

The beforeEach guard method is probably the most common approach to handle navigations. The method is called each time when a new navigation starts.

You could add the validation code in the beforeEach method to ensure only the validated users access the pages.

const router = new VueRouter({
  routes,
});

router.beforeEach((to, from, next) => {
   // Your validation logic goes here.
});


The beforeEach Method accepts 3 parameters.

  • to : The future Route
  • from : the current Route
  • next : a function that should be called to resolve the route successfully.

Real World Scenario

Let us consider a real world scenario. You have couple of routes in your application.

const routes = [
  {
    path: "/",
    name: "Default",
    component: Default
  },
  {
    path: "/login",
    name: "Login",
    component: Login
  },
  {
    path: "/dashboard",
    name: "Dashboard",
    component: Dashboard
  },
];

Ideally, you would like the Default and Login to be accessed by anyone. However, the Dashboard should be accessed only by authenticated users only.

We begin by including this very bit of logic in our route definition. We could use the meta tags for including additional information. Redefining our routes now,

const routes = [
  {
    path: "/",
    name: "Default",
    component: Default,
    meta: {
      requiresAuth: false,
    },
  },
  {
    path: "/login",
    name: "Login",
    component: Login,
    meta: {
      requiresAuth: false,
    },
  },
  {
    path: "/dashboard",
    name: "Dashboard",
    component: Dashboard,
    meta: {
      requiresAuth: true,
    },
  },
];

As you can observe, we have added a requiresAuth flag within the meta information of routes. With this in place, we could now alter our beforeEach code as following.

router.beforeEach((to, from, next) => {
  if (to.matched.some((record) => record.meta.requiresAuth)) {
    if (isAuthenticated()) {
      next();
    } else {
      next("/");
    }
  } else {
    next();
  }
});

The method now checks if the to route has the meta information flag of requiresAuth set to true and if so, calls your custom isAuthenticated method to verify if the user is authenticated to access the page.

If the user is authenticated to access the page, the next() method is called to complete the navigation successfully. Otherwise, you override the to route and navigate away to a custom route, in this case using next(“/”).

That’s all your require for creating private routes using VueJs. If you would like to see the complete code, you could find the same here in my Github.