For any developer, the debugger is the best friend. One can easily find bugs in software with a debugger.

One can add a breakpoint to pause execution. Secondly, one can also add logic to a breakpoint to halt the execution. As an example, consider a for loop having 1,000 iterations. The execution should stop when the iteration count reaches above 100. To do so, put a breakpoint on the for loop. Next, add the logic to halt the execution when the iteration goes above 100.

Besides halting a program, debuggers show memory allocations. For example, halting the execution will show memory consumed at any given point.

What Is a Remote Debugger?

Debugging is usually done on a localhost. Doing it remotely is called remote debugging :). That is, if you debug software running on a remote host, its called remote debugging. It is helpful for multiple reasons.

For one, one can debug software locally. Consider a scenario where software is on the cloud. It might be deployed either for dev, UAT, or production. Now an issue happens on the cloud but not on the localhost. In this case, it would be very helpful to connect to the cloud and attach the debugger to the process. One can execute the software line by line to evaluate the issue and fix it.

Secondly, remote debugging is also useful when the software is running inside a container. Let’s say a project is running inside Docker. One won’t be directly able to run the project and connect to it via the debugger. Instead, the docker container should expose its container port. Secondly, the remote debugger needs configuration to connect the project inside the docker container.

Docker helps create portable containers that are fast and easy to deploy on various machines. These containers can be run locally on your Windows, Mac & Linux. Also, major cloud systems like AWS or Azure do support them out of the box. If you want to learn more Docker basics and need a cheat sheet for Docker CLI, here is an introductory article about it.

In this article, we will set up a NodeJS project to run inside a docker container. We will also set up a remote debugging for the project.

If you love this article so far, please follow me and do check out other such awesome articles on my profile.

Setting Up the Project

Prerequisites

Before we move further, the system should have docker desktop and VS Code installed. Other than that, no other requirements are there.

For the hasty ones, I have made the source code available as a repository. You can check it out here.

Creating Project Files

We are going to create a very simple express Node JS project. It will simply return a static JSON string on opening a specific URL. For this, we will create a file named server.js, which is the entry point to our project.

Create a server.js file with the following contents:

const server = require("express")();
server.listen(3000, async () => { });
server.get("/node-app", async (_, response) => {
    response.json({ "node": "app" });
});

The server.js file states that display {“node”: “app”} on opening http://localhost:3000/node-app URL in the browser.

Secondly, we will need a package.json file to configure the project and add dependencies. For that, create a package.json file with the following content:

{
    "name": "node-app",
    "dependencies": {
        "express": "^4.17.1"
    }
}

Run the npm install command to install the dependencies locally. This will create a node_modules in the project directory.

Even though we will be running the project inside a container, the dependencies need to be installed. It is needed since we will be mapping our current project directory to a container project directory. It is explained below how to do so.

Running as Docker Container

A Dockerfile is needed to run the project as a docker container. Create a Dockerfile with the following contents:

# Download the slim version of node
FROM node:17-slim
# Needed for monitoring any file changes
RUN npm install -g nodemon
# Set the work directory to app folder. 
# We will be copying our code here
WORKDIR /node
#Copy all files from current directory to the container
COPY . .
# Needed for production. Check comments below
RUN npm install

Here, the project is set up to run as a simple node server without allowing any breakpoints. The container will be running the project out of a node directory inside the container. nodemon is installed globally in the container. It’s needed for watching any file change in the directory. It is explained in detail below.

The RUN npm install command is needed only when deploying to production. We will map the /node directory of our container to the current project directory on localhost using Docker Compose (next section). But when the app is deployed on the container, it needs to install the dependencies on its own.

Docker Ignore

The Docker ignore feature is very much similar to git ignore. .gitignore doesn’t track the files or folders mentioned in it. Similarly, we don’t want to copy unnecessary files in the container, which takes up space.

In our case, we don’t want to copy the node_modules folder to the container. To do so, create a .dockerignore file in the project directory with the following contents:

node_modules/

Docker Compose

Docker Compose is a really helpful way to build and run docker containers with a single command. It is also helpful for running multiple containers at the same time. It is one of the reasons we use docker compose instead of plain docker. To know more about docker compose and how to run multiple containers, please visit the article Run Multiple Containers With Docker Compose.

Now, let’s create a docker-compose.yml file to add some more configurations. Add the below contents to docker-compose.yml file once created:

version: '3.4'
services:
  node-app:
    # 1. build the current directory
    build: .
    # 2. Run the project using nodemon, for monitoring file changes
    # Run the debugger on 9229 port
    command: nodemon --inspect=0.0.0.0:9229 /node/server.js 3000
    volumes:
      # 3. Bind the current directory on local machine with /node inside the container.
      - .:/node
    ports:
      # 4. map the 3000 and 9229 ports of container and host
      - "3000:3000"
      - "9229:9229"

The docker-compose.yml file is explained point-wise below.

Point to our current directory for building the project. Run the project using nodemon, since if there are any changes in the local directory, we want to restart the project in the docker with the changes. Nodemon is a utility that will monitor for any changes in your source and automatically restart your server. Bind our current directory to the /node directory using volumes.

In addition to exposing and binding the 3000 port for the server, expose the 9229 for attaching the debugger.

Use the above docker-compose.yml file only for debugging.

The above docker-compose.yml exposes the debug port. In addition, it also monitors for any file changes inside the container (which are not going to happen). Lastly, it maps the volumes of the container to the project directory.

For production, create a new file docker-compose-prod.yml with the following contents:

version: '3.4'
services:
  node-app:
    build: .
    command: node /node/server.js 3000
    ports:
      - "3000:3000"

It simply runs the project and exposes the 3000 port. We are using multiple docker compose files to manage separate environments. Check the Running a Project section below to understand how to run a project based on different docker compose files.

Before we can run the project, we still need to configure the debugger to connect to the container.

Configure a Remote Debugger

First, check if you have launch.json file created in your project. launch.json defines different types of configurations we can run for debugging. If it is not created, visit the RUN AND DEBUG tab on the left in your VS Code, as seen in the image below:

Click on the text that says create a launch.json file. Before you can proceed, it will ask the type of application to proceed. Select Node.js. It will create a new launch.json file in your project with a default Node.js configuration added.

Since we are not going to run the node application locally, go ahead and delete that configuration. Instead, replace the launch.json file with the following content:

{
    "version": "0.2.0",
    "configurations": [
        {
            // 1. Type of application to attach to
            "type": "node",

            // 2. Type of request. In this case 'attach'
            "request": "attach",
            // 3. Restart the debugger whenever it gets disconnected
            "restart": true,
            // 4. Port to connect to 
            "port": 9229,
            // 5. Name of the configuration
            "name": "Docker: Attach to Node",
            // 6. Connect to /node directory of docker
            "remoteRoot": "/node"
        }
    ]
}

The configuration added is pretty self-explanatory. Basically, we are asking the debugger to connect to a remote host with port number 9229. We are also requesting the debugger to restart whenever it gets disconnected to the host. By default, the debugger tries to connect on http://localhost:9229/. But project is hosted inside the /node directory in docker. To map /node, the remoteRoot attribute is used.

Running the Project

That’s about it! Now, if you run docker compose up, your project will start running. For the first run, it will download some layers of the node slim SDK and then install nodemon inside the docker container. But, subsequent runs would be much faster. Running docker compose up will show the following output in your terminal:

docker compose up

In order to attach the debugger, run the Docker: Attach to Node task from the RUN AND DEBUG tab. The debugger will now attach to the /node directory of your docker container. Next, put a breakpoint on line 4 of your server.js file, i.e., response.json({ “super”: “app1” });. Finally, open your browser and hit http://localhost:3000. The breakpoint will be hit, and the execution will halt.

For production, we need to use the docker-compose-prod.yml file. To do so, we need to mention the file name in the docker command. Execute the following command to run the project as if in a production environment:

docker compose -f docker-compose-prod.yml up

With the above command, a debugger cannot be attached to the container since we are not exposing any debugging point.

Source Code

Here is the link to the final source code of the project we have created.

Conclusion

Debugging is one of the best things for development. It’s the cherry on top when we are able to debug remotely. Remote debugging enables us to connect to code running not only on the cloud but also to a docker container running locally.

I hope you have enjoyed this article. Feel free to check out some of my other articles:

• Docker: An introduction and cheat sheet
• Running multiple containers with Docker Compose
• Setup CI/CD for Android with Azure Pipelines

What is Lazy Loading?

Lazy loading is a process of loading components, modules or other assets of a website as required. Since, Angular creates a SPA (Single Page Application), all of its components are loaded, at once. Secondly, a lot of unnecessary libraries or modules might be loaded as well.

For a small application it would be okay, but as the application grows the load time will increase, if everything is loaded at once. Lazy loading allows Angular to load components and modules as and when needed.

First of all, to understand how lazy loading works in Angular, we need to understand the basic building blocks of the framework: NgModules.

In order to understand how Lazy Loading works we first need to understand the building block of Angular: NgModules.

What are NgModules?

Angular libraries like RouterModule, BrowserModule, FormsModule are NgModules. Angular Material, which is a 3rd party, is also a type of NgModule. NgModule consists of files & code related to a specific domain or having a similar set of functionalities.

A typical NgModule file declares components, directives, pipes, and services. It can also import other modules that are needed in the current module.

One of the important advantage of NgModules is they can be lazy loaded. Let's have a look at how we can configure lazy loading.

How to Create NgModules

In this tutorial, we will create two modules Module A and Module B which will be lazy loaded. On the main screen we will have two buttons for loading each module lazily.

Create a Project

Create a new Angular project lazy-load-demo by executing the below command.

ng new lazy-load-demo --routing --strict --style css
code lazy-load-demo

Here, we are creating a new project with routing. Secondly, the strict mode is enabled. Lastly, we are mentioning the stylesheet format to css. The second command opens your project in VS Code.

Root Module

By default, a root module or app module is created under /src/app. Below is the NgModule file created:

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './app.component';

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    AppRoutingModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

First, we are importing all the required modules and components.

After that, @NgModule decorator states that AppModule class is a type of NgModule. The decorator accepts declarations, imports, providers, and bootstrap. Here are the descriptions for each of them:

• declarations: The components in this module.
• imports: The modules that are required by the current module.
• providers: The service providers if any.
• bootstrap: The root component that Angular creates and inserts into the index.html host web page.

Main screen

The main screen will have 2 buttons, namely, Load Module A & Load Module B. As the name suggests, clicking these buttons will lazily load each module.

For that, replace your app.component.html file with the contents below:

<button style="padding: 20px; color: white; background-color: green;" routerLink="a">Load Module A</button>
<button style="padding: 20px; color: white; background-color: blue;" routerLink="b">Load Module B</button>
<router-outlet></router-outlet>

Let's define the modules for routes a & b.

Lazy Loaded Modules

In order to create lazy loaded modules execute the below commands.

ng generate module modulea --route a --module app.module
ng generate module moduleb --route b --module app.module

The commands will generate two folders modulea & moduleb. Subsequently, each folder will contain their own module.ts, routing.ts and component files.

If you check your app-routing.module.ts you will see the below code for routes.

const routes: Routes = [
  { path: 'a', loadChildren: () => import('./modulea/modulea.module').then(m => m.ModuleaModule) },
  { path: 'b', loadChildren: () => import('./moduleb/moduleb.module').then(m => m.ModulebModule) }
];

It implies that when route a or b is visited load their respective modules lazily.

On running the project with ng serve, you will see the below screen:

On clicking Load Module A button, you will be routed to page a. This is how your screen should look like.

You should see a similar screen that says moduleb works! when clicked on Load Module B.

How to Verify that the Lazy Loading Worked

In order to verify the files loaded, open the developer tools by pressing F12. After that, visit the Network tab as you can see in the screenshot below. When you refresh the page it will show few files requested.

Go ahead and clear your list of requests by hitting the clear button as shown in the image on the right

When you click on the Load Module A, you will see a request for modulea-modulea-module.js as in the screenshot below. This verifies that the Module A was lazily loaded.

Similarly, when you click Load Module B, the moduleb-moduleb-module.js file is loaded. Hence, verifying that Module B was loaded lazily.

Use Cases

As we have seen, it’s very easy to create lazy loading modules. There are lots of use cases where they are useful, such as

• Creating a separate module for pre-login vs post-login screens.
• For an e-commerce website, vendor facing vs customer facing screens can belong to separate modules. You can also create a separate module for payment.
• A separate CommonModule which contains shared components, directives, or pipelines is usually created. Directives like Copy Code button, components like up vote/down vote are usually included in a common module.

Conclusion

For smaller websites, it might not matter much that all the modules are loaded at once. But, as the site grows it's very effective to have separate modules which are loaded as needed.

Because of lazy loading, load time for the websites can be reduced drastically. This is specially helpful when you are trying to rank higher in SEO's. Even if not, less loading times means better user experience.

Are you interested in more articles? Check these out:

• Learn TDD with Integration Tests in .NET
• How to authenticate & authorise API’s correctly in .NET
• Azure Functions & wkhtmltopdf: Convert HTML to PDF

Like any other field, the efficiency of a developer varies based on several factors: work culture, management, personal life, skills, and so on. Some we can control, and some we cannot.

In this article, we will discuss how to make oneself better by working on things we control. There are some clichéd tips like Stay Focused, Avoid Distractions and Be in the FLOW.

But we are going to get a bit more technical on increasing the efficiency.

Journey of a Software Developer

The usual stages of a developer are shown below:

Coder -> Programmer -> Architect

Coder

Many people use the words “coder” and “programmer” interchangeably. But, there is a difference between the two. A coder is someone who knows how to write the code or a script. Optimisation and architecture are not their priority. Rather, they focus on writing code that just works.

Programmer

A programmer is a superset of a coder. They know how to write code, but in addition, they also write it with great optimisation and robustness. Secondly, time and memory complexities are kept in mind when writing code.

Architect

As you might have guessed, the architect or the software architect, to be precise, is a superset of a programmer. The architect is responsible for not only a piece of code but also how these pieces fit together.

Coder vs. Programmer vs. Architect: An Example

A great example would be to ask these three people to “Create tic-tac-toe.”

When asking the coders, they will start coding, assuming it's a 3x3 tic-tac-toe with two players. Secondly, they might write nested for loops as a brute force approach to figure out who won the match. There might also be no design patterns in place like MVC, MVVM, or others.

However, the programmer will first understand the requirements completely and then start on the coding part. They will create optimised algorithms for maintaining the state of the players and a scalable way to change the grid dimensions.

The architect will select which technology is best for designing the game. A few other questions come into play: Is it going to be a web-based or mobile app? Will an API be required or just played locally? In addition, they will also decide on which design patterns to implement. Once the architecture is defined, only then will the actual implementation start.

The goal of each developer should be to become a great architect along with having great technical skills.

Here are a few ways to improve your efficiency and skills:

1. Pen and Paper

Many people find it offensive to give a pen and paper coding interview. In my opinion, it is one of the best tools to get clarity. Jot down the things that you want to achieve and how you will achieve them.

In the tic-tac-toe example above, you can write down that there will be models like Player and Board. Secondly, a game engine will be required to calculate the result after each move. Also, write down what each class will contain, e.g., Player will have a name and symbol property.

You get the idea. Figure out your design patterns. What you are trying to achieve in code, achieve it with pen and paper first.

2. Become Your Own Manager

At the start of the day, create a TODO list of your tasks, e.g., you will complete the game engine today, or you will complete the board UI today, etc.

Try to break it down into smaller tasks of 3–4 hours each. Having clear goals for the day keeps you motivated. Secondly, it gives a sense of satisfaction when the tasks are completed; it boosts morale.

Essentially, it’s a variant of the Kanban management style. But, I have found it to be quite effective.

3. Documentation

One of the reasons for taking time to get things right is a lack of knowledge.

Astonishingly, there are many developers who just assume how the system or library works. They spend an enormous amount of time figuring out by themselves how it works without reading the documentation. This leads to a loss in efficiency.

A simple example I personally encountered was writing blogs using the Markdown syntax. I know most of the basic syntax, but I was unaware of some of the advanced ones. I wasted around 5–10 minutes trying to figure it out. If I had gone to the documentation, instead, it would have saved me time.

Here is a Markdown cheat sheet in case you are wondering.

4. Don’t Reinvent the Wheel

If something is already available in the market, with great reliability, use it. Usually speaking the pros will outweigh the cons.

As an example, you should never write your own cryptographic function or library. There are pretty decent libraries available in almost all languages, and they will save you lots of time. More importantly, it will have the correct implementation, and it will be well optimised

But don’t overdo it. You shouldn’t import underscore or lodash just to loop through an array. It only increases your package size and hurts the user experience.

5. Testing

Test-Driven Development (TDD) is another methodology that is going strong. Writing tests is as important as writing code. Though manual testing is required, automated tests provide confidence that your system will not break logically.

Initially, it might feel that you are spending more time writing tests. But as the project grows, it would be worth it. Fewer bugs and more robustness.

Here is an article on how to do TDD in .NET Core.

Conclusion

I, personally, felt a lot of different emotions when following the above tips, but they have improved my efficiency a lot, especially creating a to-do list for the day.

Read more interesting articles:

• XCode or Android Studio: Which is Better?
• Setup CI-CD for iOS
• Setup CI-CD for Android
• Learning Integration Tests in .NET with .TDD

What makes me eligible to review!

I have been in the industry for more than 11+ years now. I started my career with BlackBerry (BB) Development. I feel old already!

Eclipse was our best friend back then for mobile development. I did my internship working on the famous Zagat app for BlackBerry. It was overall a great learning experience.

For my full-time job I switched to a start up named Spinlet which I hope is still going strong. I worked as BlackBerry developer in the beginning but switched to iOS development eventually.

My iOS experience was nothing but exciting in those initial years. Eventually I started my own firm Royale Cheese with a friend that provides mobile design & development.

After around 4 years of iOS development I found my way into Android development. I have got a fair share of experience with Android development as well, around 3 years to be precise.

We have since then been working on full stack. That's when I realised how horrible the mobile development tools are.

Enough with the chit chat. Here's an honest review of the mobile development tools and technologies.

XCode

It used to be a good tool in the past. But it has become terrible lately. Here is a list of all the issues even after 15 years:

• Auto-completion: Firstly, who in the right mind would set Esc as the suggestions key. Secondly, the autocompletion doesn't work many a times or gives weird suggestions that are out of context.
• Build Times: It takes a lot of time to create an archive or to run on a device for the first time. It's best to setup a CI/CD to archive and upload builds.
• Signing & Deployment: With the latest version's it's getting easier. But, it's still confusing with the signing certificates and the provision profiles for someone who is a beginner.
• Memory Hog: Somehow XCode keeps on hogging memory. For every new device on which the build needs to run it occupies 3 GB. Archives take a huge chunk and so as the simulators. Overall it occupies around 50GB if I don't clean up regularly.
• Updates: Each update is around 10-12GB even the minor upgrades. What's worse is it requires more than 40GB of free space to get installed. Last but not the least, XCode takes around 12GB of the space.
• Design: Initially to design UI there was struts & springs, then came the Autolayout and now the SwiftUI. It is worrisome that the methodology keeps on changing.
• Cocoapods: is getting worse day by day because it's repo is getting so big. Secondly, it increases the build times by a lot.
• Camera: Possibly due to hardware limitations camera was not supported in simulators. But, now it's been a while. If the location can be simulated why not the Camera?

Android Studio

I haven't got the chance to use it in the early days. But from what I have been seeing it wouldn't have been pretty. Here are some of the frustrating issues:

• Fragmentation: I feel this might be on top of every ones list. Supporting the staggering amount of devices to support might just overwhelm anyone.
• Gradle: Oh My God! Gradle takes forever to run builds. There are optimisation's which can help alleviate the problem, but it still remains the problem.
• RAM Hogger: With emulators and IDE running together, the combo requires around 10-12GB of RAM. That's way more than what their official documentation says: 4GB.
• Signing Keys: You lose your signing keys and you can't upload to the same app again. You will have to create a new app and get the reviews and downloads again. There is some improvement in this area recently.
• IDE: I always felt Java based IDE's to be clumsy. That includes IntelliJ (on which Android Studio is based), Eclipse or NetBeans. It's responsiveness is not like other tools like XCode or VS Code.

XCode vs Android Studio Review

Even though it might feel Android has less issues it does have some serious issues. Fragmentation and Gradle might alone be enough to make Android look bad.

Personally I prefer to work in XCode compared to Android since I own a Mac and probably I am more used to it.

Conclusion

Overall both platforms have a huge user base. But, I feel that these tools still have a long way to go.

As an example I am absolutely in love how Microsoft has revamped dotnet to dotnet core and their IDE to VS Code.

Jot down your frustrations in the comments below.

Read some of my articles here:

• Setup CI-CD for iOS
• Setup CI-CD for Android
• Learning Integration Tests in .NET with .TDD
• Provide a password-less to login

TDD (Test Driven Development) is a much debated word in the tech industry. Debates like Whether you should do TDD or not? or How advantageous is it? are quite popular. Simply said, TDD is test before you develop.

Now, there are a lot of school of thoughts regarding what type of test's are included and what are not in TDD. As an example, should it include Unit Test, Integration Test, System Test or even UAT?

In this article, we will go through a real-world example on how to write integration tests in .NET 5.0 with TDD methodology.

Project Requirements

TDD requires a very clear understanding of scope of work. Without clarity, all the test cases might not be covered.

Let's define the scope of work. We will be developing a patient admission system for a Hospital.

Business Requirements

• A hospital has X ICU rooms, Y Premium rooms & Z General rooms.
• ICU & Premium rooms can have a single patient at a time, while General rooms can have 2 patients. Each room has a room number.
• On admitting, the patient has to provide name, age, gender & phone number.
• It is possible to search a patient via name or phone number.
• Same patient cannot be admitted to multiple beds while he is still checked in.
• A patient cannot be admitted if all the rooms are occupied.

Model Validation Rules

Based on the above requirements, there are 2 models namely Patient & Room.

• A patient's age is between 0 & 150. The length of name should be between 2 and 40. Gender can be male, female & other. Phone Number's length should be between 7 and 12 and it should all be digits.
• Room type can be either "ICU", "Premium" or "General".

Test Cases

Now, that we have defined rules & requirements, lets start creating test cases. Since it's a basic CRUD application we mostly have integration tests.

Patient

• Do all the model validation tests.
• Admit the same patient twice
• Check out the same patient twice.
• Admit the same patient to multiple rooms at the same time.
• Search a patient with phone number and name.

TDD Setup

In the above section we gathered requirements. Secondly, we defined the models. Finally, we created the list of test cases which we will implement.

Open your terminal and run the below script to create and setup a new project.

mkdir TDD
cd TDD
dotnet new sln
dotnet new webapi --name TDD
dotnet new xunit --name TDD.Tests
cd TDD
dotnet add package Microsoft.EntityFrameworkCore --version 5.0.5
cd ../TDD.Tests
dotnet add reference ../TDD/TDD.csproj
dotnet add package Microsoft.EntityFrameworkCore --version 5.0.5
dotnet add package Microsoft.AspNetCore.Hosting --version 2.2.7
dotnet add package Microsoft.AspNetCore.Mvc.Testing --version 5.0.5
dotnet add package Microsoft.EntityFrameworkCore.InMemory --version 5.0.5
cd ..
dotnet sln add TDD/TDD.csproj
dotnet sln add TDD.Tests/TDD.Tests.csproj
code .

The above script creates a solution file named TDD.sln. Secondly, we create 2 projects for TDD & TDD.Tests. Then we add the dependencies for each project. Lastly, we add the projects to the solution and open the project in VS Code.

Before we start testing, some more setup is required. Basically, integration tests test the a specific module without mocking. So we will be mimicking our application via TestServer.

Custom WAF

In order to mimic the TestServer there is a class called WebApplicationFactory (WAF) which bootstraps the application in memory.

In your TDD.Tests project create a file named PatientTestsDbWAF.cs with the following code.

using System.Linq;
using Microsoft.EntityFrameworkCore;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Mvc.Testing;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.AspNetCore;


namespace TDD.Tests
{
    public class PatientTestsDbWAF<TStartup> : WebApplicationFactory<TStartup> where TStartup : class
    {

        protected override IWebHostBuilder CreateWebHostBuilder()
        {
            return WebHost.CreateDefaultBuilder()
                .UseStartup<TStartup>();
        }
        protected override void ConfigureWebHost(IWebHostBuilder builder)
        {
            builder.ConfigureServices(async services =>
           {
               // Remove the app's DbContext registration.
               var descriptor = services.SingleOrDefault(
                      d => d.ServiceType ==
                          typeof(DbContextOptions<DataContext>));

               if (descriptor != null)
               {
                   services.Remove(descriptor);
               }

               // Add DbContext using an in-memory database for testing.
               services.AddDbContext<DataContext>(options =>
                  {
                      // Use in memory db to not interfere with the original db.
                      options.UseInMemoryDatabase("PatientTestsTDD.db");
                  });
           });
        }
    }
}

We are removing the applications DbContext and adding an in memory DbContext. It is a necessary step since we don't want to interfere with the original database.

Secondly, we are initialising the database with some dummy data.

Since, DataContext is a custom class, it will give compiler error. So, we need to create it.

Data Context

Therefore, in your TDD project, create a file named DataContext.cs with the following code.

using Microsoft.EntityFrameworkCore;

namespace TDD
{
    public class DataContext : DbContext
    {
        public DataContext(DbContextOptions options) : base(options) { }

        // For storing the list of patients and their state
        public DbSet<Patient> Patient { get; set; }

        // For the storying the rooms along with their types and capacity
        public DbSet<Room> Room { get; set; }

        // For logging which patients are currently admitted to which room
        public DbSet<RoomPatient> RoomPatient { get; set; }

    }
}

Here Patient, Room & RoomPatient are Entity classes with the required properties, which we will create next.

Patient

Again, in your TDD project, create a file named Patient.cs and paste in the code below.

using System;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace TDD
{
    public class Patient
    {
        [Key]
        [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
        public int Id { get; set; }

        public String Name { get; set; }

        public String PhoneNumber { get; set; }

        public int Age { get; set; }

        public String Gender { get; set; }
    }
}

Room

Create another file named Room.cs with the following code.

using System;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace TDD
{
    public class Room
    {
          [Key]
        [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
        public int Id { get; set; }

        public String RoomType { get; set; }

        public int CurrentCapacity { get; set; }

        public int MaxCapacity { get; set; }
    }
}

RoomPatient

Create the last model file RoomPatient.cs with the following code.

using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace TDD
{
    public class RoomPatient
    {
        [Key]
        [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
        public int Id { get; set; }

        [Required]
        public int RoomId { get; set; }

        [ForeignKey("RoomId")]
        public Room Room { get; set; }

        [Required]
        public int PatientId { get; set; }

        [ForeignKey("PatientId")]
        public Patient Patient { get; set; }
    }
}

Now you shouldn't be getting any compiler error.

Lastly, remove the WeatherForecast.cs and WeatherForecastController.cs files.

Go to your terminal in VS Code and run the below command.

cd TDD.Tests
dotnet test

You will see a nice green result which says 1 test passed.

Patient Controller

Unfortunately dotnet doesn't provide a way to directly test the model's in itself. So, we will have to create a controller to test it.

Go ahead and create PatientController.cs in the Controllers folder in TDD project with the below code.

using Microsoft.AspNetCore.Mvc;

namespace TDD.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class PatientController : Controller
    {
        [HttpPost]
        public IActionResult AddPatient([FromBody] Patient Patient)
        {
            // TODO: Insert the patient into db
            return Created("/patient/1", Patient);
        }
    }
}

We created an api to add a patient. In order to test our model we will call this api.

That is all the things required to start testing.

Model Validation Tests

Since, we have setup the basic code for testing, let's write a test that fails. We will start our testing with the model validation tests.

Failing (Red) State

Let's create a new file named PatientTests.cs in your TDD.Tests project and delete the file named UnitTest1.cs. Copy the below code in your file.

using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Xunit;
using System.Text;
using System.Text.Json;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.AspNetCore.Mvc.Testing;
using System;
using System.Collections.Generic;
using Microsoft.EntityFrameworkCore;

namespace TDD.Tests
{
    public class PatientTests : IClassFixture<PatientTestsDbWAF<Startup>>
    {
        // HttpClient to call our api's
        private readonly HttpClient httpClient;
        public WebApplicationFactory<Startup> _factory;

        public PatientTests(PatientTestsDbWAF<Startup> factory)
        {
            _factory = factory;

            // Initiate the HttpClient
            httpClient = _factory.CreateClient();
        }

        [Theory]
        [InlineData("Test Name 2", "1234567891", 20, "Male", HttpStatusCode.Created)]
        [InlineData("T", "1234567891", 20, "Male", HttpStatusCode.BadRequest)]
        [InlineData("A very very very very very very loooooooooong name", "1234567891", 20, "Male", HttpStatusCode.BadRequest)]
        [InlineData(null, "1234567890", 20, "Invalid Gender", HttpStatusCode.BadRequest)]
        [InlineData("Test Name", "InvalidNumber", 20, "Male", HttpStatusCode.BadRequest)]
        [InlineData("Test Name", "1234567890", -10, "Male", HttpStatusCode.BadRequest)]
        [InlineData("Test Name", "1234567890", 20, "Invalid Gender", HttpStatusCode.BadRequest)]
        [InlineData("Test Name", "12345678901234444", 20, "Invalid Gender", HttpStatusCode.BadRequest)]
        public async Task PatientTestsAsync(String Name, String PhoneNumber, int Age, String Gender, HttpStatusCode ResponseCode)
        {
            var scopeFactory = _factory.Services;
            using (var scope = scopeFactory.CreateScope())
            {
                var context = scope.ServiceProvider.GetService<DataContext>();

                // Initialize the database, so that 
                // changes made by other tests are reset. 
                await DBUtilities.InitializeDbForTestsAsync(context);

                // Arrange
                var request = new HttpRequestMessage(HttpMethod.Post, "api/patient");

                request.Content = new StringContent(JsonSerializer.Serialize(new Patient
                {
                    Name = Name,
                    PhoneNumber = PhoneNumber,
                    Age = Age,
                    Gender = Gender
                }), Encoding.UTF8, "application/json");

                // Act
                var response = await httpClient.SendAsync(request);

                // Assert
                var StatusCode = response.StatusCode;
                Assert.Equal(ResponseCode, StatusCode);
            }
        }
    }
}

[Theory] attribute allows us to mention different parameters for our tests. Consequently, we don't have to write different tests for all the combinations.

Also, DBUtilities is a utility class to reinitialise the database to it's initial state. This might seem trivial when we have 1 or 2 tests but, gets critical as we add more tests.

DBUtilities

The DBUtilities class will initialise your database with 1 patient and 3 different type of rooms.

Create a file named DBUtilities.cs in your TDD.Tests project with the below code.

using System.Threading.Tasks;

namespace TDD.Tests
{
    // Helps to initialise the database either from the WAF for the first time
    // Or before running each test.
    public class DBUtilities
    {

        // Clears the database and then,
        //Adds 1 Patient and 3 different types of rooms to the database
        public static async Task InitializeDbForTestsAsync(DataContext context)
        {
            context.RoomPatient.RemoveRange(context.RoomPatient);
            context.Patient.RemoveRange(context.Patient);
            context.Room.RemoveRange(context.Room);

            // Arrange
            var Patient = new Patient
            {
                Name = "Test Patient",
                PhoneNumber = "1234567890",
                Age = 20,
                Gender = "Male"
            };
            context.Patient.Add(Patient);

            var ICURoom = new Room
            {
                RoomType = "ICU",
                MaxCapacity = 1,
                CurrentCapacity = 1
            };
            context.Room.Add(ICURoom);

            var GeneralRoom = new Room
            {
                RoomType = "General",
                MaxCapacity = 2,
                CurrentCapacity = 2
            };
            context.Room.Add(GeneralRoom);

            var PremiumRoom = new Room
            {
                RoomType = "Premium",
                MaxCapacity = 1,
                CurrentCapacity = 1
            };
            context.Room.Add(PremiumRoom);

            await context.SaveChangesAsync();
        }
    }
}

Go ahead and run the dotnet test command again and you will see 1 passed and 4 failed tests. This is because the 4 tests were expecting BadRequest but getting a Created result.

Let's fix it!

Success (Green) State

In order to fix these we need to add attributes to our Patient.cs class.

Update the Patient.cs file as below.

using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace TDD
{
    public class Patient : IValidatableObject
    {
        [Key]
        [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
        public int Id { get; set; }

        [Required]
        [StringLength(40, MinimumLength = 2, ErrorMessage = "The name should be between 2 & 40 characters.")]
        public String Name { get; set; }

        [Required]
        [DataType(DataType.PhoneNumber)]
        [RegularExpression(@"^(\d{7,12})$", ErrorMessage = "Not a valid phone number")]
        public String PhoneNumber { get; set; }

        [Required]
        [Range(1, 150)]
        public int Age { get; set; }

        [Required]
        public String Gender { get; set; }

        public Boolean IsAdmitted { get; set; }

        public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
        {
            // Only Male, Female or Other gender are allowed
            if (Gender.Equals("Male", System.StringComparison.CurrentCultureIgnoreCase) == false &&
                Gender.Equals("Female", System.StringComparison.CurrentCultureIgnoreCase) == false &&
                Gender.Equals("Other", System.StringComparison.CurrentCultureIgnoreCase) == false)
            {
                yield return new ValidationResult("The gender can either be Male, Female or Other");
            }

            yield return ValidationResult.Success;
        }
    }
}

Here, we have added the required attributes. We have also implemented the IValidatableObject interface so that we can verify the Gender.

Time to run the dotnet test command. You will see a nice green line saying 5 tests passed.

You can add more edge case scenarios in the InlineData to test the Patient model validation tests thoroughly.

Duplicate Patient Test

We shall now create a test which fails when we try to add a duplicate patient.

Failing (Red) Test

Create another test in your class PatientTests. Add the below code.

[Fact]
public async Task PatientDuplicationTestsAsync()
{
    var scopeFactory = _factory.Services;
    using (var scope = scopeFactory.CreateScope())
    {
        var context = scope.ServiceProvider.GetService<DataContext>();
        await DBUtilities.InitializeDbForTestsAsync(context);

        // Arrange
        var Patient = await context.Patient.FirstOrDefaultAsync();

        var Request = new HttpRequestMessage(HttpMethod.Post, "api/patient");
        Request.Content = new StringContent(JsonSerializer.Serialize(Patient), Encoding.UTF8, "application/json");

        // Act
        var Response = await httpClient.SendAsync(Request);

        // Assert
        var StatusCode = Response.StatusCode;
        Assert.Equal(HttpStatusCode.BadRequest, StatusCode);
    }
}

We have used a [Fact] attribute instead of [Theory] attribute here since we don't want to test the same method with different parameters. Instead, we want to make the same request twice.

Run dotnet test to run our newly created test. The test will fail with message Assert.Equal() Failure. Time to fix it.

Success (Green) Test

To fix the failing test we need to add the implementation for the AddPatient method in PatientController.cs. Update the file's code as below.

using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;

namespace TDD.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class PatientController : Controller
    {
        private readonly DataContext _context;

        public PatientController(DataContext context)
        {
            _context = context;
        }
        [HttpPost]
        public async Task<IActionResult> AddPatientAsync([FromBody] Patient Patient)
        {
            var FetchedPatient = await _context.Patient.FirstOrDefaultAsync(x => x.PhoneNumber == Patient.PhoneNumber);
            // If the patient doesn't exist create a new one
            if (FetchedPatient == null)
            {
                _context.Patient.Add(Patient);
                await _context.SaveChangesAsync();
                return Created($"/patient/{Patient.Id}", Patient);
            }
            // Else throw a bad request
            else
            {
                return BadRequest();
            }
        }
    }
}

Run the dotnet test again and you will see that the test has passed.

You can run all the tests by calling dotnet test.

Important Notes

As you add more models/domains like Doctors, Staff, Instruments etc. You will have to create more tests. Make sure to have a different WAF, utility wrappers and different Test files for each of them.

Secondly, the tests in the same file do not run in parallel. But, the tests from different files do run in parallel. Therefore, each WAF should have a different database name so that data is not misconfigured.

Lastly, the connections to the original database still needs to be setup in the main project.

Thought Process

The thought process for creating tests for all scenarios are similar.

That is, you should first identify the requirements. Then, set up a skeleton of methods and classes without implementation. Write tests to verify the implementation. Finally, refactor as needed and rerun the tests.

This tutorial didn't include authentication and authorisation for api's. You can read here on how to set it up.

Since, it is not possible to cover all the test cases, I have created a repository on Github. It covers the implementation for all the test cases and the implementation as well.

You can find the project here.

Conclusion

In order for TDD to be effective you really need to have a clear idea of what the requirements are. If the requirements keep on changing it would get very tough to maintain the tests as well as the project.

TDD mainly covers unit, integration & functional tests. You will still have to do UAT, Configuration & Production testing before you go live.

Having said that, TDD is really helpful in making your project bug free. Secondly, it boosts your confidence for the implementation. You will be able to change bits & pieces of your code as long as the tests pass. Lastly, it provides a better architecture for your project.

Hope you like the article. Let me know your thoughts or feedback.

Check more tutorials on .NET here.

To better understand security for API's let's create a demo project for FBI. There will be an Admin who can enrol FBI Agents and change their clearance levels. Secondly FBI Agents with Clearance Level 1 will be able to access public files and agents with Clearance Level 2 will be able to access pubic & classified files.

First some theory! Not Interested? Take me to the code.

Authentication

Our Agent has successfully cleared all his exams; time to enrol him. In order to do that he will provide his documents and in return will get his badge.

In the above scenario providing documents is like login where once verified he will be provided with a token (badge). This process is called Authentication. It determines whether agents are who they claim to be.

We are going to use Json Web Tokens (JWT) Bearer tokens for authentication. Bearer tokens are a type of tokens generated by servers which contain details of the claims/roles of a user trying to login. Bearer tokens are mostly structured tokens like JWT. Read here to know more about JWT.

Authorisation

Now since the FBI Agent has got his badge he can enter the FBI building. He is also able to access public files, but when trying to access classified files he gets 401 error.

This is because FBI Agent is not authorised to access classified files. Authorisation determines what agents can and cannot access.

As mentioned above the JWT Bearer token contains claims/roles. Based on it, our server decides whether to give access to a private resource or not.

Access Flow

As you can see in the above diagram on successful login the server returns a Bearer token. The client uses the bearer token in subsequent calls to access a private resource.

These are the two main concepts that we are going to implement in our article.

Enough with the theory, show me some code!

Project Setup

Create a new project by executing the command dotnet new webapi --name FBI from your cli. It will create a project with a sample WeatherForecast api.

Why work on WeatherForecast when we can work on FBI. Go ahead and delete WeatherForecast.cs file.

Add dependencies by executing the commands

dotnet add package Microsoft.IdentityModel.Tokens --version 6.9.0
dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer --version 5.0.4

In ConfigureServices function in your Startup.cs file add the below code.

var TokenValidationParameters = new TokenValidationParameters
{
    ValidIssuer = "https://fbi-demo.com",
    ValidAudience = "https://fbi-demo.com",
    IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("SXkSqsKyNUyvGbnHs7ke2NCq8zQzNLW7mPmHbnZZ")),
    ClockSkew = TimeSpan.Zero // remove delay of token when expire
};

We are defining the parameters for validating a token. Make sure that the length of the string for generating SymmetricSecurityKey is 32.

Next, setup the services to add authentication for API's.

services
    .AddAuthentication(options =>
    {
        options.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
    })
    .AddJwtBearer(cfg =>
    {
        cfg.TokenValidationParameters = TokenValidationParameters;
    });

The AddAuthentication method registers services required by authentication services. It also configures JWT Bearer Authentication as the default scheme.

The AddJwtBearer enables JWT-bearer authentication and setting the TokenValidationParameters defined above.

Now let's add some Authorisation claims for our Agent & Admin.

services.AddAuthorization(cfg =>
    {
        cfg.AddPolicy("Admin", policy => policy.RequireClaim("type", "Admin"));
        cfg.AddPolicy("Agent", policy => policy.RequireClaim("type", "Agent"));
        cfg.AddPolicy("ClearanceLevel1", policy => policy.RequireClaim("ClearanceLevel", "1", "2"));
        cfg.AddPolicy("ClearanceLevel2", policy => policy.RequireClaim("ClearanceLevel", "2"));
    });

The AddAuthorization method registers services required for authorisation. We are also adding claims for Admin, Agent, ClearanceLevel1 and ClearanceLevel2 by calling AddPolicy. A claim is a name value pair that represents what the subject is. Since clearance level 2 can also access clearance level 1 we have put "1", "2" in ClearanceLevel1. You can read more about claims here.

Lastly in the Configure method add the below line just above app.UseAuthorization();

app.UseAuthentication();

Admin Controller

Rename your file WeatherForecastController.cs to AdminController.cs. Do change the class name and constructor names as well. Finally, remove everything except the constructor.

using Microsoft.AspNetCore.Mvc;

namespace FBI.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class AdminController : ControllerBase
    {
        public AdminController() { }
    }
}

Login API

Let's create a login API for Admin so that she can get a token to perform other tasks.

[HttpPost]
[Route("[action]")]
public IActionResult Login([FromBody] User User)
{
    // TODO: Authenticate Admin with Database
    // If not authenticate return 401 Unauthorized
    // Else continue with below flow

    var Claims = new List<Claim>
            {
                new Claim("type", "Admin"),
            };

    var Key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("SXkSqsKyNUyvGbnHs7ke2NCq8zQzNLW7mPmHbnZZ"));

    var Token = new JwtSecurityToken(
        "https://fbi-demo.com",
        "https://fbi-demo.com",
        Claims,
        expires: DateTime.Now.AddDays(30.0),
        signingCredentials: new SigningCredentials(Key, SecurityAlgorithms.HmacSha256)
    );

    return new OkObjectResult(new JwtSecurityTokenHandler().WriteToken(Token));
}

In the above code User is a model with properties Username & Password. We are also creating an object of JwtSecurityToken using configurations that we have used in Startup.cs file. The token is then converted to string and returned in an OkObjectResult.

You can now open Swagger and execute the API to see a bearer token. A bearer token will be returned as you can see below.

Keep the token handy since we are going to use it in the next section. You can also visit https://jwt.io to analyse your token.

Generate Badge API

Generating badge for an Agent is a sensitive task and should only be Authorised by an Admin. We are going to add an Authorize attribute for the GenerateBadge api.

[HttpPost]
[Route("[action]")]
[Authorize(Policy = "Admin")]
public IActionResult GenerateBadge([FromBody] Agent Agent)
{
var Claims = new List<Claim>
    {
        new Claim("type", "Agent"),
        new Claim("ClearanceLevel", Agent.ClearanceLevel.ToString()),
    };

    var Key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("SXkSqsKyNUyvGbnHs7ke2NCq8zQzNLW7mPmHbnZZ"));

    var Token = new JwtSecurityToken(
        "https://fbi-demo.com",
        "https://fbi-demo.com",
        Claims,
        expires: DateTime.Now.AddDays(30.0),
        signingCredentials: new SigningCredentials(Key, SecurityAlgorithms.HmacSha256)
    );

    return new OkObjectResult(new JwtSecurityTokenHandler().WriteToken(Token));
}

Here Agent is a model with properties Name as string and ClearanceLevel as int.

Now when you go back to swagger and try to execute GenerateBadge api it will give you 401 Unauthorised response. Since we have not passed the bearer token we are getting this error.

To be able to add the Authorize header in Swagger change the services.AddSwaggerGen as below:

services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new OpenApiInfo { Title = "FBI", Version = "v1" });
    c.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme
    {
        In = ParameterLocation.Header,
        Description = "Please enter JWT with Bearer into field",
        Name = "Authorization",
        Type = SecuritySchemeType.ApiKey
    });
    c.AddSecurityRequirement(new OpenApiSecurityRequirement {
    { new OpenApiSecurityScheme
            {
                Reference = new OpenApiReference { Type = ReferenceType.SecurityScheme, Id = "Bearer"}
            },
        new string[] {}
    }
    });
});

When you refresh Swagger in your browser you will notice an Authorize button on the right side above the list of apis.

Click on the newly added Authorize button in Swagger which will open up a dialog. We need to mention what type of token it is. So first enter Bearer in the field then a space and then the token generated from the /Admin/Login api from previous section.

Click on the header to lock in the token. Now you are all set. When you execute the GenerateBadge api again you will get a token (analogous to badge). Keep this token handy, since we require in next section. Also make sure to pass ClearanceLevel as 1 for now.

Agent Controller

Create a new file AgentController.cs with below content.

using Microsoft.AspNetCore.Mvc;

namespace FBI.Controllers
{
    [ApiController]
    [Route("[controller]")]
    [Authorize(Policy = "Agent")]
    public class AgentController : ControllerBase
    {
        public AgentController() { }
    }
}

As you can see above we are authorising the whole controller for Agent's access only. So even Admin won't be able to access the API's we are going to create.

Access Records API's

Let's add the api's to access both public and classified files.

[HttpGet]
[Route("[action]")]
[Authorize(Policy = "ClearanceLevel1")]
public ActionResult<String> AccessPublicFiles()
{
    return new OkObjectResult("Public Files Accessed");
}

[HttpGet]
[Route("[action]")]
[Authorize(Policy = "ClearanceLevel2")]
public ActionResult<String> AccessClassifiedFiles()
{
    return new OkObjectResult("Classified Files Accessed");
}

We have added Authorize attribute's for both API's such that public files can be accessed by ClearanceLevel1 and classified files can be accessed by ClearanceLevel2.

If you try to access these API's with the Admin token you will get 403 Forbidden error. So go ahead and click on the Authorize button again and click on logout. Then, get the token from the above step and paste in the field with Bearer as a prefix i.e. Bearer .

Now when you access /Agent/AccessPublicFiles api you will see response 200 with message Public Files Accessed. But when you try the classified api you get 403 Forbidden error.

Changing Clearance Level

Fast forward 3 years and our Agent's performance has been mind bogglingly good. Management has now decided to promote him to ClearanceLevel2.

The Agent goes to the Admin and asks her to provide a token/badge with Clearance Level 2.

The Admin calls the /Admin/Login api to generate his own token first. She then enters it in the Authorize dialog.

/Admin/GenerageBadge api is then called by Admin with value 2 in the ClearanceLevel. This generates a new token/badge which she then hands over to Agent.

The Agent enters this token/badge in the Authorize dialog and when he now calls /Agent/AccessClassifiedFiles he is pleased to see the result Classified Files Accessed.

Conclusion

You can find the whole project here on github.

API security is extremely important and shouldn't be taken lightly even if it's for internal use only. Setup Authentication and Authorisation and you are halfway there.

There are other other security measures you can security against DDoS attacks, accepting API's from a particular IP or domain only etc.

How did you like the article? What are the other security measures do you usually take? Any feedbacks or comments?

You can checkout out more tutorials on here.

A Content Delivery Network (CDN) helps you deliver your content more quickly. You can serve any type of content that remains unchanged over a period of time, like images, videos, CSS, JavaScript, HTML files, PDFs, and more.

A CDN is a group of servers that are spread across the world to deliver the content from the Edge servers. Edge servers are servers located closest to the place from where the request is being made.

Depending on the request, edge servers may either return the content from its cache or they can fetch it from the Origin Server. The servers that serve the actual content are called Origin servers.

In the above image, the Edge Servers are located around the world and the Origin Server is located in California, USA. When a request is made, the Edge Server located at Mumbai, India may contact the Origin Server if it's not able to serve the content.

How CDN works?

CDNs have four main parts: A Consumer, DNS, Edge Server & Origin Server.

When the Consumer makes a request, it is at first accepted by its Internet Service Provider (ISP). The ISP will then hit the content provider's Authoritative DNS.

An Authoritative DNS converts the DNS request to an IP request.

When the Authoritative DNS is made, it returns the IP address of the closest Edge Server. The Edge Server will then check in its own cache to see if the requested content is available.

If it is, then it returns the content. If the content is not available, it requests the content from the Origin Server and on retrieval caches it.

Benefits of CDN

Low Bandwidth Consumption

Many web hosts have a limited bandwidth allocation per month. If you go beyond that you will be charged extra.

With a CDN most of your bandwidth will be saved since the content will be served by the edge servers.

Low Latency

The Edge Servers cache the content. So anytime cached content is requested the latency is reduced drastically. This is because the request doesn't go all the way to the Origin Server.

Security against DDoS

Almost all the popular CDN's have the capability to protect your webserver against Distributed denial of service (DDos) attacks.

Improves SEO

Loading time is one of the factors that can affect your site's SEO rankings. If you are serving most of your content via CDN, the loading times are drastically reduced and can help improve your SEO.

Deep Dive into Azure CDN

Let's say you have created an Azure Storage Account and hosted a very simple site that displays Hello World as h1. Now that you know the benefits of CDNs, you want to serve your simple site over CDN.

You will have an endpoint something like https://demostorageaccountarjav.z29.web.core.windows.net/(where instead of demostorageaccountarjav it would be your storage account's name). Here are more details on how to setup a static website.

Login to your Azure Portal and click on Create a resource from you dashboard. Search for CDN which will open the resource in the marketplace as below.

This will open up a form to create a CDN profile. A CDN profile is a set of CDN endpoints. There is not much to fill in here except the name, resource group, and the pricing tier.

Next, select the checkbox to create a CDN endpoint. An endpoint is where the Consumer will be requesting content. So if you have multiple sites you can create multiple endpoints as well.

I have attached a screenshot for your reference on what values to put in. Since CDN is a global service the region selection will be disabled.

You can now click on Create to generate the profile and endpoint. It will take a couple of minutes to create. After it is created and when you go to the home screen, you will have these 4 resources:

As discussed earlier the CDN Profile is a group of Endpoints. To view the details click the Endpoint resource. You will see an overview with a link to the Endpoint hostname.

When you open the endpoint hostname it might show "404 not found" initially. You might have to wait another 10-15 minutes before your actual site is visible.

As discussed in the benefits section you can configure the Endpoint for security, caching, routing & a lot of other things. You can explore more concepts here.

How to Access via SAS Token

You may be wondering what if my resource is in a private container and can only be accessed via a Shared Access Signature (SAS) Token. Well you are in luck! The query strings are passed on as they are and since SAS is as a query string you are good.

Go ahead and create a new storage account (with static website disabled). Add a new Endpoint in the CDN profile that points to the newly created storage account.

For demo purposes I have created a container named site with private access level and uploaded a Blob named Photo.jpeg in a Storage Account with URL https://demostorageaccountarjav.blob.core.windows.net.

You can of course get a SAS token from the Azure portal directly for testing, but that's not how you would usually do in real-world. For that find below a simple snippet to create SAS token in Node.js.

const azureSasToken = require('azure-sas-token');

// default token validity is 7 days
let sasToken = azureSasToken.createSharedAccessToken('https://<service namespace>.servicebus.windows.net/<topic name or queue>',
                                '<signature key name>',
                                '<signature hash>');
console.log(`sasToken: ${sasToken}`);

// Specify your own validity in secs, two hours in this example
sasToken = azureSasToken.createSharedAccessToken('https://<service namespace>.servicebus.windows.net/<topic name or queue>',
                                '<signature key name>',
                                '<signature hash>', 
                                60 * 60 * 2);
console.log(`sasToken: ${sasToken}`);

We have used a simple npm package named azure-sas-token. Once the SAS is generated your URL will look something like:

https://demostorageaccountarjav.blob.core.windows.net/site/Photo.jpeg?sp=r&st=2021-03-25T07:28:45Z&se=2022-02-02T15:28:45Z&spr=https&sv=2020-02-10&sr=b&sig=PD4HlRI8bDEirMevpYQgpx6drwh%2BE5EpILfXkQOMlvw%3D

The above URL is pointing directly to the storage account. So go ahead and change the origin so that it uses the origin endpoint.

https://demowebsitearjav.azureedge.net/site/Photo.jpeg?sp=r&st=2021-03-25T07:28:45Z&se=2022-02-02T15:28:45Z&spr=https&sv=2020-02-10&sr=b&sig=PD4HlRI8bDEirMevpYQgpx6drwh%2BE5EpILfXkQOMlvw%3D

When you visit this site you will now be able to view the protected resource via CDN.

Conclusion

In my opinion everyone should be using a Content Delivery Network. There are lots of other providers like Cloudflare, S3 etc. but Microsoft is one of the major players which is emerging with a wide variety of services.

If you are an Azure fan like I am you should definitely give Azure CDN a try.

For any feedback or questions you can get in touch with me.

Check here for more tutorials like this.

Firstly, you can use Adobe‘s fill and sign tool to fill out forms, but this mostly requires a human interaction and hence it’s not scalable and not convenient.

Second option is you directly create a pdf file. Based on the platform you are working on you will have tools to directly create a pdf file. If it’s a very simple pdf you can take this approach.

This brings us to our final and most convenient option. wkhtmltopdf is a really great tool to convert your HTML to PDF. Since it is free, open source and can be compiled for almost all platforms it is our best choice.

Prerequisites

• Microsoft VS Code
• An account on Azure Portal
• Linux Basic (B1) App Service Plan. If you already have a Windows Basic (B1) App Service Plan you can use that.
• Azure Storage Account.

Azure Functions

Since converting a HTML to PDF is a time consuming task we shouldn’t run it on our main web server. Otherwise it may start blocking other important requests. Azure Functions are the best way to delegate such tasks.

In order to create a function you will first need to install Azure Functions on your machine. Based on your OS install the Azure Functions Core Tools. Once installed open your command line tool to fire the below command. html2pdf is your project's name. You can replace it with any name.

func init html2pdf

On executing the command it will ask for a worker runtime. Here select 1. dotnet since being a Microsoft’s product it provides great support for dotnet. This will generate a folder named html2pdf in your current directory. Since Visual Studio Code allows to directly publish to Azure Functions we will use it to code and deploy.

After you open your project in VS Code create a file named Html2Pdf.cs. Azure Functions provide a wide variety of triggers to execute the function. For now we will start with HTTP trigger i.e. the function can be called directly via http protocol. In our newly created file paste the below content.

using System;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;
namespace Html2Pdf
{
    public class Html2Pdf
    {
        // The name of the function
        [FunctionName("Html2Pdf")]

        // The first arugment tells that the functions can be triggerd by a POST HTTP request. 
        // The second argument is mainly used for logging information, warnings or errors
        public void Run([HttpTrigger(AuthorizationLevel.Function, "POST")] Html2PdfRequest Request, ILogger Log)
        {
        }
    }
}

We have created a skeleton in which we will now fill in the details. As you might have noticed the type of request variable is Html2PdfRequest. So let’s create a model Html2PdfRequest.cs class as below.

namespace Html2Pdf
{
    public class Html2PdfRequest
    {
        // The HTML content that needs to be converted.
        public string HtmlContent { get; set; }

        // The name of the PDF file to be generated
        public string PDFFileName { get; set; }
    }
}

DinkToPdf

In order to invoke wkhtmltopdf from our managed code a technology called P/Invoke is used. In short P/Invoke allows us to access structs, callbacks and functions in unmanaged libraries. There is a nice P/Invoke wrapper named DinkToPdf to allow us to abstract away the technicalities. You can add DinkToPdf to your project via nuget. Simply run the command from your root folder.

dotnet add package DinkToPdf --version 1.0.8

Time to add some code at the top of our class Html2Pdf.

// Read more about converter on: https://github.com/rdvojmoc/DinkToPdf
// For our purposes we are going to use SynchronizedConverter
IPdfConverter pdfConverter = new SynchronizedConverter(new PdfTools());
// A function to convert html content to pdf based on the configuration pased as arguments
// Arguments:
// HtmlContent: the html content to be converted
// Width: the width of the pdf to be created. e.g. "8.5in", "21.59cm" etc.
// Height: the height of the pdf to be created. e.g. "11in", "27.94cm" etc.
// Margins: the margis around the content
// DPI: The dpi is very important when you want to print the pdf.
// Returns a byte array of the pdf which can be stored as a file
private byte[] BuildPdf(string HtmlContent, string Width, string Height, MarginSettings Margins, int? DPI = 180)
{
  // Call the Convert method of SynchronizedConverter "pdfConverter"
  return pdfConverter.Convert(new HtmlToPdfDocument()
            {
                // Set the html content
                Objects =
                {
                    new ObjectSettings
                    {
                        HtmlContent = HtmlContent
                    }
                },
                // Set the configurations
                GlobalSettings = new GlobalSettings
                {
                    // PaperKind.A4 can also be used instead PechkinPaperSize
                    PaperSize = new PechkinPaperSize(Width, Height),
                    DPI = DPI,
                    Margins = Margins
                }
            });
}

I have added inline comments so as to be self explanatory. If you have any questions you can ask me in the comments section below. Let’s call the above created function from our Run method.

// PDFByteArray is a byte array of pdf generated from the HtmlContent 
var PDFByteArray = BuildPdf(Request.HtmlContent, "8.5in", "11in", new MarginSettings(0, 0, 0,0));

Once the byte array is generated let’s store that as a blob in Azure Storage. Before you upload the blob, do create a container. Once you do that add the below code after PDFByteArray.

// The connection string of the Storage Account to which our PDF file will be uploaded

// Make sure to replace with your connection string.
var StorageConnectionString = "DefaultEndpointsProtocol=https;AccountName=<YOUR ACCOUNT NAME>;AccountKey=<YOUR ACCOUNT KEY>;EndpointSuffix=core.windows.net";

// Generate an instance of CloudStorageAccount by parsing the connection string
var StorageAccount = CloudStorageAccount.Parse(StorageConnectionString);

// Create an instance of CloudBlobClient to connect to our storage account
CloudBlobClient BlobClient = StorageAccount.CreateCloudBlobClient();

// Get the instance of CloudBlobContainer which points to a container name "pdf"
// Replace your own container name
CloudBlobContainer BlobContainer = BlobClient.GetContainerReference("pdf");

// Get the instance of the CloudBlockBlob to which the PDFByteArray will be uploaded
CloudBlockBlob Blob = BlobContainer.GetBlockBlobReference(Request.PDFFileName);

// Upload the pdf blob
await Blob.UploadFromByteArrayAsync(PDFByteArray, 0, PDFByteArray.Length);

You will see some errors and warning after you add this code. For that firstly, add the missing import statements. Secondly, change the return type from void to async Task for the Run function. Here is what the final Html2Pdf.cs file will look like.

using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;
using DinkToPdf;
using IPdfConverter = DinkToPdf.Contracts.IConverter;
using Microsoft.WindowsAzure.Storage;
using Microsoft.WindowsAzure.Storage.Blob;
using System.Threading.Tasks;
namespace Html2Pdf
{
    public class Html2Pdf
    {
        // Read more about converter on: https://github.com/rdvojmoc/DinkToPdf
        // For our purposes we are going to use SynchronizedConverter
        IPdfConverter pdfConverter = new SynchronizedConverter(new PdfTools());

        // A function to convert html content to pdf based on the configuration pased as arguments
        // Arguments:
        // HtmlContent: the html content to be converted
        // Width: the width of the pdf to be created. e.g. "8.5in", "21.59cm" etc.
        // Height: the height of the pdf to be created. e.g. "11in", "27.94cm" etc.
        // Margins: the margis around the content
        // DPI: The dpi is very important when you want to print the pdf.
        // Returns a byte array of the pdf which can be stored as a file
        private byte[] BuildPdf(string HtmlContent, string Width, string Height, MarginSettings Margins, int? DPI = 180)
        {
            // Call the Convert method of SynchronizedConverter "pdfConverter"
            return pdfConverter.Convert(new HtmlToPdfDocument()
            {
                // Set the html content
                Objects =
                {
                    new ObjectSettings
                    {
                        HtmlContent = HtmlContent
                    }
                },
                // Set the configurations
                GlobalSettings = new GlobalSettings
                {
                    // PaperKind.A4 can also be used instead of width & height
                    PaperSize = new PechkinPaperSize(Width, Height),
                    DPI = DPI,
                    Margins = Margins
                }
            });
        }
        // The name of the function
        [FunctionName("Html2Pdf")]
        // The first arugment tells that the functions can be triggerd by a POST HTTP request. 
        // The second argument is mainly used for logging information, warnings or errors
        public async Task Run([HttpTrigger(AuthorizationLevel.Function, "POST")] Html2PdfRequest Request, ILogger Log)
        {
            // PDFByteArray is a byte array of pdf generated from the HtmlContent 
            var PDFByteArray = BuildPdf(Request.HtmlContent, "8.5in", "11in", new MarginSettings(0, 0, 0, 0));
           // The connection string of the Storage Account to which our PDF file will be uploaded

            // The connection string of the Storage Account to which our PDF file will be uploaded
            var StorageConnectionString = "DefaultEndpointsProtocol=https;AccountName=<YOUR ACCOUNT NAME>;AccountKey=<YOUR ACCOUNT KEY>;EndpointSuffix=core.windows.net";

            // Generate an instance of CloudStorageAccount by parsing the connection string
            var StorageAccount = CloudStorageAccount.Parse(StorageConnectionString);

            // Create an instance of CloudBlobClient to connect to our storage account
            CloudBlobClient BlobClient = StorageAccount.CreateCloudBlobClient();

            // Get the instance of CloudBlobContainer which points to a container name "pdf"
            // Replace your own container name
            CloudBlobContainer BlobContainer = BlobClient.GetContainerReference("pdf");

            // Get the instance of the CloudBlockBlob to which the PDFByteArray will be uploaded
            CloudBlockBlob Blob = BlobContainer.GetBlockBlobReference(Request.PDFFileName);

            // Upload the pdf blob
            await Blob.UploadFromByteArrayAsync(PDFByteArray, 0, PDFByteArray.Length);
        }
    }
}

This concludes the coding part.

wkhtmltopdf

We will still need to add wkhtmltopdf library in our project. There are a few caveats when selecting a particular Azure App Plan. Based on the Plan, we will have to get the wkhtmltopdf library. For our purposes we have selected Linux Basic (B1) App Service Plan since Windows Basic (B1) App Service Plan is 5 times costlier.

At the time of writing this blog Azure App Service Plan was using Debian 10 with amd64 architecture. Good for us, DinkToPdf provides precompiled libraries for Linux, Windows & MacOS. Download the .so library for Linux and put it in your project’s root folder. I am working on MacOS so I downloaded libwkhtmltox.dylib as well. If you are using Windows or if you have hosted the Azure Functions on Windows App Service Plan you must download the libwkhtmltox.dll. Here is how our project structure will look like.

When we create a build we need to include the .so library. In order to do that open your csproj file and add the below content to the ItemGroup.

<None Update="./libwkhtmltox.so">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    <CopyToPublishDirectory>Always</CopyToPublishDirectory>
</None>

Here is the whole csproj file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="DinkToPdf" Version="1.0.8" />
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.11" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
    <None Update="./libwkhtmltox.so">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Always</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Creating Azure Functions App

Before we deploy to Azure Functions we will have to create the Azure Functions in Azure Portal. You can go to Azure Portal and start creating the Azure Functions resource. You can follow the below screenshots for clarity.

In the below screenshot make sure to select or create at least Basic Plan here. Secondly, in the Operating System select Linux.

It’s good to have Application Insights since you will be able to see logs and monitor functions. Besides, it hardly costs anything. As shown in the screenshot below select Yes if you want to enable it.

Select Next: Tags and again click Next and click Create to create your resource. It might take a few minutes to create the Azure Functions resource.

Deploying to Azure Functions

Once created we will deploy our code directly to Azure Functions via VS Code. For that you will have to go to the extensions and install the Azure Functions extension. With its help we will be able to login and manage Azure Functions.

Once installed you will see Azure icon on the side bar. When clicked, it will open a panel with an option to Sign In to Azure.

Select Sign in to Azure which will open a browser where you can login with your account. Once logged in you can go back to VS Code and see the list of Azure Functions in your side panel.

For me there are 4 function apps. Since you might have created just one it will show one. Time to deploy the app.

Press F1 to open a menu with a list of actions. Select Azure Functions: Deploy to Function App… which will open a list of Azure Functions to which you can deploy. Select our newly created Azure Funtions App. This will ask for a confirmation pop-up, so go ahead and deploy it. It will take a few minutes to deploy your App.

Configuring wkhtmltopdf

Once you have deployed to Azure Functions there is still one last thing to do. We will need to add libwkhtmltox.so to a proper location on our Azure Functions App. Login to Azure portal and navigate to our Azure Functions App. On the side panel search for SSH and click the Go button.

This will open a SSH console in new tab. Our site is located at /home/site/wwwroot. So navigate to it's bin folder by typing in the below command.

cd /home/site/wwwroot/bin

When you execute ls command to view the contents of the file you won’t see the libwkhtmltox.so file. It is actually located at /home/site/wwwroot.

That is not the correct position. We need to copy it in the bin folder. For that execute the below command.

cp ../libwkhtmltox.so libwkhtmltox.so

If you know a better way on how to include the file in the bin folder please suggest in the comment below.

That’s it!!! You have got a fully functional Azure Functions App. Time to call it from our demo dotnet project.

Invoking the Azure Function

All said and done we still need to test and call our function. Before we do that we need to get hold of Code which is required to call the Function. The Code is a secret that needs to be included to call the Function securely. To get the Code navigate to Azure Portal and open your Function App. In the side panel search for Functions.

You will see Html2Pdf in the list. Click on that function which will open the details view. In the side panel there will be an option for Function Keys. Select that option to view a hidden default Code already added for you.

Copy the code and keep that handy since it will be needed in the code. In order to test the function I have created a sample console app for you. Replace the base url and the Code.

using System;
using System.Net;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Threading.Tasks;
using Newtonsoft.Json;
namespace Demo.ConsoleApp
{
    public class Program
    {
        public static async Task Main(string[] args)
        {
            string AzureFunctionsUrl = "https://<Your Base Url>/api/Html2Pdf?code=<Replace with your Code>";
using (HttpClient client = new HttpClient())
            {
                var Request = new Html2PdfRequest
                {
                    HtmlContent = "<h1>Hello World</h1>",
                    PDFFileName = "hello-world.pdf"
                };
                string json = JsonConvert.SerializeObject(Request);
                var buffer = System.Text.Encoding.UTF8.GetBytes(json);
                var byteContent = new ByteArrayContent(buffer);
byteContent.Headers.ContentType = new MediaTypeHeaderValue("application/json");
using (HttpResponseMessage res = await client.PostAsync(AzureFunctionsUrl, byteContent))
                {
                    if (res.StatusCode != HttpStatusCode.NoContent)
                    {
                        throw new Exception("There was an error uploading the pdf");
                    }
                }
            }
        }
    }
public class Html2PdfRequest
    {
        // The HTML content that needs to be converted.
        public string HtmlContent { get; set; }
        // The name of the PDF file to be generated
        public string PDFFileName { get; set; }
    }
}

Again the code should be pretty self explanatory. If you have any feedback or questions please ask in the comment section below. Once you run the above console app, it will create a hello-world.pdf file in your pdf container in Azure Storage.

Conclusion

That concludes our tutorial on how to convert HTML to PDF using Azure Functions. For any feedback, questions or blog topics you can leave a comment below. Subscribe to the newsletter for upcoming and exciting new tutorials.

You can also follow me on medium, dev.to & hashnode.

Visit my blogs for more such tutorials.

At Royale Cheese initially we had setup CI/CD for Android via Microsoft’s Visual Studio App Center (an upgrade of Hockey App), but last year they declared the retirement of MBaas which got us worried about the overall future of VS App Center. That was one of the reasons we wanted to switch away from it. Secondly, the free tier provided around 400 minutes of build time per month per account which would had been sufficient for other technologies, but Android takes around 15 minutes to create a single build and deploy. We all know what gradle is capable of 😉. So having multiple apps (both iOS and Android) in the same account didn’t fare well.

We were already using Azure DevOps for CI/CD for other technologies and it seemed promising. It’s future plan had no issues of shutting down and it provided around 1800 minutes of free build time. We decided to give it a try and so far don’t have any complaints. We have started loving and adoring Azure DevOps and hope it stays this way.

Alright! Enough with the issues, let’s see how we can get the build & deployment going. In this tutorial we are going to make the newer Android App Bundle (.aab) and not .apk to upload to the Google Play Console.

Prerequisites

• Paid Google developer account, an app added to the Play Console.
• Azure DevOps account with an Android repository created
• A jks file to sign the build

Continuous Integration

Continuous Integration is the process of running a build & a test suite every time a change has been pushed on to the repository. Since the Android build do take a substantial amount of time and usually cloud CI/CD tools gets costly with more build time it is better to schedule a the CI pipeline once a week. I will be using a demo project named Android created in my devops account to create ci cd pipelines. The project has a blank activity and support Lollipop 5.0 and above.

Open your project and navigate to Pipelines section on the left panel as in the screenshot below.

Click on Create Pipeline which will open the below page.

Here we are going to select Use the classic editor which is easier than the other options. The other options will eventually lead to writing yaml files for configuring your pipelines.

Usually you might have dev, qa and/or uat branches to upload to the internal or beta channels on Google Play Console and you would only want to promote the app to production from your Google Play Console. So select your branch from which you want to run the build and click Continue. For me everything is on the master branch.

Ideally we would be tempted to select the Android template and get on with our life; Don't Do It. Since the Android template doesn't provide a way to generate an .aab file we are not going to use it. Instead select an empty job.

We will now have an empty Agent Job 1 to which we will be adding tasks.

We are going to have to do the following tasks to create our CI pipeline:

• Setting up a jks file
• Unsigned build via gradle
• Generate .aab file
• Create an Artifact

Let's start step-by-step.

Setting up a jks file

If you have uploaded an apk or aab in the past to the play store you must have used a jks file to sign the build. You should the use the same jks file in this step. If you haven't generated a file yet here is a good documentation.

Get a hold of your jks file since we are going to upload it now. Click on + sign besides Agent Job 1 which will open a list of tasks to add. Search for Download secure file.

Click on the Add button to add the task. It will give an error saying Some settings need attention. It is asking for a secure file to be uploaded. Click on the gear/settings icon besides the Secure file field and upload your jks.

We will now provide a name to this file so that it can be referenced from the sign task. Click on the Output Variables drop down and enter KeyStoreFile in the Reference name. This will update the Variables list to reflect the variable name.

Unsigned gradle file

Click on + sign besides Agent Job 1 which will open a list of tasks to add. Search for gradle.

Click on the Add button to add the task. We are going to turn off Publish to Azure Pipeline under JUnit Test Results section. You can keep it on as per the requirement. Secondly we are going to update the task name. Since we are going to make a release build update your task name to buildRelease. If you want to build using a particular flavour you can update your task name accordingly. e.g. if you are using dev as a flavour name update your task name as buildDevRelease.

Generate .aab file

Click on + sign besides Agent Job 1 which will open a list of tasks to add. Search for Command line.

In the Script section clear the field and set the below text.

jarsigner -verbose -sigalg SHA256withRSA -digestalg SHA-256 -keystore $(KeyStoreFile.secureFilePath) -storepass $(StorePassword) -keypass $(KeyPassword) $(system.defaultworkingdirectory)/app/build/outputs/bundle/release/*.aab $(KeyStoreAlias)

There are 4 variables in the script out of which we have already set KeyStoreFile.secureFilePath. Time to set other 3 variables StorePassword, KeyPassword and KeyStoreAlias. Navigate to the Variables tab on the tap and add the variables and their values as shown in the screenshot below. Once you are sure that the values are correct you can click on the lock icon to secure it. Once you lock and save no one will be able to view it including you, so make sure you still have a backup of the details in case you want to use it somewhere else.

Create an Artifact

The above step creates an .aab file but still needs to be converted in to an artifact so that it is available to the CD pipeline for release.

By now you are a pro at adding tasks to Agent Job 1. Add the following two tasks to Agent Job 1: Copy Files & Publish build artifacts. To avoid confusion of which tasks to select I have added the screenshots below.

Now select the Copy Files task and set $(system.defaultworkingdirectory) in the Source Folder field, **/.aab in the Contents and $(build.artifactstagingdirectory) in the Target Folder*.

Click on Save & queue and click Save to save our CI pipeline.

That is it for the Continuous Integration. We will now head on to the Continuous Deployment to find out how to release the generated artifact to the Internal Testing channel on Play Console.

Continuous Deployment

While Continuous Integration deals with creating a build on the machine itself, Continuous Deployment is all about how will you publish that build to the Play Store, App Store, Self-Hosted or Cloud server. In order to deploy to the Play Store you will need a Google Play Console account and an app created in Play Console with the same bundle id.

Next, we will go back to our Azure DevOps project and select Releases under the pipeline section.

Since there is no pre-defined template for uploading a build to the Play Store, we are going to select an empty job.

We will now enter a stage name for our deployment. You can name it whatever you want. I have kept it as Play Store Deployment

Let's connect the CI artifact with our current CD pipeline. Select Add an artifiact from the artifacts. This will open a dialog on the right to which we will select our artifact. Click the drop down for Source (build pipeline) and you will see Android-CI as one and only option (unless you have added more CI pipelines or altered the CI name).

Select the Android-CI and click Add. After adding the artifact our release pipeline will look something like below.

Since the CI & CD pipelines are separate we should setup a way to automatically trigger the CD pipeline when the CI is successful. To achieve that select the lightning icon for the artifact we just added. This will open a dialog on the right which will have a setting to enable/disable the Continuous Deployment trigger. When the build trigger is enabled our release pipeline will automatically start when a new build is completed by our build (CI) pipeline. We are not going to enable the Pull Request trigger.

So far we have setup the pipeline to start automatically when a new build is available in our build pipeline. We have also setup a Play Store Deployment stage to which we will add tasks for the actual deployment in the next section.

Deployment task

Select 1 job 0 task hyperlink which will switch to the Tasks tab. Select the + plus besides the Agent Job to open a list of new tasks. When you search for Google Play. you will see Google Play by Microsoft. Install the item if not already installed. Once installed and when you search for Google App again you will see a few new tasks as below.

Select the task that says Google Play - Release Bundle and click the Add button (Don't select Google Play - Release). Some settings will need attention which we will take care of one-by-one.

Adding a service connection

Firstly we need to create a new service connection. Click on New button besides the Service Connection field. It will upon up a dialog which primarily asks for a Service Account E-mail and a Private Key. We are going to create a service account on Google Play Console to upload the build. This account will also have a private key attached to it for authentication purposes.

To create the account visit Google Play Console and select API Access under Developer Account under Settings.

Click Create new service account button which will pop open a dialog as below.

Click on the link in step 1 which will redirect you to a new tab of Google Cloud Console.

Click + CREATE SERVICE ACCOUNT on the top to start creating a new account. In the newly opened page I have entered Google Play Console in the service account name but it can be whatever you want. Enter the service account description if needed.

Click CREATE to continue. It will then ask for what permissions do you want to allocate for the user. Click the Role drop down and search for Owner. Select the Owner with Full access to all resources.

Click the Continue button and select Done in step 3 since we don't want to add any users or groups who can perform actions as this service account. You will be redirected to the list of keys page. Now select the newly created account and go to the Keys tab. Here we are going to add a new Private Key for our service connection.

Select Add Key and from the drop down select Create new key. It will show a pop up of which type of key you want to create.

Select the JSON option and click CREATE button. This will ask you to download the file. Store it some place secure we are not going to use the whole file as it is, rather if you open the file it will have a key called private_key.

Before we use this value head back to our google play console's API Access page and click on Done button. It will refresh the list of service accounts with your service account added to the list.

For the newly created service account there will be Grant access button for that row. Click on the button which will open a page to invite the user. Don't get confused with the term invite since Google has probably reused a page to display the same information for the service account.

Click on the Invite User on the bottom right and in the pop up dialog that comes up click on Send Invite. This action will redirect you to Users and Permissions page with the service account added as a new user.

We will now setup the Service Email and the Private key in Azure DevOps. First, copy the email of the newly created service account into the Service Account E-mail in the Azure DevOps tab. Next open the private key json file and copy the value of private_key to Private Key field. Here is what it looks like.

Click on Save which will add the service connection to the Service connection field. Next enter your bundle id in the Application id (com.google.MyApp) field. Finally in the Bundle path you can browse to select the .aab file by clicking the 3 dots on the right. Usually the aab will at location

<your CI name>/drop/app/build/outputs/bundle/release/*.aab

If you haven't run a CI pipeline yet you can set the path as

$(System.DefaultWorkingDirectory)/_Android-CI/drop/app/build/outputs/bundle/release/*.aab

If you are using a flavour prefix release with your flavour name in the path. e.g. the path should be

$(System.DefaultWorkingDirectory)/_Android-CI/drop/app/build/outputs/bundle/devRelease/*.aab

You can select which track you want to launch to from the drop down.

That is all the settings you need. You can now Save the pipeline and run the CI pipeline to build an aab and upload it to the Play Console.

Conclusion

This seems to be a long tutorial but once you are successful in setting up the CI/CD pipelines it would be a huge time saver for your developers. Secondly, it will run on the cloud so there is no need for a physical machine. You can trigger the build from your phone by logging in to Azure DevOps. Hope you have enjoyed this article and hope it helps others in your team.

To learn how to setup CI CD pipeline for iOS you can visit this tutorial.

For any queries you can leave a comment below. Please do follow my page for many more upcoming tutorials.

Open your project on DevOps and select "Releases" under the "Pipelines" section in the left panel. Select the "New Pipeline" which will open up a dialog for selecting a template.

Template Selection & Setup

We are going to select an empty job, since there is no pre-defined template for uploading a build to the App Store.

Enter the stage name as "Deployment". It can be whatever you want but for clarification purposes I set it as Deployment.

We will now select an Artifact which we want to upload. An artifact is something that is created whan an Azure Build Pipeline runs. So in our case the artifact is the one that is generated from our previous tutorial.

Click the Add button besides the Artifacts label or click on Add an artifact. This will open a new dialog on the right.

In the drop down you will see our CI setup from the last tutorial. Select that and click the Add button.

After adding the artifact our release pipeline will look something like below.

Now select the lightning icon for the artifact we just added. This will open a dialog on the right which will have a setting to enable/disable the Continuous Deployment trigger. When the build trigger is enabled our release pipeline will automatically start when a new build is completed by our build (CI) pipeline. We are not going to enable the Pull Request trigger.

So far we have setup the pipeline to start automatically when a new build is available in our build pipeline. We have also setup a Deployment stage to which we will add tasks for the actual deployment in the next section.

Deployment task

Select 1 job 0 task hyperlink which will switch to the Tasks tab. Select the + plus besides the Agent Job to open a list of new tasks. Search for Apple App Store. If you don't see any tasks you will have to install the application from the Marketplace. Once installed when you search for Apple App Store again you will see a couple of new tasks as below.

Add the Apple App Store Release task. It will add the task which requires a Service Connection. A service connection is basically a connection to the Apple's itunesconnect website.

We will now add a new service connection. Click on the New button besides Service Connection which will open a new dialog. In the new dialog enter the email & password. Even though the app-specific password and Fastlane Session are marked as optional they are mandatory to automate the process of uploading the build to App Store.

App-Specific Password

To create app-specific password visit https://appleid.apple.com/account/manage in a new tab and scroll down to the security section. Click on the Generate password... link below the label APP-SPECIFIC PASSWORDS which will open a dialog. Enter any name for the label and click Create. Copy the generated text and switch back to our Azure DevOps tab and paste it under App-specific password field.

Fastlane Session token

As a prerequisite you should already have the fastlane installed on your machine. Fastlane is required to generate the session token so that our cloud machine can login automatically without our intervention. Time to open the terminal and fire some commands.

fastlane spaceship -u xxxxxxx@gmail.com

You will will be asked for your password and then a 6 digit code as a part of two factor authentication. It will generate the session token for you and will ask if you want to copy it. Press 'y' and then switch to your Azure DevOps tab and paste the session token in the Fastlane Session field.

Enter the service connection name as per your preference and the description if you need it.

Publish details

You will see the service connection now set. Next enter your app's bundle id. Select Skip Build Processing Wait and Skip Submission so that our pipeline doesn't wait for the build to be made available, otherwise it will consume precious build minutes. Lastly enter the App Specific Apple Id which you can get by logging into https://appstoreconnect.apple.com and clicking your App to view it's details and then finally visiting App Information under General section.

That is it guys. Your hard work will finally pay off when you run your pipeline and see the green ticks going one by one as the tasks are getting completed. This would be one of the best feeling in the world.

Do you have any suggestions, optimisation and/or just want to connect let me know in the comments below.

At Royale Cheese initially we had setup CI/CD for iOS via Microsoft's Visual Studio App Center, but last year they declared the retirement of MBaas which got us worried about the overall future of VS App Center. That was one of the reasons we wanted to switch away from it. Secondly, the free tier provided around 400 minutes of build time per month per account which would had been sufficient for other technologies, but iOS takes around 15 minutes to create a single build and deploy. So having multiple apps (both iOS and Android) in the same account didn't fare well.

We were already using Azure DevOps for CI/CD for other technologies and it seemed promising. It's future plan had no issues of shutting down and it provided around 1800 minutes of free build time. We decided to give it a try and so far don't have any complaints. We have started loving and adoring Azure DevOps and hope it stays this way.

Alright! Enough with the issues, let's see how we can get the build & deployment going.

Prerequisites

• Paid Apple developer account, an app added to appstoreconnect.apple.com & an identifier added to the developer account.
• Azure DevOps account and an iOS repository created
• fastlane installed locally (for generating session token)

Since for iOS CI and CD are two separate and lengthy processes we will divide the tutorial in two parts. Part 1: Continuous Integration and Part 2: Continuous Deployment

Continuous Integration

Let's start with CI part of CI/CD. In this section we will create a build using the pipeline feature. For demo purposes I have created a project named 'iOS' in Azure DevOps. Open your project and navigate to "Pipelines" on the left panel as in the screenshot below.

Click on "Create Pipeline" which will open the below page.

Here we are going to select "Use the classic editor" which is easier than the other options. The other options will eventually lead to writing yml files for configuring your pipelines.

Select your branch from you which you want to ru the build.

Select "Xcode" from the list of featured items and click Apply.

This will automatically create a build configuration with some basic settings, but we are still a long way. For simplicity we are not going to use "Xcode test" so you can right click on it and select "Remove selected tasks". Also since we are not going to use VS App Center you can remove those tasks as well. We will be distributing our app on TestFlight. So enable the Apple Certificate & Apple Provisioning Profile tasks. It will show some error but we will get there. Our pipeline page will look like below.

Apple Certificate

Let's get the Apple .p12 certificate which is used for signing the build. On your Mac open Keychain app and in the top bar select Keychain Access -> Certificate Assistant -> Request a Certificate from Certificate Authority... Enter the information for the certificate and select "Saved to disk" and continue. It will ask you to save a CertificateSigningRequest.certSigningRequest file. Save it some place accessible on your machine.

We will now add it the above generated file in your apple account. Visit this page from where we will be adding the certificate. Select "Apple Distribution" and continue. The next two pages are self explanatory (see the screenshots below).

Download the certificate file as "distribution.cer". Click on this file which will open the Keychain access and add the certificate file to your Keychain. You can find an entry "Apple Distribution: Your account name" in your Keychain certificates.

Right click on it and select "Export "Apple Distrubtion: name". Save the file as .p12 with a strong password. We have successfully generated the .p12 file required for signing the build.

Apple Provisioning Profile

For this you need to have an identifier added to your developer account. Check prerequisites. Visit your profiles and create a new profile. Select App Store in the distribution section and continue. Select your App ID and continue. Select the certificate which we uploaded in the above step and click continue. Enter the name of your provisioning profile and click "Generate". This will download the provisioning profile on your machine.

Back to DevOps

Phew! that was a long process. Okay, going back to DevOps let's upload the files to their respective tasks. Select the "Install an Apple Certificate" task and click on the gear icon on the right besides the "Certificate (P12)" field. It will ask you to upload the p12 file which we generated above. Once set it will look like below.

Select "Variables" from the top tabs. The variables really come in handy when you want to store keys, secrets or passwords securely. There will already be an entry for your P12password variable. Enter your password in Value and make sure to lock the icon so that you or other people cannot see it once you save the build.

Time to add the provisioning profile. Go back to tasks tab and select "Install an Apple provisioning profile task". Upload your provisioning profile which will now remove any error.

Since we want to sign the build we need to tell the "Xcode build" task to manually sign it using the certificate and provisioning profile we just uploaded. In order to do so select the "Xcode build" task and select "Manual Signing" under "Signing & Provisioning". This will display 3 fields. Enter $(APPLE_CERTIFICATE_SIGNING_IDENTITY) in "Signing Identity" field and $(APPLE_PROV_PROFILE_UUID) in Provisioning Profile UUID field. Finally select the checkbox "Create app package".

Lastly if you are using pods in your project you need to add a CocoaPods task in your pipeline on top. Select the + icon besides "Agent Job 1" to add a new task. Search for CocoaPods and click Add. Drag the task above "Install an Apple Certificate" so that it is the first task that is being executed.

You can now save and queue your build by clicking "Save & queue" button. Make sure to select Mac OS in the Agent Specification other wise it will give an error.

In the next part we will have a look at how to setup Continuous Deployment to the TestFlight using release pipelines.

In this part we will continue our quest to a more better and secure Nginx configuration by setting directives that will help with security & performance optimisations.

Here is the file from previous tutorial. We will be adding directives inside the HTTPS server context.

events {

}

http {
    # HTTP server
    server {
        listen       80;
        return 301 https://localhost:443;
    }


    # HTTPS server
    server {
       listen       443 ssl;

       ssl_certificate /usr/local/etc/ssl/certs/self-signed.crt;
       ssl_certificate_key /usr/local/etc/ssl/private/self-signed.key;

       location / {
           root   /Users/arjav/Desktop/www;
           index  index.html index.htm;
       }
    }
}

Enable only new TLS versions

Transport Layer Security (TLS) are a set of cyrptographic protocols to communicate securely over a computer network. TLS v1.1 and older uses cipher suites that are insecure in today's world. So let's just enable TLS 1.2 & 1.3. Add the new directive just below listen 443 ssl;

ssl_protocols TLSv1.2 TLSv1.3;

Server ciphers

TLSv1.2 and TLSv1.3 have secure enough cipher suites. So it would be okay to have the below option as off. What it basically says is allow the client to select the cipher algorithm that is best for itself but defined in TLSv1.2 and TLSv1.3 only.

ssl_prefer_server_ciphers off;

In case you are as skeptical as me and want to allow a specific cipher suites only, you can turn it on as below and mention the list of ciphers. Do remember that the order of the cipher matters and the client will make selection in that order.

ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";

OCSP Stapling

When a client communicates with a server it needs to verify the server certificate either via Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP). The CRL process is bandwidth consuming and resource heavy while OCSP is much more light weight but with its own issues. Since we are using a self-signed certificate on a local machine it won't be an issue, but for 3rd party certificates all the intermediate certificates needs to be present in your ssl certificate. This can alleviated by using ssl_trusted_certificate directive. You can read more about it here.

ssl_stapling on;
ssl_stapling_verify on;

Diffie-Hellman Parameters

Diffie-Hellman is one of the most common key exchange used in Perfect Forward Secrecy (PFS). Open terminal and run the below command to generate parameters for Diffie-Hellman key exchange. Note: It will take a long time to generate the parameters.

sudo openssl dhparam -out /usr/local/etc/ssl/certs/dhparam.pem 4096

Once generated you can use these parameters by adding the following directive in Nginx

ssl_dhparam /usr/local/etc/ssl/certs/dhparam.pem;

Response Headers

The below directive tells the client that you are allowed to contact the server only via secure HTTPS protocol. Our server is like: Till 'max-age' time passes you cannot contact me via un-secure channels.. If you don't want to include subdomains you can remove includeSubdomains

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains" always;

The next directive is used when you don't want to allow your side to be embedded in an iFrame. For more frame options you can visit mozilla's site.

add_header X-Frame-Options DENY;

Lastly we disable Content or MIME sniffing by applying the below directive. It is one of the key things for avoiding XSS attacks. Also if you will get your site audited it is one of the response headers that needs to be set.

add_header X-Content-Type-Options nosniff;

There are a lot of other response headers you can set to optimise the website and increase security. For further details Mozilla has great resources for the same: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers.

Session Caching

Caching a TLS connection is helpful to avoid unnecessary handshakes in turn increasing your performance of the site. The caching can be set with the help of below directives.

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h;

The directives say that the session cache is shared among all worker processes and can use upto 10MB of space. The time out for each session is 1h.

Conclusion

These SSL directives will make your website secure and perform better. Our final nginx.conf file will be as below:

events {

}

http {
    # HTTP server
    server {
        listen       80;
        return 301 https://localhost:443;
    }


    # HTTPS server
    server {
       listen       443 ssl;

       ssl_certificate /usr/local/etc/ssl/certs/self-signed.crt;
       ssl_certificate_key /usr/local/etc/ssl/private/self-signed.key;

      # Enable only TLSv1.2 TLSv1.3;
      ssl_protocols TLSv1.2 TLSv1.3;

      # Enable cipher suites
      ssl_prefer_server_ciphers on;
      ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";

      # Enable OCSP stapling
      ssl_stapling on;
      ssl_stapling_verify on;


      # Set DH parameters
      ssl_dhparam /usr/local/etc/ssl/certs/dhparam.pem;


      # Add Response Headers
      add_header Strict-Transport-Security "max-age=63072000; includeSubdomains" always;
      add_header X-Frame-Options DENY;
      add_header X-Content-Type-Options "nosniff";

      # Cache Connections
      ssl_session_cache shared:SSL:10m;

       location / {
           root   /Users/arjav/Desktop/www;
           index  index.html index.htm;
       }
    }
}

PS: Since Nginx is cross-platform these directives can work on any OS. Just make sure that you select the paths specific to OS.

That concludes our 4 part series of NGINX on MAC. Hope you have enjoyed it. If you are looking for installing & configuring Nginx on Linux to host a laravel project digital ocean has a nice tutorial Installing & Configuring Laravel. Make sure to go through the pre-requisites.

In this part we will be configuring Nginx with a self-signed certificate. We will be creating a self signed certificate using openssl and make Nginx use it for serving content over https. Let's get our hands dirty. Open our pal, Terminal and lets create a couple of folders to store our key and certificate. Fire the following commands:

mkdir -p /usr/local/etc/ssl/private
mkdir -p /usr/local/etc/ssl/certs

Ideally you can create these folders anywhere but it's a good practice to have them at the above given path. We will now create key and certificate by running the below command:

sudo openssl req \
  -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout /usr/local/etc/ssl/private/self-signed.key \
  -out /usr/local/etc/ssl/certs/self-signed.crt

Let's alter our server context from previous tutorial. The updated file is as below.

events {

}


http {
    server {
        # Listen on port 80 which is the default http port
        listen 80;

        # Set a permanent redirection from http to https
        return 301 https://localhost:443;
    }
}

Add another server context inside http context with configuration and locations relating to SSL

 server {
       listen       443 ssl;

       # location of ssl certificate
       ssl_certificate /usr/local/etc/ssl/certs/self-signed.crt;

       # location of ssl key
       ssl_certificate_key /usr/local/etc/ssl/private/self-signed.key;
    }

Add location context inside the ssl server context

location / {
    root   /Users/arjav/Desktop/www;
    index  index.html index.htm;
}

This is the whole configuration file:

events {

}

http {
    # HTTP server
    server {
        listen       80;
        return 301 https://localhost:443;
    }


    # HTTPS server
    server {
       listen       443 ssl;

       ssl_certificate /usr/local/etc/ssl/certs/self-signed.crt;
       ssl_certificate_key /usr/local/etc/ssl/private/self-signed.key;

       location / {
           root   /Users/arjav/Desktop/www;
           index  index.html index.htm;
       }
    }
}

As a last step we will need to add the self-signed certificate to the system keychain. Run the below command in your terminal.

sudo security add-trusted-cert \
  -d -r trustRoot \
  -k /Library/Keychains/System.keychain /usr/local/etc/ssl/certs/self-signed.crt

Voila! That's it. In your terminal verify your configuration file by running nginx -t and if everything looks okay reload your Nginx server by running nginx -s reload. Visit https://127.0.0.1. You will still see a red flag or "Not secure" sign in your browser saying that your certificate is invalid, but that it's because not signed by a third-part authority. Rest assured the content is served over secure channels.

In the next chapter we will look at some advanced ssl configuration options for better security, caching and optimisation.

Configuration file

Your Nginx configuration file will be located at /usr/local/etc/nginx/nginx.conf. You can fire nginx -t to run a test configuration just to verify the location. Open the nginx.conf file to see it's contents. I usually use Microsoft's VS Code to edit any text files, so I ran the below command to open the file in VS Code. You can use any text editor you want.

code /usr/local/etc/nginx.conf

Once open you will see a the config file already has content in it most of which is commented out. You can clear everything so that we can take one step at a time. Run nginx -t to test the configuration file we just cleared out. It will give an error saying no "events" section in configuration which simply means there is no events context. Add the events context as follows:

events {

}

The events context helps you with configuration of the server like how many worker connections can be open at the same time and how polling happens among them.

Now when you run nginx -t you will not get any error but when you open http://127.0.0.1:8080 you will be faced with This site can’t be reached error since we have not set our server locations yet. Time to do that!

Below your events context add another context with name http. Inside http context add context with name server. Finally, inside server context add context named location. It should look like below.

events {
}

http {
    server {
        # We are configuring for the / location
        location / {

        }
    }    
}

We have created a skeleton inside which we will now put some flesh and bones. Add a root directive inside the location context with a path pointing to your html directory. For demo purposes I have created a www folder on my Desktop. You can place your folder where ever you like. In the folder I have created an index.html with content <h1>HELLO WORLD</h1>. Here is the overall config file

events {
}

http {
    server {
        # listen on the port 8080
        listen 8080;

        # When 127.0.0.1:8080 is visited, serve content from www on Desktop
        location / {
            root /Users/arjav/Desktop/www;
        }
    }    
}

That's it!!! This is the simplest configuration you can have in nginx. From your terminal run nginx -s reload to reload nginx and visit http://127.0.0.1:8080 in your browser and you will see a nice big HELLO WORLD. Press Cmd+Shift+R to hard refresh your browser in case you are seeing some cached content.

Next -> Configure self-signed SSL.

This is a multipart part series where we will be installing, configuring and deploying Nginx on a local machine with Mac OS installed as it were a production machine.

Let's start with Part 1: Installing Nginx.

Installing Homebrew

We will be using Homebrew to install Nginx. To install Homebrew open your terminal and fire the below command:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

You can visit https://brew.sh/ for more details

If Homebrew is already installed you can use the below command to update the repository index

brew update

Installing Nginx

Once Homebrew is installed, installing Nginx is as easy as

brew install nginx

Once installed you can see the version of the Nginx that is installed in the Summary.

Starting and Stopping Nginx

To start the Nginx server fire the below command.

nginx

It will start the web server. You can then visit http://127.0.0.1:8080 in your browser to see a welcome message by Nginx.

To stop the Nginx server add the stop signal as below.

nginx -s stop

Next -> Part 2: Simple Configuration Nginx on Mac