Test your Angular App with a Local Mock API JSON Server

Ever wanted to test your front end will a fully functional fake REST API before connecting it to your actual backend? Well now you can in 30 seconds with this nifty npm package – so let’s get started.

In your Angular app install the json-server.

npm install -D json-server

In package.json include the following json-server command in the "scripts" block:

"scripts": {   
  "test": "ng test",    
  "lint": "ng lint",   
  "e2e": "ng e2e",    
  "json-server": "json-server --watch db.json --port 3004"  

Create a db.json file in your root directory with the following contents:

  "posts": [
    { "id": 1, "title": "json-server", "author": "typicode" }
  "comments": [
    { "id": 1, "body": "some comment", "postId": 1 }
  "profile": { "name": "typicode" }

Next write a simple GET request to fetch the only "post" object in the database.

import {Component, OnInit} from '@angular/core';
import {HttpClient} from '@angular/common/http';
import {tap} from 'rxjs/operators';

  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
export class AppComponent implements OnInit {

  constructor(private httpClient: HttpClient) {}

  ngOnInit(): void {

Time to serve your Angular app and fake REST API! In two separate terminal windows start your Angular development server and the JSON server.

ng serve
npm run json-server

If you open the console of your Angular app you’ll see that the data was fetched and is ready to use!

fake REST API GET request success
fake REST API GET request success

I highly recommend you look through the official documentation of this package as there’s so much more you can do with this fake REST API tool. Happy prototyping!

Styling inner HTML with Angular special selectors

In this post I show how to style the HTML in Angular’s [innerHtml] using special style selectors ::ng-deep and :host.

The problem

In an application I’m working, we’re using an open source text editor that saves text as HTML in the backend for certain product descriptions. To display the saved HTML we used the [innerHTML] directive, however, some of the styles saved to the backend did match the CSS theme on the front end, making for ugly looking typography. To fix this, I tried styling the HTML blocks as I normally would but to no avail! There must be another way to target the embedded HTML.

Inner HTML directive Angular

The solution

After some research and looking through the Angular styling documentation, I found that I was able to successfully target and style the HTML blocks inside of the [innerHtml] with the :host and ::ng-deep special style selectors.

Styling with Angular special selectors

I needed both the :host and ::ng-deep pseudo-selectors because I wanted to keep the scope of this style to the current component and all its descendants. If I just used ::ng-deep pseudo-selector without :host , then the style can bleed into other components.



Deploy an Angular app on S3 in 5 minutes

In this post I’ll be showing you how to deploy an Angular application to AWS S3. This post assumes that you already have an AWS account.

Advantages of hosting you Angular application on S3:

  • Cheap
  • Almost no maintenance
  • Easy to deploy

Step 1 – Create a new Angular app

Install the Angular command line interface

npm install -g @angular/cli

Create a new Angular app with the cli

ng new my-app

You can click “Enter” twice in the console to not include Angular Routing and include CSS in the newly generated Angular app on your local machine.

angular create new app command
ng new my-app

With a fresh new Angular app ready to go, it’s time to build the static production bundle.

Step 2 – Build the app

Build the production bundle of the application

ng build --prod

This will generate a dist/ folder, as specified in angular.json in the root directory of your project like so.

Angular build production bundle command line interface
ng build –prod

Once the build process is done you will the generated static files where index.html will be the entry point of the app.

Angular production build

Step 3 – Deploy to S3

In your AWS S3 console, create a new bucket to host your web application and make sure you uncheck “Block all public access” during the “Configure Options” step in the creation process.

Once the bucket is created, drag and drop all the files of the my-app folder that resides inside the dist folder into your S3 bucket. When setting the S3 permissions, select “Grant public read access to this object(s)” as seen below.

set S3 permissions
set S3 permissions

Click “next” through the other options and then AWS will upload your static files to the S3 bucket.

files deployed to S3
files deployed to S3

Lastly, we now hove to tell S3 to serve index.html as the starting point of our application. Navigate to the bucket properties and turn on static website hosting. Set index.html as the entry point of the application and save the configuration. Once you save the configuration click the “Endpoint” link and you will see your hosted Angular app live on the web! Congrats!

static web hosting configuration on S3
static web hosting configuration on S3

Do you need more granular control of how you host your Angular app? Check out my other post on how you can create you own custom configuration with EC2 and Nginx to deploy your Angular app.

View your Angular local development environment on your phone

In this post I will show you how ngrok has become an invaluable tool for testing responsive designs – especially on mobile phones. It’s probably the easiest local development tunnel I’ve ever used. Let’s get started:

Step 1 – Setup & Installation

Navigate to https://ngrok.com/ and click the “Get started for free” button. Once you create a free account, you’ll find yourself on the dashboard page with a set of small instructions:

ngrok home page
  1. Download the ngrok zip file for your OS
  2. Unzip the file that was just downloaded $ unzip /path/to/ngrok.zip
  3. Connect your account with the token they provide you `$ ./ngrok authtoken your_token_should_be_very_long_3485994389

Step 2 – Serve & Connect

I’m running my local Angular development environment on port 4200. Please change the port number in the following commands if you’re running on a different port.

With your local Angular development server running in the background. Run the following in your terminal:

$ ./ngrok http 4200 -host-header="localhost:4200"

After which your terminal will look like the following which means your local development tunnel has opened.

ngrok terminal

Simply copy and paste the “Forwarding” address into the URL of any phone, tablet, or really anything else you want to view your local development server on and you should see you Angular application!

To quit the local development tunnel run Crtl + C.

Installing WordPress on top of your Angular App

The problem

When companies decided to build their core application with modern Javascript libraries and frameworks such as React, Vue.js or Angular, they do so because of their native feel and amazing user experience. As the application scales and the proof of concept is achieved, more time and money will be invested in marketing and improving SEO.

Soon the marking team will want to run their own experiments to try and increase the conversion rate and test other campaigns. Now the marketing team will flood the engineering teams backlog with marketing related tasks such as updating blog posts, changing images, user flow tracking integrations, etc. This will exponentially slow down the rate of development on business objectives. So how do you give the marketing team their freedom and clear up the engineering back log?

The solution

Give the people what they want! A solution I’ve used a few times now is to install and and configure WordPress to take care of the static pages of the website. As you probably already know WordPress ships with a great admin user interface where almost anyone and log in and alter the static parts of the website with little or no technical experience. With a WordPress admin interface, the marketing team won’t have to bother the engineers with tasks that could disrupt their focus.

NOTE: There are plenty of other great content management systems out there that will do the job.

I’ve shared the nignx configuration below that I’ve used to direct traffic to the right code base depending on the requested route. I serve the WordPress pages from the http://www.my-app.com/ base directory and the Angular application from a sub-directory http://www.my-app.com/app/.

server {

    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/wordpress;
    index index.html index.php;

    server_name www.my-app.com; 
    server_tokens off; 

    error_log /var/log/nginx/error.log; 
    access_log /var/log/nginx/access.log; 

    #### WordPress Routes ####

    location = / {
        # WordPress site log files
        error_log /var/log/nginx/wordpress-error.log; 
        access_log /var/log/nginx/wordpress-access.log; 
        try_files $uri $uri/ /index.php?$args;

    # Other WordPress routes ...

    location ~ .php$ {
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        include fastcgi_params;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;

    location = /favicon.ico {
        log_not_found off;
        access_log off;

    location ~* .(js|css|png|jpg|jpeg|gif|ico)$ {
        expires max;
        access_log off;
        log_not_found off;

    # robots.txt fallback to index.php
    location = /robots.txt {
        # Some WordPress plugins gererate robots.txt file
        allow all;
        try_files $uri $uri/ /index.php?$args @robots;
        access_log off;
        log_not_found off;

    # additional fallback if robots.txt doesn't exist
    location @robots {
        return 200 "User-agent: *\nDisallow: /wp-admin/\nAllow: /wp-admin/admin-ajax.php\n";

    # Deny all attempts to access hidden files such as
    #.htaccess, .htpasswd, .DS_Store (Mac) excepted
    # .well-known directory. Keep logging the requests 
    # to parse later (or to pass to firewall
    # utilities such as fail2ban)
    location ~ /.(?!well-known\/) {
        deny all;

    # Deny access to any files with a .php extension 
    # in the uploads directory for the single site
    location /wp-content/uploads {
        location ~ .php$ {
            deny all; 

    # Deny access to any files with a .php extension
    # in the uploads directory
    # Works in sub-directory installs and also in 
    # multisite network
    # Keep logging the requests to parse later 
    # (or to pass to firewall utilities such as fail2ban)
    location ~* /(?:uploads|files)/.*.php$ { 
        deny all; 

    ####  Angular Routes  ####

    location ^~/app/ {
        # User Portal log files
        error_log /var/log/nginx/portal-error.log;
        access_log /var/log/nginx/portal-access.log;
        alias /var/www/dist/my-angular-bundle/;
        try_files $uri$args $uri$args/ /index.html =404;

Comment if you have any questions!

Local WordPress Development with Vagrant

The purpose of this post is to show you how to set up an isolated WordPress development environment on your local machine with Vagrant. The benefits of using Vagrant for development is that all your dependencies/packages are installed in an isolated, reproducible, & disposable development environment that doesn’t effect your local machine.

Learn more about what Vagrant is here.

This tutorial assumes that you have both Vagrant and Virtual Box install on your local machine. If not here are the links to both:

  1. https://www.vagrantup.com/
  2. https://www.virtualbox.org/

Once both are installed you will be able to complete the rest of this tutorial.

Step 1 – Fetch WordPress Source Code

Clone the latest WordPress source code from their Github:

git clone https://github.com/WordPress/WordPress.git

When git is done fetching the source code you should have a new WordPress folder in your working directory which contains all the WordPress source code files.

Step 2 – Create a Vagrantfile

Run the vagrant init command to generate a new Vagrantfile in the same directory as you cloned the WordPress source code.


The Vagrantfile generated tells VirtualBox how to provision and run the Ubuntu virtual machine we will spin up. We’ll edit this in a bit.

For a bit of house cleaning, let’s create a parent folder called wp and put both the WordPress source code and Vagrantfile inside it.

mkdir wp
Code directory

Step 3 – Quick Configuration Changes

Configure the Vagrantfile

Open the wp folder with your favorite text editor and edit the Vagrantfile to look like the following:

Vagrant.configure("2") do |config|
# The base disk image will be Ubuntu 16.04 LTS
config.vm.box = "ubuntu/xenial64"

# Set the host name of the machine
config.vm.hostname = "wordpress"

# A friendly message to appear on machine start up
config.vm.post_up_message = "Welcome to WordPress mate!"

# The private IP to access the virtual machine on your local
config.vm.network "private_network", ip: ""

# Syncs the shared folder WordPress source code to
# /var/www/Wordpress on the virtual machine
config.vm.synced_folder "Wordpress", "/var/www/Wordpress"

# On start up the machine will run these commands to install
# Nginx
# PHP 7.0 packages we need to run WordPress
config.vm.provision "shell", inline: <<-SHELL
apt-get update
apt-get install -y nginx
apt-get install -y php7.0 php7.0-common php7.0-mbstring php7.0-gd php7.0-intl php7.0-xml php7.0-mysql php7.0-mcrypt php7.0-fpm

Configure WordPress

  1. In the WordPress source code folder rename the wp-config-sample.php to wp-config.php.
  2. In the wp-config.php update the salts with salts generate from this website https://api.wordpress.org/secret-key/1.1/salt/
  3. Update define( 'DB_NAME', 'database_name_here' ); with whatever name you want your database to be
  4. Update define( 'DB_USER', 'username_here' ); to be define( 'DB_USER', 'root' );
  5. Update define( 'DB_PASSWORD', 'password ); to be define( 'DB_PASSWORD', 'root' );
Wordpress configuration file

NOTE: For live environments I would highly recommend not using the root user for MySQL nor such a simple password.

Step 4 – Enter the Machine

With these configurations done it’s time to start your virtual machine with vargant up. When the machine is done provisioning and installing all dependencies you’ll see your friendly message in the terminal.


To check that everything is working so far navigate to on your local machine. You should see the default Nginx page.

Nginx default page

Congratulations, you now have a high performance web server running on your local machine! Just a few more steps to go.

Step 5 – Install MySQL

ssh into your machine with vagrant ssh and install MySQL on your virtual machine with

sudo apt-get install -y mysql-server

After which you will be prompted to enter and reconfirm a password. Above we made out database password root so we will use that input for both prompts.

MySQL Password Prompt
MySQL Confirm Password Prompt

Now we will create our database with the same name as specified in our wp-config.php file. Mine was called wp_db. From inside the machine log into your MySQL instance as the root user with:

mysql -u root -p

Once in the MySQL command line, create your database with:


And then exit the MySQL command line with:

Terminal of virtual machine

Step 6 – Configure Nginx

In your virtual machine, create a wordpress file in /etc/nginx/sites-available with the following contents:

server {
listen 80;
root /var/www/Wordpress;
index index.php index.html;
server_name example.com;

location / {
try_files $uri $uri/ =404;

location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;

location ~ /\.ht {
deny all;

Remove the default file from /etc/nginx/sites-enabled and symlink the wordpress file you created in the sites-available directory to sites-enabled

Terminal of virtual machine

Confirm that your Nginx configuration is valid with:

sudo nginx -t

Restart your Nginx web server

sudo nginx -s reload

You’re Done!

Reload and you should WordPress!

Wordpress settings page

Please let me know how I can improve this post and I’ll be happy to update it!

Configure Angular for Multiple Development Environments

In this post I’ll show you how I set up my angular.json file to support multiple build environments for an Angular 6 application. I’ve used the configuration below in a development stack where I had a development, staging, and production server.


// angular.json
"configurations": {
"production": {
"fileReplacements": [
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.prod.ts"
"optimization": true,
"outputHashing": "all",
"sourceMap": false,
"extractCss": false,
"namedChunks": false,
"aot": true,
"extractLicenses": true,
"vendorChunk": false,
"buildOptimizer": true
"staging": {
"fileReplacements": [
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.staging.ts"
"optimization": true,
"outputHashing": "all",
"sourceMap": false,
"extractCss": true,
"namedChunks": false,
"aot": true,
"extractLicenses": true,
"vendorChunk": false,
"buildOptimizer": true
"development": {
"fileReplacements": [
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.dev.ts"
"optimization": true,
"outputHashing": "all",
"sourceMap": false,
"extractCss": false,
"namedChunks": false,
"aot": true,
"extractLicenses": true,
"vendorChunk": false,
"buildOptimizer": true

Each configuration tells Angular to replace /environment.ts with the correct environment file in the "with": block.

Now when you run

ng build --configuration=development

The Angular CLI will build an optimized static bundle in the newly generated dist/ directory with the environment variables in environment.dev.ts.

CI/CD Possibilities

With this setup I was able to create an AWS CI/CD pipeline using CodeCommit, CodeBuild, CodeDeploy, and CodePipeline. The AWS CodeBuild service allowed me to set variables at build time so making an automated pipeline for each EC2 instance was as simple as replacing the above command with:

ng build --configuration=$ENVIRONMENT

For those of you interested here is the buildspec.yml I used for my AWS CI/CD pipeline:

version: 0.2

- npm install -y npm@latest
- npm install -g @angular/cli
- rm package-lock.json
- npm install
- echo build started on `date`
- ng build --configuration=$ENVIRONMENT
- ls -l -F
- echo Production build ended on `date`
- appspec.yml
- dist/my-app/**/*
- node_modules/

Comment below if you would like me to write a post on how I made the all AWS CI/CD pipeline!

Top Visual Studio Code extensions for Angular Development

Below is a list of some VSCode extensions I use heavily when developing Angular web applications that have helped me move faster. Check them out!


This first tool is not a VSCode extension, however, I have been using this lately as an invaluable tool when developing in bigger teams. As a developer you will spend a lot of time reading other people’s code where there may not be any documentation. The good people at Compodoc give you an out-of-the-box solution for automatically generating an entire static site of documentation for your Angular project right in your working directory. By providing some really cool graphical diagrams of all the imports, routes, and modules, understanding other people’s code just got a little easier.

Angular7 Snippets

Having this extension installed provides hot keys and short cuts to generate Angular and Typescript snippets. There’s not much more to be said here.


Prettier is my de-facto code formatter and takes care of 80% of all of my code formatting. It’s also extremely customizable in that you can include a .prettierrc file in the root directory of your project and customize exactly how Prettier formats your code. Recently I’ve been turned off by the way it formats HTMLcode blocks so I’ve added a .prettierignore file to the root directory of my project to tell Prettier to ignore formatting my HTML – hence the missing 20%. See some sample files below:

// .prettierrc
"trailingComma": "es5",
"tabWidth": 2,
"semi": true,
"singleQuote": true
// .prettierignore

Code Spell Checker

Anybody writing code should some sort of spell checker in place. If you’re like me misspell words constantly then this extension will help you spot your blunders and correct them before your users read your mistakes in production!

You’ve inherited 100,000 lines of spaghetti code. Now what?

It’s the first day of your job at your startup as the new Angular developer on the block and you spend the first week warming up to the code base. On Friday your founder interrupts your morning coffee to say that he wants you to start working on updating an existing feature. You say “Sure! It’s about time I got my hands dirty”. You roll up your sleeves and get to work only to find:

  • Copy and pasted PHP code snippets in your Angular project
  • heavily using var instead of let or const
  • == instead of === almost everywhere you can find any object comparison
  • Each HTML and TypeScript file pushes ~1200 lines of code
  • Each route is it’s own component – there are no reusable components

And guess what! It’s all yours buddy. Don’t fret! Here’s what you should not do in this situation.

What you shouldn’t do

1. Don’t whine or complain

Do not set up a meeting with your boss and say “Hey this code base is horrible. We have to stop everything and re-do it all”. What are you expecting your founder to say to this? “Hey, wow bob, well…when you put it that way we should stop all product development and refactor the whole thing the way you want it”. Throwing your problems at your boss does not help the business. If you’re going to present a problem, present a solution or at least things you’ve tried. The business isn’t going to stop because you arrived.

2. Don’t be a cowboy

Your inner perfectionist is coming out now and you have the sudden urge to re-write the code base or at least most of it thinking you can do it better. Don’t. What is working now in production is working. There are many months, maybe even years of knowledge and experience behind that code block you just want to tear apart. Document the mysterious code blocks/components so that the next guy who looks at the code has some knowledge to work with. Refactoring the whole code base will be a drain of your company’s resources.

What you should do (from my experience)

1. Communicate constructively

Everything starts with solid communication. You should communicate with your direct report that the code is not in the best condition where you can just start pumping out features but that you’ll do your best to keep up with the deadlines. Don’t torture yourself by keeping the state of the project a secret and burn yourself out to meet a deadline to “just make it work” because you’re still warming up to the code base. This always leads to problems down the line. Work with your product manager to set appropriate deadlines. 

2. Start enforcing standards from day one

Do your best not to contribute to the spaghetti mess that you inherited. Start implementing some coding standards from day one and continue to enforce those standards. This will be very hard in the beginning, however, you will be very happy you did in a few months. You have to start somewhere right?

3. Understand your data services

I’ve found that the most effective way for me to start breaking up my Angular application in to components is to first understand the services that provide data to the components and make them accessible. When I start making my components, I try to make them as independent as possible from the other components. Understanding where your data is coming from and how to inject it properly in each component will help keep your components more independent, maintainable, and reusable.

3. Create your reusable components

Once you know where you data feeds are at, building reusable and maintainable components is a synch. In time you’ll see your code base come together and maybe you won’t be hating your work as much when sprints are easier to complete because you put the ground work to make reusable components.

Final notes

Refactor the code bit by bit on each deployment and soon you will be a much happier camper in about a month. Work hard but don’t forget to work smart. Please drop some comments below on how you guys have dealt with similar situations.

How to switch between versions of Node on Mac with nvm

In this article, we’ll explore how to easily switch between different versions of node using the node version manager (nvm) on MacOS. 

The technologies used in this tutorial are

Step 1 – Install nvm

The first step is to visit the official nvm repository and look through the README.md. To install nvm via curl open up your terminal and enter the following command:

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash

Step 2 – Verify nvm Installation

If nvm was installed successfully, the output of the following command will return ‘nvm’

command -v nvm

If you do not see this output above you may have to restart your terminal application. Once you’ve verified you have installed nvm correctly you’re all set to start managing the global versions on node on your mac!

Step 3 – Install & Manage node

If you’re completely new to nvm I highly recommend reading the output of 

nvm --help

to view, all the options nvm have to offer. To download, install, and compile the latest release of node use

nvm install node

or use the following command to install a specific version of node

nvm install 10.12.0

To view the list of node versions you have installed via nvm use: 

nvm list

As you see in this output, I’m using v10.12.0 on my local mac. If I wanted to switch to node v11.3.0 I can simply do:

nvm use 11.3.0

and nvm will automatically configure my local to use node v11.3.0 instead of v10.12.0. 

Final Notes

Hopefully, you found this how-to on managing node versions very helpful. Please let me know if anything here was not clear and I’ll be happy to update this post!