DEV Community

loading...

Docker for the frontend and backend development -just for local testing not for the deployment.

vishwasnarayan5 profile image vishwasnarayanre ・6 min read

We now have a frontend and backend that work flawlessly on our local computer. Although you can get more out of this guide if you have finished the previous pieces, it can also be useful in general. The aim of this section is to ready our web applications for modern deployment.

We want to be able to easily run our frontend and backend on every computer and scale the framework if necessary. There are several ways to do that, just as there are numerous ways to do something else. We'll use Docker for this series since it's been very successful in recent years. This guide is broken down into four sections:

  • What is Docker?
  • Dockerizing the frontend
  • Dockerizing the backend
  • Running it all at once #what is docker?

There are a great many clarifications on what docker is everywhere on the web. I need to contact the main parts however I will not go into subtleties here. My primary concerns were taken from this video.

Lets say we fabricated our backend as container document and tried it locally. Presently we need to discover a spot in the cloud to run it. The primary test that we experience presently is that we can not ensure that our backend runs in the cloud actually as it does locally. Just if the cloud climate is equivalent to our neighborhood climate, we could make such a guarantee. To get the hole between our neighborhood and the cloud climate as little as conceivable we need to tell our cloud-supplier what we need. Nonetheless, as a cloud supplier you can not have 1,000,000 designers reveal to you how their individual cloud arrangement should resemble. That is the reason cloud-suppliers offer various bundles. They fluctuate between giving a (virtual) machine and giving us a static climate to run our application in. If there should arise an occurrence of an individual machine it is presently dependent upon us, the designer, to ensure the machine carries on as our nearby machine. That is too expensive time and is additionally costly as we don't actually require a whole machine. We simply need a spot to run our container record. If there should arise an occurrence of furnishing us with a static climate we would now need to ensure that our neighborhood climate acts something very similar. This isn't valuable all things considered. Precisely here becomes docker helpful.

Docker gives a shared conviction and is in a real sense tantamount with genuine steel trailers. A banana-organization just stresses over how to get their bananas into the compartment. Whenever it is shut it does't make any difference what is in there. It is fundamentally dealt with like each and every other compartment and the delivery organizations realize how to function with it. Docker gives a standard that is adequately adaptable yet additionally ensures the product runs in the cloud a similar way it does locally.

We use docker to make a docker-picture of our application. Simply picture we would copy it on a Compact disc. That picture is assemble utilizing a dockerfile that characterizes how the docker-picture ought to be constructed. That picture would then be able to be utilized inside a docker-compartment.

Docker is an amazing asset and gives more valuable highlights (for example scaling). Anyway this isn't as important here.

Docker for the frontend

Please ensure that you have docker configured before attempting to dockerize the frontend. In addition, in config.nuxt.js, we must examine our base url. Since, if we deploy our app in the cloud as is, it would still believe that our backend is accessible at localhost:8080. That is why we must remove every environment-specific element.

Extracting environment specific variables

Please ensure that you have docker configured before you attempt to dockerize the frontend. Furthermore, in our frontend, we only have one environment variable, which is the URL of our backend.

You will remember that in the nuxt.config.js package, we used the proxy module. All that remains is to include the environment variables.

If no value is available, we set it to the default value (http://localhost:8080/), and we must check our base url in config.nuxt.js. Since, if we deploy our app in the cloud as is, it would still believe our backend is accessible at localhost:8080. As a result, we must remove any environment-specific variable.

proxy: {
    '/api/': process.env.PROXY_API || 'http://localhost:8080/'
},
Enter fullscreen mode Exit fullscreen mode

Next, in our frontend folder, we'll make a dockerfile called frontend.dockerfile. The code in our docker file is as follows.

FROM node:alpine3.12

# Create an application directory
RUN mkdir -p /app

# The /app directory should act as the main application directory
WORKDIR /app

# Copy the app package and package-lock.json file
COPY frontend/package*.json ./

# Install node packages
RUN npm install

# Copy or project directory (locally) in the current directory of our docker image (/app)
COPY frontend/ .

# Build the app
RUN npm run build

# Expose $PORT on container.
# We use a varibale here as the port is something that can differ on the environment.
EXPOSE $PORT

# Set host to localhost / the docker image
ENV NUXT_HOST=0.0.0.0

# Set app port
ENV NUXT_PORT=$PORT

# Set the base url
ENV PROXY_API=$PROXY_API

# Set the browser base url
ENV PROXY_LOGIN=$PROXY_LOGIN

# Start the app
CMD [ "npm", "start" ]
Enter fullscreen mode Exit fullscreen mode

The remarks and comments on each line should hopefully clarify what's going on. To create the picture, simply type this command into the terminal. Be sure to run it from the root directory of your project!

docker build --file=frontend/frontend.dockerfile -t playground-web-frontend .

. : Full stop is very important

—file → The file to use for the build

-t → To identify our image we tag it

.→ The location of the build context (the app). In our case the current directory, referenced as.

Until we can dockerize or backend, we must remove every environment-specific attribute, just as we did for our frontend.In our backend, we have two environment-specific variables. The address of our frontend and the address of our servers.

The programme configures all environment-specific variables.

The assets file is located in the resources folder. Each line includes a key and a value. For the value, we'll use an environment variable (provided by docker) or the default value. Put in the following code.

spring.data.mongodb.uri=${MONGODB_URI:mongodb://localhost:27017/todo}server.port=${PORT:8080}

You may be wondering why we haven't already set the URI for mogoDB. That's because spring thought by default that the mongoDB will be found at that URI. That will change once we put it in place. That's why we're extracting it. Heroku can use the server port in the following section of the tutorial.

FROM openjdk:15

# Create an application directory
RUN mkdir -p /app

# The /app directory should act as the main application directory
WORKDIR /app

# Copy or project directory (locally) in the current directory of our docker image (/app)
COPY backend/build/libs/*.jar ./app.jar

# Expose $PORT on container.
# We use a varibale here as the port is something that can differ on the environment.
EXPOSE $PORT

# Start the app
CMD [ "java", "-jar", "./app.jar" ]
Enter fullscreen mode Exit fullscreen mode

The remarks/comments on each line should hopefully clarify what's going on with the dockerfile.

There is a significant disparity between the frontend- and backend-dockerfiles. The former holds the application's code. If we make improvements to the backend, we must first construct it with this command.

gradle build

To create the picture, simply type this command into the terminal. Again, make sure to run it from the root directory of your project!

docker build --file=backend/backend.dockerfile -t playground-web-backend .

—file → The file to use for the build

-t → To identify our image we tag it

.→ The location of the build context (the app). In our case the current directory, referenced as.

We'll use docker-compose to start it up now that we have everything we need. The docker compose command instructs Docker to launch the services (and which images) to use, as well as to set the environment variables. In the root folder of your project, create a new file called docker-compose.yml.

version: '1'
services:
  playground-web-db:
    image: mongo:4.4
    environment:
      MONGO_INITDB_DATABASE: playground-web
    ports:
      - 27017:27017
  playground-web-frontend:
    image: playground-web-frontend:latest
    environment:
      PORT: 3000
      PROXY_API: http://playground-web-backend:8080/
    ports:
      - 3000:3000
  playground-web-backend:
    image: playground-web-backend:latest
    environment:
      MONGODB_URI: mongodb://playground-web-db:27017/playground-web
    ports:
      - 8080:8080
Enter fullscreen mode Exit fullscreen mode

To run the app execute:

docker-compose -f docker-compose.yml up

Thus you will have your application up and running.

Discussion (0)

Forem Open with the Forem app