Today, we will examine 4 different methods to store data in a web browser along with basic code examples. We will also touch on an upcoming new storage API that is currently in the experimental stage.

Introduction

As web applications become increasingly complex, more sophisticated methods to store data locally on the client-side is needed to match with the capabilities of the multitude of server-side storage options available.

Storing data locally also enables offline capability in a web application that helps deliver a smoother user experience for your users even when under poor network condition.

Let's look at the different storage options available in a modern web browser.

1. Cookies

The most common purpose of storing data locally in web browsers is to retain user session. This has been faithfully served by the use of Cookies ever since the introduction of the Mosaic Netscape browser released in 1994.

To set a cookie, a server needs to return the Set-Cookie in the HTTP response headers as such:

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: app_session=abcde12345

Most server-side languages have specific methods to do so. For example, in PHP you could call the setcookie() method:

<?php
setcookie("app_session", "abcde12345");
// must be set before any other output
...

The cookie will then get sent back to the server that matches the domain in subsequent requests to the server.

To retrieve the cookies on the frontend, you can access them with the following JavaScript property:

document.cookie
// will return "app_session=abcde12345;"

❗️ Only cookies that are not set with the HttpOnly option is accessible via code on the client-side browser.

You can also use the same property to set a cookie from the browser:

document.cookie = "session_id=abcde12345";

❗️ Please note that multiple cookies with the same name can exist for the same domain path. Your application must be able to determine which value to use.

However, a cookie can only hold a limited amount of data. In fact, you can only store up to 4096 bytes of data in a cookie. Not to mention cookies come with an expiration date, just like the Christmas cookies from last year that you are still keeping in your jar.

Cookies also get sent back to the domain server in every request, which may not be necessary for certain types of web applications.

2. localStorage

That's when localStorage comes to the picture. localStorage provides none of the limitations of a cookie stated above, while at the same time able to persist the data even when the browser was restarted.

With localStorage, you can store up to 5MB of data in Google Chrome, and they will never expire unless explicitly cleared by the user or through JavaScript code.

You may also be able to save on bandwidth as localStorage does not send its data to the server in every request.

Here's how you can store data into localStorage using JavaScript:

localStorage.setItem('product_id', 25);

You may close the browser window and the data will still persist in the localStorage.

To retrieve the data, simply run the following JavaScript code:

localStorage.getItem('product_id')
// will return "25"

All data save to localStorage will be converted into Strings. Therefore, if you want to store objects, you can use JSON to do so:

localStorage.setItem('person', JSON.stringify({ name: 'John' }));
// will be converted into strings as "{"name":"John"}"

To read the object data, just parse the returned string with JSON again:

JSON.parse(localStorage.getItem('person'))
// returns a proper Object type

You may also perform other operations to the data easily through the following methods:

localStorage.removeItem('product_id')
// remove an item by key

localStorage.clear()
// remove all data

localStorage data are bound to the current domain, protocol, and port. So, data between different domain's localStorage space will not interfere with each other.

This also means that if a user has another tab or window opened with the same domain origin, both can read the same data in the domain's localStorage. This shared property is useful in applications where you need to ensure data integrity across all active app instances.

However, if you do not want data to retain after the browser window is closed or to share data across other opened windows, you may consider using sessionStorage instead.

3. sessionStorage

sessionStorage has the same properties and methods with localStorage, but it's limited in two ways.

The first is that the data stored in sessionStorage will only survive a page refresh, but will be gone if the window is closed.

As the name implies, sessionStorage is more useful for application where data is only needed to be retained throughout the current browser session.

The second limitation of sessionStorage is that the data are only available to the current window, and it's not available to another tab or window opened even with the same domain origin.

This is useful in cases where you want your user to have a fresh session every time they load your application site.

4. IndexedDB

If you require a storage solution that is more closely resembles a database, you may consider using the IndexedDB storage.

With IndexedDB, you can store more than just strings and plain text in a much bigger storage size limit. We are talking about up to 60% of the device's available space. Therefore, storing a few hundred megabytes of data is possible.

IndexedDB even supports transaction, queries, auto-increment, and indexes, just like a database engine that is commonly used on the server-side.

With such powerful capabilities, IndexedDB is best used for building offline web applications that are typically used together with ServiceWorkers.

Let's look at some code on how to store data into IndexedDB.

i) Open a Connection

Just like a typical database, before we can insert any data, we need to open a connection to it:

// the syntax is indexedDB.open(name, version);
let openRequest = indexedDB.open('myLocalDb', 1);

Similar to other Web Storage methods mentioned earlier, the database will exist within the current origin domain, protocol, and port. But as you can guess from the code above, you can have many databases within an origin. All you need to do is open a new IndexedDB connection with a different name.

The openRequest is now an object and will emit onsuccess, onerror, and onupgradeneeded events to be listened to subsequently.

The onupgradeneeded will only be triggered if the database has not been created before, or a new version number is introduced.

ii) Create an Object Store

Next, let's create a table or collection. In IndexedDB, this is called an Object Store, which can only be created in the onupgradeneeded event handler:

openRequest.onupgradeneeded = function() {
    let db = openRequest.result;

    // the syntax is createObjectStore(name[, keyOptions]);
    db.createObjectStore('fruits', {keyPath: 'id'});
    // keyPath is the object property that IndexedDB will use as the key for query later
};

This makes sense because you don't want to keep running the object store creation script every time your application is launched.

If you want to create or modify an object store, you will have to change the version number when opening a new IndexedDB connection.

iii) Storing Data

Once our object store is available, we can now store some data into it within the onsuccess handler:

openRequest.onsuccess = function() {
    let db = openRequest.result;

    // prepare the transaction
    let transaction = db.transaction('fruits', 'readwrite');
    // 'readwrite' means we want to perform a write operation

    // prepare the object store for use
    let fruits = transaction.objectStore('fruits');

    // our data to be stored. Any data type is possible
    let banana = {
        id: 'banana',
        price: 12,
        created: new Date()
    };

    // add the data into the object store
    let request = fruits.add(banana);

    request.onsuccess = function() {
        console.log("Fruit added successfully", request.result);
    };

    request.onerror = function() {
        console.log("Error: ", request.error);
    };
};

iv) Retrieving Data

To retrieve our data, just call the get() method on the object store as such:

openRequest.onsuccess = function() {
    let db = openRequest.result;

    // prepare the transaction
    let transaction = db.transaction('fruits', 'readonly');
    // 'readonly' indicates we only want to retrieve data

    // prepare the object store for use
    let fruits = transaction.objectStore('fruits');

    // get the data by the id keyPath
    let request = fruits.get('banana');

    request.onsuccess = function() {
        console.log("Fruit: ", request.result);
    };

    request.onerror = function() {
        console.log("Error: ", request.error);
    };
};

v) Deleting Data

To remove data from the object store, we can use the delete() method:

openRequest.onsuccess = function() {
    ...
    // similar code as before
    let transaction = db.transaction('fruits', 'readwrite');
    // here we need to specify 'readwrite' because we are modifying data

    // delete data by keyPath
    fruits.delete('banana');
    ...

    // or delete ALL data in the Object Store
    fruits.clear();
};

There are many more methods and techniques in using IndexedDB. If you would like to learn more, be sure to check out the links under the Resources section at the bottom.

5. Cache API

The Cache API is a new storage mechanism that is designed for storing HTTP responses to specific requests that is also commonly used in conjunction with ServiceWorker.

According to MDN, this API is currently under experimental phase. So, it is not recommended to be used in your serious project for now.

However, as a web developer, it's always good to be aware of new tools that are available at our disposal. You may read about it further by checking out the links below.

🎁 Bonus: Viewing Local Storage Data

As a last tip, while developing your application with local storage, you can always view all the data easily from your browser DevTools.

In Chrome, just press F12 and navigate to Application tab:

You may ignore the Web SQL data store as it is no longer under active development since 2010

From here, you can easily browse through all the data in your local store under the current domain. It is also possible to edit and remove the data manually which makes testing your application very convenient.

🏁 Summary

We have covered all the important local storage options available in most major web browsers.

Each storage methods have different traits that are useful in certain applications. You can always pick the one that best fits your requirements.

🙏 Thank you for reading! I hope you learnt as much as I did. 🚀 If you find this article useful, please share it with your followers. 🦊

📚 Resources

• 🔗 https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
• 🔗 https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API
• 🔗 https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API
• 🔗 https://developer.mozilla.org/en-US/docs/Web/API/Cache
• 🔗 https://javascript.info/data-storage
• 🔗 https://web.dev/storage-for-the-web/#how-much

Prerequisites

It is recommended that you have some basic experience in using JavaScript and have implemented AJAX on a web project.

We will also touch on a few language features in JavaScript such as arrow functions and Promise. If you don't already know it, this article may serve as a good introduction to start using Promise in your next project.

History

JavaScript has come a long way since its inception in 1995. The web back then was largely static, until XMLHttpRequest(XHR) came along around 2002 that really made the web come alive.

However, as with all new technologies, the adoption was slow until John Resig wrote a wrapper around it in his jQuery library back in 2006 which made it easy to implement XHR on any website. That's when AJAX, which stands for "Asynchronous JavaScript and XML", becomes one of the most popular and widely used web technologies even until today.

As the internet progresses, platforms and protocols expand. The limitations and flaws of XHR soon surfaced and it deemed inadequate in many modern use cases.

Introduction

In 2015, the Fetch API was introduced as a much-improved alternative to XHR. It uses some of the modern language features in JavaScripts such as Promise, which provides a much cleaner API and helps avoid callback hell.

In fact, it is so simple that you can make a GET request in a single line of code:

fetch('https://example.com/books')

That's it. In contrast, you will need to call at least three methods on an XHR object just to make a network request. Not to mention the complexity of actually using XHR, such as error handling and multiple event-listeners.

Sure, you could use jQuery and make an AJAX call with a one-liner as well. But that will cost your webpage an extra 70~80kb of traffic and delays just to load the entire jQuery library.

Promise

Let's look at one of the main advantages of using the Fetch API.

Every fetch() request will return a JavaScript Promise object, which is asynchronous by default. This means you could safely and confidently ensure that your code will only run AFTER a response is successfully returned from a network request.

Assuming we are returning some plain text over our fetch request, we can get the result by using .then() after the fetch:

fetch('http://example.com/message')
    .then(response => response.text())
    .then(text => console.log(text))

As you can see, the code is so much simpler and concise compared to using XHR. Also, this is all ready to use in JavaScript without loading any external 3rd party libraries.

Response

The response passed to the .then() function is actually a JavaScript Response object. This means that we could parse a JSON result directly on the Response object without having to read the result first.

Assuming the following request expects a response containing JSON data:

fetch('https://example.com/users/1')
    .then(response => response.json())
    .then(user => console.log(user.name))

The response also contains other useful properties that you can read to check the response statuses. Some of the more common ones include:

a) Response.ok

Return a Boolean true or false to indicate the success of the response. It will return true for 200-299 range statuses, and false otherwise.

b) Response.status

The status code of the response itself. For example, 200, 404, 500 etc.

c) Response.statusText

The status message corresponding to the status code. For example, OK for 200 response.

Here's an example of how to use them:

fetch('https://example.com/users/1')
    .then(response => {
        if (!response.ok && response.statusText != 'OK') {
            if (response.status == 404) {
                console.log('Resource not found!')
            }
        }
    })

Error Handling

To handle any connection error, you simply need to add a .catch() method to the chain:

fetch('https://invalidurl')
    .then(response => response.json())
    ... // other .then()
    .catch((error) => console.log(error))

❗️ Fetch only throws an error when the network request itself fails for some reasons, such as unreachable host or broken connection. A 500 status response(or 200, 400 etc.) is considered a successful request by Fetch, and it should be handled in your response instead.

POST Requests

All the examples we have seen so far are making only GET requests. Even though we have not set any options for our fetch request, it has accomplished quite a few scenarios.

To send a POST request, we need to set a few options to our fetch() function in the second parameter. Let's look at an example of sending some JSON data over POST.

fetch('https://example.com/posts', {
    method: 'POST',
    headers: {
        'Content-type': 'application/json; charset=UTF-8'
    },
    body: JSON.stringify({
        title: 'New Post',
        content: 'Hello world!'
    }),
})
.then((response) => response.json())
.then((json) => console.log(json));

Since the Content-Type header is set to text/plain; charset=UTF-8 by default, you will most likely need to provide one according to the content of your request.

For example, for form data request:

fetch('https://example.com/login', {
    method: 'POST',
    headers: {
      'Content-type': 'application/x-www-form-urlencoded; charset=UTF-8'
    },
    body: 'username=admin&password=secret'
})
.then(response => response.text())
.then(text => console.log(text))

🏁 Conclusion

🎉 That's all you need to know to get started on using Fetch API!

Certainly, there are many more features I have yet to touch on regarding Fetch API. Hopefully, this article will give you a glimpse about the powerful and modern approach towards making AJAX requests using Fetch API compared to XHR. 🚀

To explore further, you may check out the links I shared under the Resources section below.

🙏 Thank you for reading! If you find this article useful, please share it with your followers.

📚 Resources

• 🔗 https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
• 🔗 https://javascript.info/fetch

A Docker container allows you to contain all the necessary development software and environment needs into one complete package for easy distribution.

By using a development container, anyone in your development team will be able to clone and have the exact same setup ready for development with just one command.

In this article, we will walk through the steps in creating a Docker container for Laravel Development that will include an NGINX webserver, PHP with extra extensions, as well as MySQL database.

In addition, we will throw in adminer for easy database management.

🛠 Prerequisites

Docker

You need to install Docker on your machine. If you are new to Docker, I recommend you to download Docker Desktop from the following site:

• 🔗 https://www.docker.com/products/docker-desktop

Git

Make sure your machine has Git installed.

Project Folder

Before we begin, please create a new folder for your project. All files will be created in this folder.

We will call this folder my-project.

1. Clone or setup a Laravel project

Make sure you are in the my-project directory.

~$ cd my-project

Clone an existing Laravel codebase or set up a new Laravel project.

my-project$ git clone https://github.com/laravel/laravel.git laravel

Note that it clones the project files into a folder named laravel.

2. Install Composer

Composer is usually required when developing with Laravel.

Instead of forcing your developers to install Composer globally on their machine, we can use Docker’s composer image to mount the directories that are needed by your Laravel project.

Move into the ./laravel directory and run the command:

my-project$ cd laravel

laravel$ docker run --rm -v $PWD:/app composer install

The -v and --rm flags are used to create a short-lived container that will be bind-mounted to the /laravel directory before being removed. This ensures that the /vendor folder that Composer creates inside the container is copied to your current directory.

3. Customize a new PHP Docker image

To be able to run Laravel and Composer, and to connect with MySQL database, we will need to install a few PHP extensions.

We will refer to the official Laravel's requirements here:

• 🔗 https://laravel.com/docs/8.x#server-requirements

The official Docker PHP image provides only the bare minimum for most PHP applications. Therefore, to fulfil our requirements, we will have to build our own Docker image.

Move back to my-project folder and create a new folder php-fpm:

laravel$ cd ..

my-project$ mkdir php-fpm

Create a new file with the filename Dockerfile inside the new ./php-fpm folder:

# Use the PHP-FPM 7.4 image
FROM php:7.4-fpm

# Install the necessary software and libraries
RUN apt-get update && apt-get install -y \
    libfreetype6-dev \
    libjpeg62-turbo-dev \
    libpng-dev \
    libzip-dev \
    git \
    zip \
    unzip \
    curl

# Install the required PHP extensions
RUN docker-php-ext-install bcmath mysqli pdo_mysql zip
RUN docker-php-ext-configure gd --with-freetype --with-jpeg
RUN docker-php-ext-install -j$(nproc) gd

# Install xdebug
RUN pecl install xdebug \
    && docker-php-ext-enable xdebug

# Install composer
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer

When saving the file, make sure the Dockerfile filename does not contain any file extension like .txt.

4. Setup NGINX site configuration

In order for our Laravel application to be served by NGINX webserver, we need to create an NGINX site .conf file.

In \my-project folder, create a new folder nginx and a subdirectory conf.d within the new folder:

my-project$ mkdir -p nginx/conf.d

The -p flag will allow the creation of subdirectories when the parent directory is not present.

Create a new configuration file site.conf in ./nginx/conf.d directory:

server {
    listen      80;
    server_name localhost;
    root        /var/www/laravel/public;

    add_header  X-Frame-Options "SAMEORIGIN";
    add_header  X-XSS-Protection "1; mode=block";
    add_header  X-Content-Type-Options "nosniff";

    index       index.php;

    charset     utf-8;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    error_page 404 /index.php;

    # pass the PHP scripts to FastCGI server listening on [server]:9000
    location ~ \.php$ {
        fastcgi_pass    app:9000;
        fastcgi_param   SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include         fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

The above configuration is based upon the recommended site configuration by Laravel here:

• 🔗 https://laravel.com/docs/8.x/deployment#nginx

Please note the following:

i) The root /var/www/laravel/public; is where we will store our Laravel application codebase.

ii) fastcgi_pass app:9000; is the Docker network DNS name for the PHP-FPM container, which we will see in the next step.

5. Create a docker-compose.yml configuration

Instead of running each container service one by one, a docker-compose.yml file will define each container image and setup details that can be called by Docker Compose with a single command.

Let's start by defining the services we need. Create a new docker-compose.yml configuration file in /my-project folder:

version: "3.7"

services: 
  web:
    image: nginx:latest
    container_name: webserver

  app:
    build: 
      context: ./php-fpm
      dockerfile: Dockerfile
    image: php-fpm-laravel
    container_name: app
    working_dir: /var/www/laravel

  db:
    image: mysql:8.0
    container_name: db

  adminer:
    image: adminer
    container_name: adminer

Here, we have defined four services in our configuration. As you can guess from the image: field, each service will serve a different purpose.

This is the recommended practice when setting up container services: Each container should do one thing and do it well.

A few things to take note of the configuration settings:

i) Under the app service, we are building a custom PHP Docker image using the build commands in ./php-fpm/Dockerfile defined previously.

ii) container_name is important for containers to identify each other within a Docker network.

iii) The working_dir: /var/www/laravel under app service will be the location where the Laravel application codebase is stored in the container. This is important when we need to execute PHP Artisan & Composer commands in the container later.

6. Mapping Access Port

To access the Laravel app & adminer from our localhost machine, we need to define each port that maps to the web & adminer service container.

i) In the docker-compose.yml file, add the following port configuration under the web service:

...
services: 
  web:
    image: nginx:latest
    container_name: webserver
    ports:
      - "8000:80"
...

This means that we will access our Laravel app via http://localhost:8000

ii) Add the following port configuration under the adminer service:

...
  adminer:
    image: nginx:latest
    container_name: webserver
    ports:
      - "8888:8080"

This will allow us to manage our MySQL database using adminer from http://localhost:8888

7. Set a MySQL Database & Password

Let's set a database and password for MySQL database container.

i) In docker-compose.yml file, add the following environment: configuration under the db service:

...
db:
    image: mysql:8.0
    container_name: db
    environment: 
      MYSQL_DATABASE: laravel
      MYSQL_ROOT_PASSWORD: secret
...

ii) Make a copy of ./laravel/.env.example file and name the new file ./laravel/.env. Then, open the newly copied file ./laravel/.env and edit it with the following MySQL Database information:

...
DB_CONNECTION=mysql
DB_HOST=db
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=root
DB_PASSWORD=secret
...

Note that the DB_HOST=db must be equivalent to the db service container_name: db from docker-compose.yml file.

❗️It's not a good practice to use the root account for database access, but it's acceptable for development purposes in a container deployed on your local machine.

8. Setting up Docker Volumes

At this point, your project directory structure should look like this:

my-project
    \_ laravel
        \_ app
        \_ ...
        \_ public
        \_ vendor
        \_ .env
        \_ ...
    \_ nginx
        \_ conf.d
            \_ site.conf
    \_ php-fpm
        \_ Dockerfile
    \_ docker-compose.yml

Next, we are going to create Docker Volumes for several purposes:

i) First, the Laravel application codebase in our local machine will be mounted to the containers so that any code changes made to our local files will be reflected in the containers without having to reload our containers.

This will speed up the work of your development process.

ii) Second, to mount the NGINX site configuration from Step 4 before that will override the default site configuration in the NGINX container.

This exposes the site configurations to your development team so that everyone understands how the webserver is being setup.

This also allows us to change our site configuration conveniently at any time without having to do it in the container.

iii) Thirdly, to persist the data stored in MySQL Database so that all data created inside the container database is retained even when the containers are being brought down.

This is useful when we need to develop a huge feature that spans several days and needed the data to persists for development continuation purposes.

Here's the complete docker-compose.yml configuration after adding the volume mounts for each container:

version: "3.7"

services: 
  web:
    image: nginx:latest
    container_name: webserver
    ports:
      - "8000:80"
    volumes: 
      - ./laravel:/var/www/laravel
      - ./nginx/conf.d/:/etc/nginx/conf.d/

  app:
    build: 
      context: ./php-fpm
      dockerfile: Dockerfile
    image: php-fpm-laravel
    container_name: app
    working_dir: /var/www/laravel
    volumes: 
      - ./laravel:/var/www/laravel

  db:
    image: mysql:8.0
    container_name: db
    environment: 
      MYSQL_DATABASE: laravel
      MYSQL_ROOT_PASSWORD: secret
    volumes:
      - laravel-mysql-data:/var/lib/mysql

  adminer:
    image: adminer
    container_name: adminer
    restart: always
    ports:
      - "8888:8080"

volumes: 
  laravel-mysql-data:

Note the last line laravel-mysql-data: is where the database data will be stored persistently in a Docker volume.

9. Run Docker Compose

All the necessary files and configuration is in place. Now let's spin up our containers using Docker Compose.

Make sure you are in the my-project directory where the docker-compose.yml file is located and run the following command:

my-project$ docker-compose up -d

The -d flag is to instruct Docker to run the containers in detached mode.

Please be patient as the build process will take some time to complete. Once it's completed, you will see the following response in your terminal:

Creating webserver ... done
Creating db        ... done
Creating adminer   ... done
Creating app       ... done
my-project$

If you have installed Docker Desktop, open the Dashboard to view your new containers:

10. Execute PHP Artisan & Composer commands

Normally, you do not include the .env file and ./vendor/ folder in your code repository. Therefore, you need to include in your repository README file with the following instructions for your development team on how to run php artisan & composer commands in the containers.

So, before we can access the Laravel application from the browser, we need to run a few commands to set up the necessary data required by Laravel.

i) First, let's generate the application encryption key:

$ docker exec app php artisan key:generate

Let's break down the command:

• docker exec: the Docker command to execute commands in a container
• app: the service container_name defined previously in docker-compose.yml file
• php artisan key:generate: the actual command you intended to run in the container

You will see Application key set successfully. returned for the above successful command.

ii) Next, let's install all composer's dependencies:

$ docker exec app composer install

iii) To clean up composer cache:

$ docker exec app composer dump-autoload

Now, you can access your application via http://localhost:8000 on a web browser where you will see your Laravel application being loaded.

11. (Optional) Database migration and adminer access

Next, I'll show you how to install new composer dependencies, run database migration, and view them in adminer.

Let's assume your application needs to use the Laravel Passport to handle authentication. You can install the dependencies with the following command:

$ docker exec app composer require laravel/passport

To create the tables necessary for Laravel Passport, you may run the following command:

$ docker exec app php artisan migrate

And lastly, to create the encryption keys needed to generate secure access tokens in Laravel Passport:

$ docker exec app php artisan passport:install

Now, let's inspect the tables and data in MySQL database via adminer by going to http://localhost:8888/ using your web browser:

Login with the following credentials:

• Server: db
• Username: root
• Password: secret
• Database: laravel

You should see the tables and their data created from the migration and installation processes earlier:

12. Shutting down containers

Finally, we can shut down our containers once we are done working on our project.

$ docker-compose down

You will see the following response messages in your terminal after the process has completed:

Stopping webserver ... done
Stopping app       ... done
Stopping adminer   ... done
Stopping db        ... done
Removing webserver ... done
Removing app       ... done
Removing adminer   ... done
Removing db        ... done
Removing network my-project_default
my-project$

Alternatively, take a look at the Docker Desktop Dashboard. You will find that your project containers are gone from the list.

🏁 Summary

🎉 That's all for today! We have come to an end to the walkthrough of setting up a Laravel Development Container using Docker.

With this method, we can say goodbye to setting up a different development environment manually on your machine for every project. Your development team will no longer have to spend the whole day setting up their machine before they can start working on the project. Not to mention having to make sure all software and environments must match the project system requirements.

Hopefully, by learning how to use containers as a development environment, you will no longer hear your developers saying "It works on my machine!". 😉

🙏 Thank you for reading! If you find this article useful, please share it with your followers.

💬 If you have any questions, feel free to leave a comment below.

📚 References

• https://www.docker.com/101-tutorial
• https://www.digitalocean.com/community/tutorials/how-to-set-up-laravel-nginx-and-mysql-with-docker-compose
• https://hub.docker.com/_/composer
• https://hub.docker.com/_/php
• https://laravel.com/docs/8.x/installation#server-requirements
• https://laravel.com/docs/8.x/deployment#nginx

• 🎖 https://www.youracclaim.com/badges/00afda49-dfd8-45e1-bdd7-dec12965f2b1

In this article, I would like to share some tips as well as the methods & FREE resources that I have used to study for the AWS Cloud Practitioner exam and passed.

This is the first IT certification that I have taken ever since I graduated from University almost a decade ago. Hence, if you have never taken any certification or exam, you may be able to relate to my experience here.

❗️Do keep in mind that your mileage may vary. What works for me may not work for you.

❗️Disclaimer: I have no affiliation with all the links that I shared in this article.

Prerequisite

A) Technical Background

I need to clarify that I did not learn from scratch. I was (un)fortunate enough to be involved in a past client e-Commerce project that needed to be deployed on AWS infrastructure. However, only minimal efforts were carried out in that one-time experience.

It is also due to that experience of not knowing how to work on cloud correctly that led me to discover about AWS Certification paths.

Although having a technical background does help, but there aren't really any background requirements in getting started with AWS.

B) Exam Requirements

This exam is entirely optional. In fact, you could skip this and go straight for the AWS Certified Solutions Architect Associate exam.

However, it's highly recommended that you take the Cloud Practitioner exam first, mainly for two valid reasons:

1. If you have minimal or no experience in using AWS Cloud services, it is good to familiarise yourself not only with AWS and general cloud computing concept before diving into a much deeper area, but also with how the exam works and the mechanism of the exams. The latter is important if you have been out of school for a very long time, or have never taken any exams before.

2. The cost for the Cloud Practitioner exam is $100 USD, while the cost for Solutions Architect Associate exam is $150 USD. BUT, whenever you passed ANY exams on AWS, you will be given a 50% voucher for your next exam as part of the certification benefits!

If you do the math, taking both exams will cost you $100 + $75(50%) = $175 USD. But taking only the Solutions Architect Associate exam will already costing you $150 USD. Might as well spend another +$25 to get both certificates. ¯_(ツ)_/¯

C) Physical Notebook for Note Taking

Call me old-fashioned, but a physical notebook still works best for me when it comes to note-taking. The act of writing down actually reinforces the knowledge that you learned.

D) Register For a FREE-tier AWS Console Account

Nothing beats doing when it comes to learning. Please register for a FREE-tier account on AWS so that you can experiment with the AWS Console throughout your learning.

• 🔗 https://console.aws.amazon.com/

It will cost you nothing in the first year if you are just experimenting.

1. Official Exam Guide

Before you start studying, you need to know the scope of the exam. AWS provides a clear but slightly vague Exam Guide for anyone who planned to take the exam.

• 📄 https://d1.awsstatic.com/training-and-certification/docs-cloud-practitioner/AWS-Certified-Cloud-Practitioner_Exam-Guide.pdf

Read through it but you don't have to know everything that's mentioned in the guide. You will come back to this guide when you are ready to register for the exam again.

The only thing that's not mentioned in the Exam Guide is that there are 65 questions in the exam. Since they did not mention it in the guide, it means that this could change in the future.

2. Official Digital Classroom Lesson

Sign up for an account on https://aws.training and enrol yourself in this free Digital Training course:

• 🔗 https://www.aws.training/Details/eLearning?id=60697

This AWS Cloud Practitioner Essentials course has been updated recently and I found it to be very high quality. According to the course description, this course also helps you prepare for the AWS Certified Cloud Practitioner exam.

The format of the training consists of instructor-led video lessons, text summaries, and an interactive section for knowledge check at the end of each lesson. It is definitely a good starting place to begin your cloud exploration.

This is where I began taking note of key concepts and important learning points in my notebook as well.

After completing this course, you should have a good overview of AWS.

3. freeCodeCamp.org / ExamPro

Watch this video:

• ▶️ https://www.youtube.com/watch?v=3hLmDS179YE

This 4-hour video is a must-watch for anyone planning to take and pass the Cloud Practitioner exam. It is a complete course presented by the amazing Andrew Brown(https://twitter.com/andrewbrown) from ExamPro for FREE.

The video is very concise and packed with all the knowledge you need in passing the exam. It covers the essentials as well as provides hands-on practices on key services. Furthermore, all services are introduced and similar services are carefully compared to make sure you do not confuse with them.

After all, there are more than 140+ services offered by AWS. Therefore, it is crucial that you know what each of them does and the difference from each other.

Pace yourself and do make sure that you continue to do note-taking, or best if you could draw out mindmaps to aid in your understanding and revision later.

4. Whitepapers and Documentations

Here comes the "boring" but one of the most important parts of your study.

a) Please download and read the following Whitepapers from AWS:

• 📄 https://d1.awsstatic.com/whitepapers/aws-overview.pdf
• 📄 http://d1.awsstatic.com/whitepapers/aws_pricing_overview.pdf

b) Please make sure you know by heart on the following topic as well:

• 🔗 https://aws.amazon.com/premiumsupport/plans/

The videos might be great as an introductory to AWS & Cloud Computing concepts in general. However, to really learn about the details, this is where you need to dive a little deeper to make sure you get all the specifics right.

Not to mention AWS is constantly evolving, so the videos might miss out some of the latest updates that have been introduced recently.

It is recommended to write a short one-sentence summary in your own words of every single AWS service from the whitepaper in your notebook. This has helped me in making sure I understand what each service do, and to provide a go-to reference point whenever you want to revise on them.

In addition to the whitepapers, you will most likely need to Google to lookup on some key concepts that you want to clarify further. More often than not, you will always land on none other than the AWS Official Documentation page for a particular service itself.

This is where you need to familiarise yourself on navigating and reading the official documentation. I believe you will be depending on the information in the official documentation regularly throughout your cloud journey.

5. AWS Online Conferences & Events

Keep an eye on any online conference organized by AWS. They do not happen often, but I take it as a good medium to break out from reading the whitepapers.

For example, here's the upcoming AWS re:Invent FREE Virtual Conference that you can sign up and watch:

• 🔗 https://reinvent.awsevents.com/index.html

The conferences are usually FREE and presented by AWS technical experts. In the conference, AWS technical experts will explain key features and use cases, share best practices, and walk through technical demos.

Depending on the event, if you managed to attend the sessions live, they might be available to answer your questions one-on-one.

6. Practice Exam Questions

In most Asian education culture, exams are everything. Students are trained to perform well in exams. The best way to excel in your exam is to practise on the exam questions itself.

Therefore, try to search for any FREE practice exam questions you could find on the internet. Many websites actually have exam questions dump with answers from various sources.

a) Here are a few that I've used:

• 🔗 https://free-braindumps.com/amazon/free-aws-certified-cloud-practitioner-braindumps.html
• 🔗 https://www.itexams.com/exam/AWS%20Certified%20Cloud%20Practitioner

b) Not tried, but seems to be good quality:

• 🔗 https://www.awsboy.com/aws-practice-exams/practitioner/
• 🔗 https://awslagi.com/practice-questions/

c) From official AWS:

GOOD News! As part of the Get AWS Certified Global Challenge, AWS is giving out FREE practice exam voucher to anyone who signs up for the challenge. You may request for a practice exam voucher here:

• 🔗 https://pages.awscloud.com/AWS-Global-Certification-Challenge-Practice-Exam-Request.html

❗️Offer is valid until 31st December 2020, so make sure you take action immediately.

Again, I cannot stress enough how important is it to practise on exam questions. If you are facing time constraints, this is the only area you should put your effort in to increase your chances in passing the exam.

As soon as you start doing exam questions, you will quickly realise there are still many details in your learnings that you may have missed out. You will also discover common gotchas and edge scenarios that you have never considered before.

For every question that you answered wrongly, please Google about it and make sure you understand the correct answer and why the mistake was made. Read the official documentation if you need to, as it is the source of truth.

7. Cheat Sheet

Once you have done all the above, it is time for a final round of revision before you take the exam.

Your notebook that you have been taking notes with should now be served as a revision guide before you sit for the exam.

In addition, you should also review some of the cheat sheets out there to make sure you have absolutely covered everything that is required to know to pass the exam.

• 🔗 https://digitalcloud.training/certification-training/aws-certified-cloud-practitioner/

Lastly, it is also a good time to take a look at the Cloud Practitioner Exam Guide again, to make sure you have covered all topics.

🎁 Extras

Looking For Help

No doubt you will have questions during your studies. If you can't find the answer you need everywhere, you may need to ask someone who has the answer.

For this purpose, you may ask for help from the cloud community on A CLOUD GURU forum:

• 🔗 https://acloud.guru/forums

Very likely, any question that you might have has already been asked and answered by someone else. You just need to search in the forum using the right keyword. If not, just sign up for an account and post your questions there.

Scheduling And Taking The Exam

At this point, you should be confident enough to schedule a date for the exam.

❗️Due to COVID-19 restrictions around the world, AWS allows all exams to be taken through online proctored from your home or office, without having to take them at an exam centre. If you choose so, please be certain of the rules that you need to adhere to.

For your information, I chose to take my exam from home via online proctored managed by PearsonVUE using their OnVUE application which they provided for candidates. I used an Apple MacBook Pro with working webcam & microphone while connected to my home WiFi fibre internet connection to complete the test.

On your exam day, make sure you are well rested the night before and try not to drink too much fluid, as breaks are not allowed throughout the 90 minutes exam session.

While answering the questions, you may not scribble on any notes or paper. However, it is possible to flag a question and return to it at a later time.

Do not spend too much time on a single question. If you get stuck and do not know the answer, select the most likely answer or take a guess, flag it, and move on to the next question.

If you are lucky, another question further down might give you a hint or the answer right out to the previous question that you had trouble figuring out before. The point here is that you should try your best to answer ALL 65 questions. It is not worth to leave any unanswered question.

In my exam, I spent a total of 65 minutes before ending my exam session. During which I had around 10 questions flagged, and managed to review all the questions once more after completing them the first round.

You will know if you have passed or failed immediately upon ending your exam. However, you will only receive the official certification within 5 business days.

🏁 Conclusion

That's all I have to share about my experience in preparing and passing the AWS Certified Cloud Practitioner exam.

🙏 Thank you for reading and best of luck in your exam! 🍀 I hope my experience will help you succeed in getting your AWS Certified Cloud Practitioner certification and beyond. 🚀☁️

📚 Resources

• https://aws.amazon.com/certification/certification-prep/
• https://pages.awscloud.com/takethechallenge.html (due date 31 December 2020)
• https://www.aws.training/
• https://www.youtube.com/watch?v=3hLmDS179YE
• https://aws.amazon.com/events/
• https://free-braindumps.com/amazon/free-aws-certified-cloud-practitioner-braindumps.html
• https://www.itexams.com/exam/AWS%20Certified%20Cloud%20Practitioner
• https://www.awsboy.com/aws-practice-exams/practitioner/
• https://awslagi.com/practice-questions/
• https://digitalcloud.training/certification-training/aws-certified-cloud-practitioner/
• https://acloud.guru/forums
• https://home.pearsonvue.com/Clients/Amazon-Web-Services/Online-Proctored.aspx

Dynamic DNS is also useful if you are testing some 3rd party callback services such as Payment Gateway and requiring a response endpoint but you are still developing the app on your localhost and have not registered for a domain name yet.

The issue with your home or office internet is that you are usually provided with a dynamic IP address by your internet service provider(ISP) that can change anytime. Thus, it is not practical to provide this IP address to your client when they ask to check your work progress, or to use it as a 3rd party service callback response endpoint during development.

🌐 What is Dynamic DNS?

The above issue can be solved by setting up a Dynamic DNS on your router.

Dynamic DNS allows you to assign a fixed domain name to a dynamic IP address. Even when the dynamic IP address assigned to you changes, the Dynamic DNS service will automatically update the Domain Name Server(DNS) to point to your new IP address.

❗️ However, do note that it is NOT advisable to use Dynamic DNS for any production system or live website. Not only this may violate the terms with your ISP, but your home internet connection may not have adequate uploading bandwidth to handle the incoming traffic. Not to mention your computer may not be powerful enough to handle high volume of requests as well.

🖇 Prerequisite

Router Access

Most modern routers come with Dynamic DNS feature built-in. But you do need to have the administrator access to your router in order to configure it.

In this guide, I will use a TP-LINK Wireless Router Archer C1200 model as an example. But rest assured that most routers have similar settings and keywords, and guides for specific router models can be easily found on the internet elsewhere.

I have put up some links to a few popular router brands and their DDNS guide under the Reference section at the bottom.

Step 1: Configure Dynamic DNS On Your Router

a) Find out your router IP address. Usually, it can be accessed by going to http://192.168.0.1 via your web browser.

If not, you may locate from your computer's Network settings. On macOS, navigate to System Preferences > Network > WiFi or the connected Internet connection > click on the Advanced... button > click on the TCP/IP tab > look for the Router value:

❗️ Please note down the IPv4 Address as well, as we will need this value later on.

b) Enter the Router IP address to your web browser location and you should arrive at a login page for your router. Login to your router configuration panel with a username and password. For TP-LINK, the default credentials are admin/admin.

c) Once logged in, navigate to Advanced > Network > Dynamic DNS:

Select "NO-IP" and click on "Go to register..." link to register a FREE NO-IP account.

d) On the noip.com page, enter a Hostname and select a domain name from the drop-down list.

Click on the Sign Up button once you have made your selection.

e) Complete the Free Sign Up form on the next page. You will most likely need to confirm your email address to activate your free account.

❗️ Do note that your Free Domain Name will expire in 30 days.

f) Return to your Router Dynamic DNS configuration page and enter your noip.com account details and the full Domain Name:

g) Click on the Login and Save button to save your settings. At this point, your router will attempt to connect to the NO-IP DDNS service with your account details.

You will see a "Success!" message if it's successful:

Step 2: Add Port Forwarding to HTTP

To allow incoming requests from the internet to your local network via HTTP, you need to enable Port Forwarding on your router, so that your router will pass on all HTTP traffic to your local computer correctly.

You may visit https://portforward.com/ to look for a suitable guide specific to your Router brand and model.

a) On your Router configuration page, navigate to Advanced > NAT Forwarding > Virtual Servers.

b) Click on "Add" to add a new entry:

• Service Type: Enter "HTTP" or click on the "View Existing Services" and search for HTTP.
• External Port: 80
• Internal IP: 192.168.0.126 (Your local computer IPv4 Address, from Step 1 a) above)
• Internal Port: 80
• Protocol: TCP
• Check Enable This Entry

c) Click OK to save the entry. You should have a new entry as such:

Step 3: Add Domain Name to Webserver

In order for the domain name to reach your website, you will need to inform your localhost Webserver on the new domain name.

a) For NGINX webserver, locate your site configuration file and add the domain name to the server_name directive:

server {
    listen 80;
    server_name localhost mysuperapp.ddns.net;
    root /var/www/html;

    ...
}

Save and reload NGINX to load the changes:

$ sudo nginx -s reload

b) For Apache webserver, locate your site or virtual host configuration file and add the domain name to the ServerAlias directive:

<VirtualHost *:80>
    ServerName localhost
    ServerAlias mysuperapp.ddns.net

    ...
</VirtualHost>

Save and restart Apache:

$ sudo apachectl -k restart

Step 4: Add Domain Name to Hosts File

In order for the Domain Name to reach your computer, you need to add the Domain Name to the collection of hosts in your computer hosts file.

a) On macOS and most Linux OS, that file can be located in /etc/hosts. You will require administrative privilege to edit the file:

$ sudo vim /etc/hosts

b) On Windows, the hosts file can be located in C:\Windows\System32\drivers\etc\hosts.

c) DO NOT remove any entries in this file. Instead, just add a new entry with a new line at the end of the file:

127.0.0.1            localhost
...
192.168.0.126        mysuperapp.ddns.net

The format should be: [your computer IPv4 Address] [domain name], where IPv4 Address value can be found in the Network settings in Step 1 a) above.

d) Save the file.

Step 5: Allow Incoming Connections on Firewall

Depending on your Operating System, you may need to configure your Firewall to allow incoming connections to your Webserver.

a) On macOS, navigate to System Preferences > Security & Privacy > Firewall > Firewall Options > Add New entry for your Webserver(e.g. NGINX or Apache) > Set it to "Allow incoming connections":

b) Click Ok to save the new Firewall entry.

🏁 Complete

🎉 That's it!

Now you can access your localhost website by using a FREE Domain Name. 🙌

You may verify the public access to your localhost website by using another internet connection such as your mobile data network. Enter the domain name into your web browser to load and view your localhost website.

You may now share this domain name to your client for them to access it from their end, or use this domain name as an endpoint to any 3rd party response callback service that you are testing.

❗️ Thank you for reading! I hope you learnt something new today. If you find this useful, feel free to share it with your followers. 🦊

📚 Reference

Dynamic DNS Configuration for major Router brands:

• TP-LINK: https://www.tp-link.com/us/support/faq/1367/
• D-Link: https://eu.dlink.com/uk/en/support/faq/cameras-and-surveillance/mydlink/settings/router/how-do-i-configure-dynamic-dns-on-my-dir-series-router
• NETGEAR: https://kb.netgear.com/23860/How-do-I-set-up-a-NETGEAR-Dynamic-DNS-account-on-my-NETGEAR-Nighthawk-router
• Cisco-Linksys: https://www.linksys.com/us/support-article?articleNum=142585

Port Forwarding Configuration for most major Router brands:

• https://portforward.com/

This guide is suitable for anyone who is new to AWS and would like to try it out without having to provision any servers or database.

☁️ Introduction

Static Site

A static site is just like any regular website. In fact, it is what web pages supposed to be like in its most fundamental form since the beginning of the web.

As the name implies, a static site has no dynamic component. A static site is usually made up of plain HTML files, CSS stylesheets, images, as well as Javascript files. It has no capabilities to perform any dynamic request or backend processing, such as processing form data or retrieving information from the database.

Amazon S3

Amazon S3 is an Object Storage service that provides virtually unlimited storage for all your file storage needs. As an added feature, you can configure a storage pool(called a "bucket") to host and serve a static site to the internet.

Amazon CloudFront

Amazon CloudFront is a global CDN(Content Delivery Network) service that caches and serves files & data to anyone globally very quickly and under low latency.

The idea of a CDN is to distribute commonly accessed files to edge servers around the world for quicker access by users near to the edge servers location. A shorter distance means that requests are being fulfilled faster. Hence, this increases the overall performance and less waiting time for the users.

Since static website contents are made up of static files that don't usually change much, the above two AWS services are perfect for setting up a high-performance static website at a very low overhead in terms of cost and technical requirements.

🖇 Prerequisite

To get started, you will need the following:

1. An account with AWS
2. The files for your static website
3. A domain name(optional)

You can sign up for an AWS account for free. However, to be eligible for AWS FREE Tier, there are few criteria to take note of:

• Your AWS account has to be less than 12 months old
• Your static website files have to be less than 5 GB in total, and less than 2,000 files (Amazon S3)
• Monthly bandwidth not exceeding 50 GB and 2,000,000 HTTP/S requests. (Amazon CloudFront)

Otherwise, you will be charged for the service used on your account.

Step 1 - Creating a Bucket on Amazon S3

a) After logging in to your AWS Console, under Services > All Services, search for "S3" and click on it to go to the S3 dashboard.

b) On the S3 Dashboard, click on the Create Bucket button to create a new storage bucket to store your website files.

c) Enter a bucket name. The name has to be globally unique, so just try another one if you get an error "Bucket with the same name already exists".

❗️ The Region does not matter much as we will be using Amazon CloudFront to distribute the files globally later.

d) Since we want to allow anyone to view our website, clear the checkbox for Block all public access, and make sure to check the I acknowledge... statement checkbox below it.

e) Leave all other settings intact and click on the Create bucket button at the bottom of the page.

Step 2 - Upload Website Files to S3 Bucket

a) After creating a new bucket, click on the bucket name to view the bucket details.

b) Scroll to the bottom of the page. You should see that there aren't any objects(files) in the new bucket. Click on the Upload button to upload some files.

c) On the File Upload page, click on the Add files to add a file from your computer, or Add folder to add multiple files from a folder.

As you can see from the screenshot above, I've added some HTML & CSS files, as well as few images in a folder, and a Javascript file.

Make sure you have added all the necessary files for your static website.

d) Leave all other settings intact, scroll to the bottom of the page and click on the Upload button to start the uploading of the files you have added above.

e) Depending on your connection and the number of files, you will have to wait while the files are being uploaded to the S3 Bucket:

f) Once the uploading process has completed, you may check if each file has been uploaded successfully or if there are any errors. Otherwise, just click on the Exit button to return to the Bucket details screen.

Step 3 - Enabling Static Website Hosting on S3 Bucket

a) On the Bucket overview page, click on the Properties tab and scroll down.

b) Look for Static website hosting section and click on the Edit button.

c) Select Enable option for Static website hosting setting and you will be presented with more options as the following screenshot:

• Hosting type: Select Host a static website

• Enter the Index document file name(case-sensitive) that will serve as the home page for your static website. This is usually "index.html" by convention.

• Enter the Error document that will be shown when an error occurs. E.g. "error.html", "404.html" etc.

d) Scroll to the bottom of the page and click on the Save changes button.

Step 4 - Unblock Public Access Settings

a) On the Amazon S3 page, click on Account settings for Block Public Access from the left menu.

b) Click on the Edit button.

c) Clear the checkbox for Block all public access, and click on the Save changes button.

d) When you're asked to confirm your action, enter "confirm" and click on the Confirm button to save your changes.

Step 5 - Add a Bucket Policy

Before anyone could access the website on the bucket, we need to explicitly tell S3 Bucket to allow that.

a) On the Bucket overview page, click on the Permissions tab, scroll down and look for Bucket policy section.

b) On the Bucket policy section, click on the Edit button.

c) To grant public read access for your website on this bucket, copy the following bucket policy, and paste it in the Bucket policy editor below. For the "Resource", modify the my-static-website to your bucket name.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::my-static-website/*"
            ]
        }
    ]
}

❗️ You must change the my-static-website to your bucket name.

d) Click on the Save changes button when you are done.

e) You should now be able to access your website via the Amazon S3 Endpoint on the internet.

• Return to the Bucket overview page
• Click on the Properties tab
• Scroll to the bottom and look for Static website hosting section
• You can find the URL under Bucket website endpoint. Click on it to view your website.

You have completed all the necessary steps for Amazon S3.

Step 6 - Creating a CloudFront Distribution

a) From the top navigation under Services > All Services, search for "CloudFront" and click on it.

b) On the CloudFront Distributions page, click on the Create Distribution button.

c) Choose Web distribution delivery method and click on Get Started.

d) On the Create Distribution page > under Origin Settings section > for Origin Domain Name > enter the Amazon S3 website endpoint from Step 5 e) earlier. Example: my-static-website.s3-website-us-east-1.amazonaws.com (You could also choose from the drop-down list if available)

The Origin ID should be automatically filled up for you. Leave other settings to the default under this section.

e) Leave other settings under Default Cache Behavior Settings section to the default.

f) Under Distribution Settings section > for Alternate Domain Names (CNAMEs), you may insert your own domain name if you have one.

According to AWS, You must list any custom domain names (for example, www.example.com) that you use in addition to the CloudFront domain name (for example, d1234.cloudfront.net) for the URLs for your files. Specify up to 100 CNAMEs separated with commas or put each on a new line. You also must create a CNAME record with your DNS service to route queries for www.example.com to d1234.cloudfront.net. For more information, see the Help.

g) If you wish to use a custom domain name, you must also provide an SSL Certificate for that domain under the next setting via AWS Certificate Manager(ACM) service.

❗️ Creating a public certificate from Amazon is free of charge. However, this guide will not cover that part.

Otherwise, select Default CloudFront Certificate (*.cloudfront.net) for the SSL Certificate setting.

h) Enter "index.html" for Default Root Object. This file name must match with the Index document file name entered in Step 3 c) previously on S3.

i) Leave other settings intact. Scroll to the bottom and click on the Create Distribution button.

j) As you remember from earlier, CloudFront will now distribute all your files to edge servers around the world. This process will take some time to complete.

k) Once Status has updated to Deployed, the distribution is ready to be accessed.

l) The URL for the distribution can be found under the Domain Name column. For example: stuvwxyz6789.cloudfront.net. Hopefully, you will see your static website by accessing this URL on your web browser.

❗️ If you have configured to use a custom domain name in Step 6 f), you should be able to access your static website via the custom domain name instead.

🏁 Conclusion

🎉 Congratulations! 🎊

You have successfully setup a high performance and highly available static website on AWS using Amazon S3 and Amazon CloudFront. All these without setting up a single server too! 👏

If you are using a new AWS account, this will most likely cost you nothing as well.

In case you are worried about exceeding the FREE Tier usage, I'll share my usage cost over a three month period.

As you can see, there's not much traffic to my site. Therefore, the daily cost hardly exceeds the FREE Tier. Even when it did, the cost came to only a cent at most.

❗️ Thank you for reading! I hope you learnt something new today. If you find this useful, feel free to share it with your followers. 🦊

📚 References

• https://aws.amazon.com/free/
• https://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html

Usually, the case is most likely caused by caching applied by the Laravel framework.

Here are some of the common commands you can run in your terminal to alleviate the issue.

❗️ Make sure you are running them in the context of your application. Meaning, your terminal is currently in the same directory as your Laravel application.

1. Configuration Cache

Caching configuration helps with combining all of the configuration options for your application into a single file which will be loaded quickly by the framework.

Clearing Configuration Cache

However, if you notice changes to the configuration values in .env file is not reflecting on your application, you may want to consider clearing the configuration cache with the following command:

$ php artisan config:clear
Configuration cache cleared!

If you want to quickly reset your configuration cache after clearing them, you may instead run the following command:

$ php artisan config:cache
Configuration cache cleared!
Configuration cached successfully!

Caching your configuration will also help clear the current configuration cache. So it helps save your time without having to run both commands.

2. Route Caching

Caching your routes will drastically decrease the amount of time it takes to register all of your application's routes. When you add a new route, you will have to clear your route cache for the new route to take effect.

Clearing Route Cache

The following command will clear all route cache in your application:

$ php artisan route:clear
Route cache cleared!

To cache your routes again, simply run the following command:

$ php artisan route:cache
Route cache cleared!
Routes cached successfully!

Again, running the above command alone is enough to clear your previous route cache and rebuild a new one.

3. Views Caching

Views are cached into compiled views to increase performance when a request is made. By default, Laravel will determine if the uncompiled view has been modified more recently than the compiled view, before deciding if it should recompile the view.

Clearing View Cache

However, if for some reason your views are not reflecting recent changes, you may run the following command to clear all compiled views cache:

$ php artisan view:clear
Compiled views cleared!

In addition, Laravel also provides an Artisan command to precompile all of the views utilized by your application. Similarly, the command also clears the view cache before recompiling a new set of views:

$ php artisan view:cache
Compiled views cleared!
Blade templates cached successfully!

4. Events Cache

If you are using Events in your Laravel application, it is recommended to cache your Events, as you likely do not want the framework to scan all of your listeners on every request.

Clearing Events Cache

When you want to clear your cached Events, you may run the following Artisan command:

$ php artisan event:clear
Cached events cleared!

Likewise, caching your Events also clear any existing cache in the framework before a new cache is rebuilt:

$ php artisan event:cache
Cached events cleared!
Events cached successfully!

5. Application Cache

Using Laravel's Cache is a great way to speed up frequently accessed data in your application. While developing your application involving cache, it is important to know how to flush all cache correctly to test if your cache is working properly.

Clearing Application Cache

To clear your application cache, you may run the following Artisan command:

$ php artisan cache:clear
Application cache cleared!

This will clear all the cache data in storage which are typically stored in /storage/framework/cache/data/. The effect is similar to calling the Cache::flush(); Facade method via code.

❗️ This command will NOT clear any config, route, or view cache, which are stored in /bootstrap/cache/ directory.

6. Clearing All Cache

Laravel provides a handy Artisan command that helps clear ALL the above caches that we have covered above. It is a convenient way to reset all cache in your application, without having to run multiple commands introduced before.

To clear all Laravel's cache, just run the following command:

$ php artisan optimize:clear
Compiled views cleared!
Application cache cleared!
Route cache cleared!
Configuration cache cleared!
Compiled services and packages files removed!
Caches cleared successfully!

As you can read from the terminal feedback, all cache types that existed in your Laravel application will be cleared entirely, except Events cache.

❗️ The Compiled services and packages files removed! can be run individually via $ php artisan clear-compiled command. It is used to remove the compiled class file in the framework.

🎁 Bonus

If the above Laravel's Artisan commands don't seem to resolve the issue you are facing, you may need to look at other related environments in your project that may be causing it.

When building a Laravel project, it is common to employ the Composer Dependency Manager for PHP, as well as NPM for any JavaScript library that might be needed in your project. We just have to take note that both package managers are using some form of caching for performance improvements.

Clearing Composer Cache

Sometimes, a new package you just installed via Composer doesn't appear to be working at all. Or a new project you just cloned from a repository doesn't seem to be running correctly.

Such issues are usually caused by classmap error from a newly installed library class, or the cached version of a particular library does not match with the ones required by the project codebase you just cloned. In such a situation, you need to update the PHP autoloader by running the following command:

$ composer dump-autoload

As well as any of the following variations(they all achieve the same purpose of deleting all content from Composer's cache directories):

$ composer clear-cache
$ composer clearcache
$ composer cc

Clearing NPM Cache

To clear NPM cache:

$ npm cache clean --force

🏁 Summary

That's all you need to know about Laravel's Artisan cache related commands, as well as few additional commands for Composer and NPM, which you most likely will be using together in a Laravel project.

Here's a final command before we end the article:

$ php artisan list

The above command will list down all available Artisan commands when executed. I recommend you to take a look at it, as you might find something new that will be useful to you!

❗️ Thank you for reading! If you find this useful, feel free to share it with your followers. 🦊

📚 References

• https://laravel.com/docs/6.x/configuration#configuration-caching
• https://laravel.com/docs/8.x/controllers#route-caching
• https://laravel.com/docs/8.x/views#optimizing-views
• https://laravel.com/docs/8.x/events#event-discovery
• https://laravel.com/docs/8.x/cache#removing-items-from-the-cache
• https://getcomposer.org/doc/03-cli.md#dump-autoload-dumpautoload-
• https://getcomposer.org/doc/03-cli.md#clear-cache-clearcache-cc
• https://docs.npmjs.com/cli/v6/commands/npm-cache

This guide assumes that you have some experience in setting up a web server, understand the purpose of URL rewrites, and basic knowledge of regular expression (RegEx). We will go over all the options available when using the location directive, as well as some practical examples to highlight common use cases.

You may scroll to the bottom for a quick TL;DR summary. 📘

📬 The location block

One of the most widely used configuration modules within NGINX is the location block. It is responsible for matching the Request URI and to subsequently passes it on to the correct block for further processing.

The location directive only concern about the path after the domain name and before any query strings. For example, if we have the following URL:

https://www.example.com/user/posts?post_id=45#top

The location directive will only use the path /user/posts to perform any matching.

1. Match any URLs

Let's start with a common example that you have likely encountered in many default configurations and tutorials elsewhere:

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

The above rule will match with any URLs, and try to serve them. For example, it will match with https://www.example.com/homepage.html and try to serve the page if it exists. Otherwise, it will return a 404 not found response.

Just to be clear, the / after location is not a special symbol. It is actually telling NGINX to match with any URIs that begins with /, which literally means to match with any URLs since that's the first character after a domain name.

This specific rule usually serves as a fallback that matches last when all other location blocks failed to match.

❗️ Please note that the keyword here is begins. NGINX will always match from the beginning of a URI no matter which rule is being applied.

2. Match exact URL

Sometimes, we would like to match an exact URL for NGINX to process separately. For example, redirecting legacy links after a migration or a marketing landing page such as https://www.example.com/deals.

To do that, the location directive offers us a handy = modifier to be used as such:

location = /deals {
    return 301 https://$host/marketing/deal/2020;
}

With the = modifier set, NGINX will only redirect to https://example.com/marketing/deal/2020 if the request URL is exactly https://example.com/deals.

❗️ It is possible to achieve the same outcome with location = deals { ... } but it's better to express your intent in a clear manner.

3. Matching URL prefix

Continuing on with the example before, what if the = modifier was not set?

location /deals {
    return 301 https://$host/marketing/deal/2020;
}

In such configuration, NGINX will redirect to https://example.com/marketing/deal/2020 as long as the URL begins with /deals. The following URLs will be considered a match:

• https://example.com/deals
• https://example.com/deals/today
• https://example.com/deals/today/12
• https://example.com/dealsoftheday
• https://example.com/dealsoftheday/latest
• https://example.com/dealsoftheday/latest?deal_id=12

A prefix match is more useful when you have a dynamic page that you want to serve via preprocessing engine such as PHP:

location /post {
    rewrite ^/post/(.*)$ /post.php?post_id=$1;
}

With that in place, the post.php page can be accessed from the URL https://example.com/post/23 where the value 23 will be used as the post_id variable for PHP to serve the correct post content.

Another practical use case would be to deny access to a certain directory on your server. For example, you wish to deny access to a directory that contains your users' uploaded profile photos in /upload/ directory. Here's how you can apply such restriction:

location /upload/ {
    deny all;
}

This may do the job well for now until you have more matching cases to deal with. We will reexamine this further down with a more suitable modifier.

4. Match URLs using regular expression

Another common use case is when you want to serve static assets such as images to your visitors directly without having to route the request through your web application. NGINX is best known for serving static content efficiently. Therefore, it is wise to take advantage of such a feature.

By using the ~ modifier, it will allow us to define a configuration with regular expression to serve a collection of asset types, and handle it properly when they are not found.

location ~ \.(ico|gif|jpe?g|png|js|css)$ {
    try_files $uri =404;
}

As you can see from above, having the full power of regular expression makes matching URL pattern very convenient.

❗️ However, I want to stress that the above configuration is only beneficial if you have another match all location block that matches all URIs. If your site only serves static content, there's no need for such configuration.

5. Case-insensitivity in regular expression matching

The previous example works well if all your assets have a lower-case file extension. To cover both lower-case and upper-case file extensions, we can use the ~* modifier for case-insensitive matching.

location ~* \.(ico|gif|jpe?g|png|js|css)$ {
    try_files $uri =404;
}

This will match https://www.example.com/images/teapot.jpg as well as https://www.example.com/images/teapot.JPG.

❗️ Please note that this does not mean that a file named 'teapot.jpg' can be accessed by the URL request https://www.example.com/images/teapot.JPG. Instead, it is the underlying OS filesystem that decides whether a file can be served with a case-insensitive request or not, not NGINX.

6. Prioritising prefix matching

With multiple location blocks in place, how would NGINX decide which block gets matched with the request URI? Here's the order with what we've learned so far:

1. NGINX will always look for an exact match that uses the = modifier.
2. If there is no exact match, NGINX will try to match a RegEx location block that uses the ~ & ~* modifiers, in top-down order.
3. If there is no RegEx block match, NGINX will try to match the longest prefix location block that doesn't contain any modifiers.

Now, what if you want to match a prefix location block(step 3) first with the presence of other RegEx blocks(step 2)?

Remember the previous prefix match example that was used to deny access to a directory? Here's what we have before:

location /upload/ {
    deny all;
}

And here's the previous RegEx location block example for serving static assets:

location ~* \.(ico|gif|jpe?g|png|js|css)$ {
    try_files $uri =404;
}

However, since RegEx location blocks will be matched before URL prefix matches, the URL prefix block will never be matched. Therefore, anyone will be able to access all resources in the /upload/ directory.

To solve this issue, that's where you can use the ^~ modifier to prioritise a location block to be matched before other potentially matching RegEx blocks. In fact, NGINX will not perform any further RegEx location block matching checks if a ^~ modifier location block is found to be a match.

Here's how you can redefine the URL prefix block that imposes access restriction to a specific directory path:

location ^~ /upload/ {
    deny all;
}

With the above configuration, any request to the resources in /upload/ will be denied with a 403 Forbidden response, such as https://www.example.com/upload/profile23.jpg.

7. Determining the order of location matching

That concludes the fourth and last modifier available for use in a location directive. Therefore, the final matching order is as follows:

1. NGINX will look for an exact match that uses the = modifier.
2. If there is no exact match, NGINX will try to match the longest prefix location block that uses the ^~ modifier.
3. If there is no prefix match, NGINX will try to match a RegEx location block that uses the ~ & ~* modifiers, in top-down order.
4. If there is no RegEx block match, NGINX will try to match the longest prefix location block that doesn't contain any modifiers.

❗️ In reality, NGINX will first scan all non-RegEx based prefix location blocks(including ^~) and remember them to be used later if no RegEx location blocks are matched. But in my opinion, it's easier to visualize them in just four steps as described above.

🎁 Summary

That's all to it about NGINX location directive and all four of its modifiers. Here's a table to summarize each modifier's purpose and effect.

❗️Thank you for reading! If you find this useful, feel free to share it with your followers. 🦊

📙 References

To find out more about NGINX location directive and its technical details, you may read further from the following great resources.

• http://nginx.org/en/docs/http/ngx_http_core_module.html#location
• https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms
• https://www.keycdn.com/support/nginx-location-directive