DEV Community: Scalia Abel

Containerizing A NextJs Application For Development

Scalia Abel — Fri, 14 Apr 2023 16:21:04 +0000

Introduction

Containerizing your NextJs application can be an efficient way of developing it, as it provides a more isolated and reproducible environment. In this article, we will go through the steps required to containerize a NextJs application and explain each step in detail.

Prerequisites

Before we begin, you should have a basic knowledge of NextJs and familiarity with Docker CLI and Docker Compose commands.

Note: The docker image we'll be building should not be used in a production environment.

Creating A NextJs Application

The first step is to create a NextJs application. To do this, you can run the following command:



npx create-next-app docker-next

This will create a NextJs application called docker-next in your current working directory.

You will be prompt to decide whether to include TypeScript, TailwindCSS and a few other things. Feel free to choose whichever options as we won't be going through NextJs in depth.

Setting Up Docker

If you are on Windows or Mac, you can directly install docker desktop. If you are on linux, you may want to follow the instructions listed here.

Once you have Docker installed, verify that the Docker CLI and Docker Compose are installed correctly by running the following commands:



docker -v
docker-compose -v

These commands should output the versions of Docker and Docker Compose, respectively.

Containerizing NextJs

We should delete our node_modules folder and package-lock.json file because it helps to reduce the size of the image and ensure that the dependencies in the image are consistent with the ones declared in the package.json file.

Now that we have the necessary tools to run docker, we can start containerizing our NextJs application.

Creating A Dockerfile

The first step is to create a Dockerfile for our application. You can do this by running the following command:



touch Dockerfile

This command will create a new empty file named Dockerfile in your current directory.

The contents of your Dockerfile should look like this.



FROM node:18-alpine

WORKDIR /app

COPY package.json ./

RUN npm install

COPY . .

CMD ["npm", "run", "dev"]

Let's go through each line of this Dockerfile:

FROM node:18-alpine: This line specifies the base image to use for our container. We're using the node image with version 18 that is built on top of the alpine Linux distribution.
WORKDIR /app: This line sets the working directory for our container to /app. This is important to avoid clashing of folder names between our application and the container's.
COPY package.json ./: This line copies the package.json file from our local machine to the /app directory inside the container.
RUN npm install: This line installs the dependencies required by our application inside the container.
COPY . .: This line copies the entire contents of our application from our local machine to the /app directory inside the container.
CMD ["npm", "run", "dev"]: This line specifies the command to run when the container starts. In this case, we're running the npm run dev command, which will start our NextJs development server.

Note: Replace npm with your choice of package manager.

Bulding The Docker Image

Now that we have our Dockerfile, we can build the Docker image by running the following command:



docker build -t docker-next .

This command will build a new Docker image named docker-next from the Dockerfile in our current directory. The -t flag specifies the name of the image, and the . specifies the build context.

Running The Container

To run the container, we can use the following command:



docker run docker-next -p 3000:3000 -v /app/node_modules -v .:/app

Here's what each option means:

-p 3000:3000: maps port 3000 of the container to port 3000 of the host machine. This means that you can access the application by navigating to http://localhost:3000 in your web browser.
-v /app/node_modules: mounts the /app/node_modules directory in the container as a volume. This is useful because it allows you to take advantage of Docker's caching mechanism. Since node_modules is typically a large directory that doesn't change very often, mounting it as a volume means that it won't have to be rebuilt every time you make changes to your application's code.
-v .:/app: mounts the current directory (i.e., the directory where you run the command) as a volume at the /app directory inside the container. This is where your Next.js application code lives.

So in summary, this command runs a Docker container from the docker-next image, maps port 3000 of the container to port 3000 of the host machine, mounts the /app/node_modules directory in the container as a volume, and mounts the current directory as a volume at /app inside the container

Once the container has run, visit localhost:3000 in your browser and you should be greeted with the NextJs default page.

Having to type this command:



docker run docker-next -p 3000:3000 -v /app/node_modules -v .:/app

every single time, will slowly chip away your sanity. That's where docker compose comes in.

Enter Docker Compose

Docker Compose is a tool for defining and running multi-container Docker applications. It allows you to describe the services that make up your application in a YAML file, and then start and stop those services using a single command.

With Docker Compose, you can also scale your application's services, set up networking between containers, and more. Essentially, Docker Compose makes it easier to manage and deploy multi-container Docker applications.

Creating The Docker Compose File

We can create the docker compose file by running:



touch docker-compose.yml

Paste this into the docker-compose.yml file:



version: '3.5'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: docker-next
    ports:
      - '3000:3000'
    volumes:
      - .:/app
      - /app/node_modules

First we define a service called app, that will be build using the Dockerfile located in our root directory and run in a container. The service exposes the container's port 3000 to the host's port 3000 and mounts two volumes:

.:app: This will mount the directory where the Docker Compose file is located as a volume in the container at the /app directory. This is useful for development as it allows for live reloading of code changes made on the host machine to be reflected in the container.
/app/node_modules: This mounts the node_modules directory in the container as a separate volume. This is done to avoid overriding the dependencies installed by npm during the image build process with the dependencies installed on the host machine.

To start our application, just run the following command:



docker-compose up

Congratulations, you just containerized a NextJs application.

Bonus

There is one caveat developing with a containerized application, which is running cli commands. Specifically, in our case npm commands.

If you need to add new dependencies, you will need to run:



docker-compose run --rm app npm install <package name>

The docker-compose run command allows you to run a one-time command against a service defined in your docker-compose.yml file. The --rm option specifies that the container created from the service should be removed after the command is executed. This option ensures that the container is cleaned up and does not consume resources on your system after it's no longer needed.

In this case, app is the name of the service defined in docker-compose.yml that the command is being run against.

To keep our sanity in check, we'll be building a script to help us run docker-compose, npm and node commands.

Creating A Script To Run Docker Compose, NPM And Node Commands

We will be building a script based on laravel/sail.

Create a file called harbor and make it executable.



touch harbor
chmod +x harbor

Paste the following into the harbor file:



#!/usr/bin/env bash
function display_help {
  echo "Harbor"
  echo
  echo "Usage:" >&2
  echo "  harbor COMMAND [options] [arguments]"
  echo
  echo "Unknown commands are passed to the docker-compose binary."
  echo
  echo "docker-compose Commands:"
  echo "  harbor up        Start the application"
  echo "  harbor up -d     Start the application in the background"
  echo "  harbor stop      Stop the application"
  echo "  harbor down      Stop the application and remove related resources"
  echo "  harbor restart   Restart the application"
  echo "  harbor ps        Display the status of all containers"
  echo
  echo "Node Commands:"
  echo "  harbor node ...         Run a Node command"
  echo "  harbor node --version"
  echo
  echo "Npm Commands:"
  echo "  harbor npm ...        Run a Npm command"
  echo "  harbor npm test"
  echo
  echo "Customization:"
  echo "  harbor build --no-cache       Rebuild all of the harbor containers"

  exit 1
}

if [ $# -gt 0 ]; then
  if [ "$1" == "npm" ]; then
    shift 1
    docker-compose run --rm app npm "$@"
  elif [ "$1" == "node" ]; then
    shift 1
    docker-compose run --rm app node "$@"
  elif [ "$1" == "help" ] || [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
    display_help
  else
    docker-compose -f docker/dev/docker-compose.yml "$@"
  fi
else
  display_help
fi

The display_help function is defined first, which prints out the available commands, options, and arguments to the user.

The script then checks if there is at least one command-line argument ($# -gt 0). If there is, it checks if the first argument is npm or node. If the argument is npm or node, it runs the corresponding command using docker-compose run --rm app. If the argument is help, --help, or -h, it prints out the help information using the display_help function. Otherwise, it passes the command and any arguments to docker-compose to execute.

If there are no command-line arguments, the script also prints out the help information using the display_help function.

The help output will look like this.

Now we are able to run npm and node commands by using the script that we just created. You can take it up a notch and include conditions for yarn and pnpm or put everything in an npm package and publish it, since it's basically framework agnostic.

Conclusion

Containerizing a Next.js application with Docker provides a more isolated and reproducible environment, making it an efficient way of developing and onboarding new developers.

Hopefully, this article has helped provide some clarity and deepen your understanding regarding docker. If you have any feedback or comments, feel free to leave them in the comments section.

If you enjoyed this article, consider tipping me.

Note: Link to GitHub Repository

Laravel Google Login with Socialite

Scalia Abel — Tue, 08 Feb 2022 17:37:28 +0000

Social login help simplifies registration and login for the end users. Socialite is a social login package provided by Laravel. This package allows us to seamlessly integrate social logins like Facebook, Twitter, Google and many more. The list of adapters that Socialite provides can be found here.

A Google Cloud Platform (GCP) account is required for this example.

Installation

First we need to scaffold our application with Laravel breeze. You can follow the steps provided here.

Once the scaffolding is done, we will need to install the socialite package into our application.



composer require laravel/socialite

Setting Up Migrations

Let's create a table to store the user's socialite login.



php artisan make:migration CreateSocialiteLoginsTable

Next, setup the columns for our socialite_logins table.



use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateSocialiteLoginsTable extends Migration
{
    public function up(): void
    {
        Schema::create('socialite_logins', function (Blueprint $table) {
            $table->id();
            $table->foreignId('user_id')->references('id')->on('users');
            $table->string('provider_id');
            $table->string('provider');
            $table->timestamps();
        });
    }

    public function down(): void
    {
        Schema::dropIfExists('socialite_logins');
    }
}

The user_id column will be used to map the socialite logins to the users. The type of provider will be saved in the provider column, i.e google.

Considering that the users are not required to register, make sure to change the password column in our CreateUsersTable migration to nullable, .

Setting Up Models

Create a SocialiteLogin model.



php artisan make:model SocialiteLogin

Since we are only implementing the Google authentication and a user can only have one Google account, the relationship between the SocialiteLogin model and User model is One-to-One.

If you feel like implementing another social login, you will need to change the relationship to Many-to-One.

Add the user_id, provider and provider_id field to the $fillable property in the SocialiteLogin model.



namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

class SocialiteLogin extends Model
{
    use HasFactory;

    protected $fillable = [
        'user_id',
        'provider',
        'provider_id'
    ];

    public function user(): BelongsTo
    {
        return $this->belongsTo(User::class);
    }
}

Next, add the socialiteLogin relationship in the User model.



namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Laravel\Sanctum\HasApiTokens;

class User extends Authenticatable
{
    use HasFactory;
    use HasApiTokens;

    /**
     * The attributes that are mass assignable.
     *
     * @var string[]
     */
    protected $fillable = [
        'name',
        'email',
        'password',
    ];

    /**
     * The attributes that should be hidden for serialization.
     *
     * @var array
     */
    protected $hidden = [
        'password',
        'remember_token',
    ];

    /**
     * The attributes that should be cast.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
    ];

    // change this to HasMany
    // if you are implementing
    // more than one social login
    public function socialiteLogin(): BelongsTo
    {
        return $this->belongsTo(SocialiteLogin::class);
    }
}

Setting Up Google Cloud Platform

Login to a Google Cloud Platform account and select a project or create one. Click on the sidebar and navigate to the API and services -> OAuth Consent Screen.

Setting Up OAuth Consent Screen

We will be greeted by this screen.

Since we are authenticating external users, the user type that we'll be selecting is external.

Once we have selected the type of user, we will be redirected to the OAuth Consent Screen page. We are only required to fill in the app information section and the developer contact information.

The developer contact information will be your personal/work email.

After setting up the app information, we will be setting up the scope of permission that is needed for our application. Click the add or remove scopes and select userinfo.email and userinfo.profile scope.

Click save and continue and setup the test user with an existing gmail account.

Setting Up Credentials

Proceed to the credentials tab located on the sidebar and create a new OAuth Client ID. The application type we are using is web application.

If you are developing with an SPA, you will need to setup the Authorized JavaScript Origin section. The http://localhost:3000 url is sufficient for this field.

The Authorized Redirect URIs is where we are going to handle the authentication of the user based on their email and profile. Our url will be http://127.0.0.1:8000/login/google/callback.

Once we have created the credentials, we will be given the CLIENT_ID and CLIENT_SECRET values.

The credentials will be placed in services.php config and .env file.



// .env
GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=
GOOGLE_REDIRECT_URI= // callback url

// services.php
'google' => [
   'client_id' => env('GOOGLE_CLIENT_ID'),
   'client_secret' => env('GOOGLE_CLIENT_SECRET'),
   'redirect' => env('GOOGLE_REDIRECT_URI'), // callback url
]

Setting Up URL and Callback

Create a SocialiteLoginController controller. This controller will be consisting of two functions, redirectToProvider and handleProviderCallback



php artisan make:controller SocialiteLoginController

Handling The Redirection and Callback

The redirectToProvider will only redirect the user to the google authentication page via the Socialite Driver.

Moving on to the handleProviderCallback. First we get the user from the Socialite driver. This user returns a variety of informations since the Google provider supports OAuth2.0.

In our case, we only need the user's email, name and id of the provider. We will be using Laravel's firstOrCreate method to identify if the user exists. If it does not, we will create a new user.

We will be using the same method for our SocialiteLogin model. We are doing this to ensure that there is no duplication for the socialite login since a user can only have one google account.

We can now safely authenticate the user by using Laravel's auth helper and redirect them to the dashboard.

The controller will look something like this.



namespace App\Http\Controllers;

use Laravel\Socialite\Facades\Socialite;

class SocialiteLoginController extends Controller
{
    public function redirectToProvider()
    {
        return Socialite::driver('google')->redirect();
    }

    public function handleProviderCallback()
    {
        $socialiteUser = Socialite::driver('google')->user();

        $user = User::firstOrCreate(
            [
                'email' => $socialiteUser->getEmail(),
            ],
            [
                'name' => $socialiteUser->getName(),
            ]
        );

        SocialiteLogin::firstOrCreate(
            [
                'user_id' => $user->id,
                'provider' => 'google',
            ],
            [
                'provider_id' => $socialiteUser->getId()
            ]
        );

        auth()->login($user);

        return redirect(route('dashboard'));
    }
}

Setting Up The Route

Add the controller to the web.php route file.



// web.php
Route::get('/login/google', [SocialiteLoginController::class, 'redirectToProvider']);
Route::get('/login/google/callback', [SocialiteLoginController::class, 'handleProviderCallback']);

The callback url needs to be the same with what we have setup in our Google Cloud Platform.

Updating the UI

We begin by starting our development server.



php artisan serve

The UI is pretty simple compared to what we have done so far.

Since we will be doing a redirection, using an anchor tag makes more sense than using a button. Paste the code below to the login.blade.php.

Make sure to change the url accordingly



// login.blade.php
<a
  href="/login/google"
  class="ml-3 inline-flex items-center px-4 py-2 bg-gray-800 border border-transparent rounded-md font-semibold text-xs text-white uppercase tracking-widest hover:bg-gray-700 active:bg-gray-900 focus:outline-none focus:border-gray-900 focus:ring ring-gray-300 disabled:opacity-25 transition ease-in-out duration-150"
>
   Login Google
</a>

Click on the Login Google button to proceed to the Google OAuth Screen. After selecting a google account, we will be redirected to the dashboard after being authenticated.

Conclusion

Most of the providers that Socialite supports have the same implementation thus helping us reduce the boilerplate needed to be written and maintained.

Let me know if there are any questions or things that I can improve on.