DEV Community

Alaa Mohammad
Alaa Mohammad

Posted on • Updated on

Why and When to use Docker, Developing React App using Docker Container with Live Reload

developing React in Docker container
Why to use Docker?
Docker is an open platform offers portability, consistency, and scalability for developing, shipping, and running applications in different environments. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly.
A Docker container, unlike a virtual machine, does not require a separate operating system. Which gives Docker container advantages such as light-weight, consumes less space, more portability and needs short boot-up time.

Docker vs VM

When to use Docker?
1- If your business grows and new developers can join your team every few months. So instead of wasting valuable time setting up their local development environment. Such as the database or third-party libraries which may take a few hours to a couple of days. Which depends on the complexity of the project. Docker helps automate this setup so new developers can get right on board.

2- If the same software needs to run in a different environment: for example, a developer working on two PCs, development PCs and production servers, developers PCs, and testers PCs. Docker, you can run your application in separate containers, so your application can run in a consistent and predictable way in each environment.

3- If you need to test new technologies for your program, such as a new database, a different programming language, or new tools. So Docker Hub can be leveraged to pull the required package, tool or database to test with your application into an isolated container.

4- In case your software requires running multiple applications on the server? So, with Docker, you can keep the components of each application in separate containers even if they share the same resources.

When to avoid using Docker?
1- Working on the desktop application. Because Docker is more useful with web applications running on a server. Also, the rich GUI also requires additional solutions to work with Docker.

2- Working on a small application that does not require any additional tools or services.

3- If your development team consists of one developer. In this case, the benefits of using Docker will be less, and you can start using Docker when your software starts to grow.

4- If the majority of your team developers use a MacBook because Docker faces many performance issues when running on the Mac operating system.

Run React App on a Docker container to test a new environment:
1- Install Docker in your PC form the official website

2- Add Dockerfile to your project directory which will be used to build a Docker image (Dockerize the React App)

# Stage 1
# Use the desired Node.js runtime as the base image
FROM node:18-alpine AS build
RUN corepack enable
# Set the working directory in the container

# Copy package.json and pnpm-lock.yaml to the working directory
COPY package.json ./
COPY pnpm-lock.yaml ./

# Install project dependencies
RUN pnpm install

# Copy the entire React app code to the container
COPY . .

# Stage 2
# Expose the port of your application to bind with the host port

# run your app
CMD ["pnpm", "run", "start"]
Enter fullscreen mode Exit fullscreen mode

3- Add .dockerignore file:

Enter fullscreen mode Exit fullscreen mode

4- Build a Docker image based on Dockerfile
docker image build -t :
-t option specifies the name and tag (latest by default) for the image. represents the path in which you want to run the command (. (dot at the end) represent the current directory)

After building the image, you can review the result in Docker Desktop software as the following:

Docker Desktop software

5- Run Docker Container based on the generated image. By clicking on run or by using the following command
docker run --name -p 3005:3000 -d -v ${pwd}
For example: docker run --name ecommerce-website-react-reactquery-redux -p 3005:3000 -d -v ${pwd} ecommerce-website-react-reactquery-redux
Navigate to http://localhost:3005/ in your browser to view the app.

Another way to run a container based on a Docker image is by clicking the run button next to the image name in the Docker desktop software:

Run Docker container

6-Install the following extensions in VS Code

VS Code required extensions for Docker

7- In the lower left cornet in VS Code you will find a button “Open a remote view”. After clicking this button, click on “Attach a running container”.

Open VS Code in a remote view

After selecting the desired container, a new VS Code window will appear, in which you can make all the changes that you want and it will reflect in the browser.

VS Code remote view

🎉🎉[Project on GitHub] E-commerce Web Application: React, Redux, React Query, MUI ... (

Top comments (8)

stevepotter profile image
Stephen Potter

Nice article. You should make one correction though. Docker containers are not more secure than vms. Just remove that part in the beginning and you’re good. If you are interested, search around and you’ll find some interesting info. Have a great day

webjose profile image
José Pablo Ramírez Vargas

While interesting (and of course, well explained), what would be my gain as opposed to running the project locally in my PC? I mean, the exercise is interesting, but I am having a hard time identifying the value it brings.

pavelee profile image
Paweł Ciosek

In my opinion few possible reasons:

  • Your are working with few projects, some of them need different (older) version of node.js. Instead of switching it locally you just have prepared docker container for the app.
  • You are working with some complex ssr powered app . You would like to have dev and prod enviorment spinning up at the same time. So you can always see how the change looks like on prod enviorment and eventually errors during build time. It's pretty nice for ppl starting with a next.js, it's sometimes surprising that page will be static on the prod env 😅
  • You are working with some more complex app that need database, redis etc.
  • You are self-hosting your app, so probably you will need a docker 🤓
viiik profile image

I would argue none of those points are really good reasons to use Docker. Right now essentially all my development environments I run directly on my machine. IMO Docker does not lower complexity, it raises it.

  1. Node versions: Managing different docker images / docker files is at least as hard as using something like nvm. Also, just use the latest stable.
  2. Prod and dev environments: Just run the preview version if you really need to test production environment. If you are afraid to miss build time regressions, you can catch them on git push (and you should, including other tests).
  3. You can use docker to simplify other dependencies like say postgres or redis. That does not mean your app needs to also use docker.
  4. Self-hosting != docker. There are tons of options, a plain old systemd service has comparable configuration options like restart on error, logging, sandboxing directory access, etc. If systemd is too complex, there are simpler alternatives like the popular pm2 package on NPM.
Thread Thread
cmcnicholas profile image
Craig McNicholas

The great advantage is simply what runs in dev is what runs in prod. This alone is the single biggest reason, you can be very confident changes don't break your environment.

Now add more team members working across front and backend and you take away any pain of a Dev needing to configure a like for like environment.

webjose profile image
José Pablo Ramírez Vargas

Thanks for stopping by. I see some of those could be possible. However, they feel a bit too specific. I suppose this doesn't invalidate the reasons, nonetheless. Except for the last one, I would say. Once you need to host, you need the compiled version of the project, not the development one proposed here.

matija2209 profile image

Running it on Macbok is a mess.

alexknips profile image
Alexander Knips

I also don't really see the benefits yet but once you introduce additional containers, it certainly would be more interesting. If you go even further and run it with kubernetes locally to actually test how multiple microservices work together while still having live reload, then you got something.