Forem: ritwikmath

Python Design Patterns Cookbook: Recipes for Clean and Reusable Code (Facade)

ritwikmath — Tue, 13 Jun 2023 17:27:49 +0000

Design Patterns: An Introduction and Explanation

Design patterns are like recipes that software developers use to solve common problems that come up when building complex software. Like how different chefs might use slightly different ingredients or techniques to make the same dish, developers can use different approaches to implement the same design pattern. Design patterns are not strict rules that apply to every situation, but rather a blueprint that can be customized to fit the specific problem at hand. They can be used with any programming language and it's important to choose the correct design pattern for each situation.

Facade Design Pattern

Introduction

As software systems grow in size and complexity over time, they can become increasingly difficult to maintain and modify. This can be especially challenging when trying to add new features or make changes to existing functionality, as exposing the complex inner workings of the system can lead to unwanted side effects and unpredictable behavior. Additionally, developers may find themselves duplicating the same code in multiple parts of the system, leading to redundant and hard-to-maintain code.

To address these challenges, the Facade design pattern provides a way to hide the complexity of a system behind a simple interface, allowing developers to execute a set of operations in one place without exposing the inner workings of the system. This approach can greatly simplify the development process, reduce duplication of code, and make it easier to maintain and modify the system over time. In this way, the Facade pattern is a powerful tool for improving the maintainability and scalability of software systems.

Issue You May Face

As a developer, you have been assigned building a key component of our multimedia player software that can support a wide range of audio file formats, including MP3, WAV, and FLAC. The main objective is to design a system that allows users to seamlessly play audio files of different formats, eliminating the need for them to worry about the underlying complexities involved in handling diverse file formats.

Your responsibility is to create robust software that ensures users can enjoy a smooth and uninterrupted playback experience, regardless of the audio file format they choose. It is essential to develop a solution that abstracts the intricacies associated with decoding and playback, providing users with a simple and intuitive interface to initiate and control audio playback effortlessly.

A Logical Solution

In the given scenario, we have a multimedia player system that supports various file formats, including MP3, WAV, and FLAC. To simplify the interaction with the player and hide the complexity of handling different file formats, we can apply the Facade design pattern. The MultimediaFacade class serves as the facade, providing a simplified interface for the client code to interact with the multimedia player. It encapsulates the interactions with the MP3Codec, WAVCodec, and FLACCodec subsystems responsible for decoding the respective file formats.

When the client code calls the play() method of the MultimediaFacade, it passes the filename of the audio file to be played. The facade internally determines the file format based on its extension and delegates the decoding process to the appropriate codec subsystem. Once decoded, the facade initiates the playback of the file, abstracting the details of decoding and playback from the client.

Using Facade Design Pattern

So, here's the deal! You can create three cool classes for handling different types of audio files. We have the MP3Codec class, the WAVCodec class, and the FLACCodec class. Each of these classes knows how to decode its specific type of audio file. For example, the MP3Codec can decode MP3 files, the WAVCodec can handle WAV files, and the FLACCodec can work with FLAC files.

But wait, there's more! We also have this awesome MultimediaFacade class. It acts as the mastermind behind the scenes, making your life easier. Inside this class, we create instances of the codec classes, like mp3_codec, wav_codec, and flac_codec.

Now, here's the magic. The MultimediaFacade class has a nifty play() method that takes the name of a file as input. It's smart enough to figure out the file format based on its extension (you know, like .mp3, .wav, or .flac).

When you call the play() method with a file name, the MultimediaFacade class does all the heavy lifting. If it's an MP3 file, it uses the mp3_codec to decode it and then proudly announces that it's playing an MP3 file. If it's a WAV file, it delegates the decoding to the wav_codec and says it's playing a WAV file. And of course, if it's a FLAC file, it uses the flac_codec and lets you know that it's playing a FLAC file.

Oh, and if it encounters a file format it doesn't support, it kindly informs you that it's an unsupported format. But let's hope we only throw in some cool MP3s, WAVs, and FLACs, right?

To get this party started, you just need to create an instance of the MultimediaFacade class and call its play() method with the file names you want to groove to. So grab your favorite music.mp3, audio.wav, or audio.flac, and let the multimedia player do its thing!

Code Example

class MP3Codec:
    def decode(self, filename):
        print("Decoding MP3 file:", filename)

class WAVCodec:
    def decode(self, filename):
        print("Decoding WAV file:", filename)

class FLACCodec:
    def decode(self, filename):
        print("Decoding FLAC file:", filename)

class MultimediaFacade:
    def __init__(self):
        self.mp3_codec = MP3Codec()
        self.wav_codec = WAVCodec()
        self.flac_codec = FLACCodec()

    def play(self, filename):
        if filename.endswith(".mp3"):
            self.mp3_codec.decode(filename)
            print("Playing MP3 file...")
        elif filename.endswith(".wav"):
            self.wav_codec.decode(filename)
            print("Playing WAV file...")
        elif filename.endswith(".flac"):
            self.flac_codec.decode(filename)
            print("Playing FLAC file...")
        else:
            print("Unsupported file format.")

# Client code
multimedia = MultimediaFacade()
multimedia.play("music.mp3")
multimedia.play("audio.wav")
multimedia.play("audio.flac")

With the current implementation of the Facade pattern, you can simplify the process of repairing electronic devices by providing a unified interface that hides the complexities of handling different device types. This means that you can seamlessly add new devices to the system without modifying any existing code.

Let's say you have a system that guides users through repairing mobile phones and laptops. Each device may have unique repair requirements, such as different components or repair procedures. However, by utilizing the Facade pattern, you can create a streamlined interface that abstracts away these differences and provides a consistent user experience.

Differences with Factory Design Pattern

The Facade pattern is a structural design pattern that provides a simplified interface to a complex subsystem or set of classes. The Factory Method pattern is a creational design pattern that provides an interface for creating objects, but allows subclasses to decide which class to instantiate.

The primary goal of the Facade pattern is to simplify the usage of a complex system by providing a high-level, user-friendly interface. The factory method, on the other hand, encapsulates the object creation logic, providing flexibility in choosing the appropriate class to instantiate based on the specific requirements or conditions.

Factors Should be Taken into Consideration

While the Facade pattern can be beneficial in many cases, there are situations where it may not be the best choice. Here are some scenarios in which using the Facade pattern may not be recommended:

If your system is relatively simple and does not involve a complex arrangement of classes or subsystems, introducing a Facade may add unnecessary complexity.
In systems where components and their interactions change frequently, applying a Facade pattern may lead to increased maintenance efforts.
If clients require fine-grained control and access to individual components or subsystems, using a Facade may limit their flexibility.
In performance-critical systems where every millisecond counts, the additional abstraction layer introduced by the Facade pattern may impact performance.

Conclusion

In conclusion, the Facade design pattern offers a powerful solution for simplifying complex systems and providing a user-friendly interface to clients. By encapsulating the complexities of the underlying subsystems, the Facade pattern promotes code readability, maintainability, and ease of use. It allows clients to interact with a unified interface, shielding them from the intricate details of the system's internal workings.

However, it's essential to carefully consider when to use the Facade pattern. Simple systems, highly dynamic systems, cases requiring fine-grained control, performance-critical systems, and situations where the Facade does not significantly reduce complexity may not be the ideal fit for this pattern. It's crucial to evaluate the specific requirements and trade-offs of each scenario to determine whether the benefits of using a Facade outweigh the potential drawbacks.

Python Design Patterns Cookbook: Recipes for Clean and Reusable Code (Factory Method)

ritwikmath — Sat, 29 Apr 2023 12:35:05 +0000

Design Patterns: An Introduction and Explanation

Factory Design Pattern

Introduction

When a software program has multiple components that share similarities but have different implementations for general operations, a junior developer may use conditionals like if-else or switch-case to handle the differences. However, as the number of components grows, the code becomes difficult to manage and maintain. For example, imagine a program that handles different types of shapes, such as circles and squares. A junior developer may write a method that handles the calculation of area for each shape separated by if-else, but as new shapes are added, the code becomes longer and harder to manage.

To avoid the problems that come with using conditionals for handling multiple components' behavior, a better approach is to use the Factory Method pattern. The Factory Method pattern involves creating an interface or abstract class that represents the category, such as the "Shape" interface in the previous example. Each shape, such as a "Circle" or "Square," then implements this interface and defines its behavior for calculating area. This approach simplifies the code because each new shape can simply implement the "Shape" interface that will enforce the new shape to implement a method for calculating area without affecting the existing code.

Issue You May Face

You've been tasked with creating software that guides users through repairing electronic devices, starting with mobile phones and laptops. However, the process for repairing different components, such as screens, batteries, and ports, is unique to each device, and not all repairs are possible in both. Additionally, the company plans to add seven more devices to the system within the next three months, and the repair instructions may need to be updated as technology evolves. To ensure scalability and ease of modification, the system needs to be designed accordingly.

To simplify matters, it is often assumed that all models of a particular mobile phone or laptop can be repaired using the same process.

A Logical Solution

One way to solve this problem is by categorizing the devices based on their common characteristics, such as whether or not they have a SIM slot or a HDD. You could then create separate sets of instructions for each category, which would allow you to provide device-specific instructions while still keeping the instructions organized and easy to manage. This would also make it easier to add new devices to the system in the future, since you could simply categorize them based on their characteristics and create a new set of instructions for that category.

Using Factory Method

To implement the Factory method, you can start by creating an abstract class called RepairGuide. This class will define the interface for all the repair guides and should include abstract methods for repairing the screen, RAM, and SIM slot. Then, you can create two concrete classes, MobileRepairGuide and LaptopRepairGuide, that implement the RepairGuide interface and provide device-specific repair instructions.

Next, you can create a RepairGuideFactory class that will create the appropriate RepairGuide object based on the device type passed to it. In your main program, you can create a RepairGuide object for a mobile device using the RepairGuideFactory. Then, you can display a list of available repair options to the user by getting the list of subclasses of the RepairGuide class using the subclasses() method.

Once the user selects a device, you can create the appropriate RepairGuide object using the RepairGuideFactory. Then, you can display a list of available repair options for the selected device by getting a list of all the non-private methods of the object using the inspect.getmembers() function.

You can iterate through this list and display the name of each method, which corresponds to a repair option. Then, prompt the user to select a repair option. Once the user selects a repair option, you can call the corresponding method on the RepairGuide object. This will execute the device-specific repair instructions for the selected repair option.

Code Example

import inspect
from abc import ABC, abstractmethod

class RepairGuide(ABC):
    @abstractmethod
    def repair_screen(self):
        pass

    @abstractmethod
    def repair_ram(self):
        pass

    @abstractmethod
    def repair_sim_slot(self):
        pass

class MobileRepairGuide(RepairGuide):
    def repair_screen(self):
        print("Mobile screen repair instructions.")

    def repair_ram(self):
        print("RAM repair is not possible on mobile phones..")

    def repair_sim_slot(self):
        print("Mobile SIM slot repair instructions.")

class LaptopRepairGuide(RepairGuide):
    def repair_screen(self):
        print("Laptop screen repair instructions.")

    def repair_ram(self):
        print("Laptop RAM repair instructions.")

    def repair_sim_slot(self):
        print("SIM slot repair is not possible on laptops.")

class RepairGuideFactory:
    @staticmethod
    def create_repair_guide(device_type):
        if device_type == "mobile":
            return MobileRepairGuide()
        elif device_type == "laptop":
            return LaptopRepairGuide()
        else:
            return None

    @staticmethod
    def sub_class_list():
        return RepairGuide.__subclasses__()

options = []
count = 1
for sub_class in RepairGuideFactory.sub_class_list():
    print(str(count) + ': ' + sub_class.__name__[:sub_class.__name__.find('R')])
    options.append(sub_class.__name__[:sub_class.__name__.find('R')].lower())
    count += 1

selected = input('Which device you want to repair? \n')
obj = RepairGuideFactory.create_repair_guide(options[int(selected)-1])
repair_options = []
count = 1
functions = inspect.getmembers(type(obj), predicate=inspect.isfunction)
for func in functions:
    if not func[0].startswith('__'):
        print(str(count) + ': ' + func[0].capitalize().replace('_', ' '))
        repair_options.append(getattr(obj, func[0]))
        count += 1
selected = input('Which part you want to repair? \n')
repair_options[int(selected)-1]()

With the current implementation of the Factory Method, you can add as many new device types as you want without having to modify any of the existing code. Additionally, if you need to add repair instructions for a new device type, you can do so with confidence because any new child class that you create must implement all the abstract methods that are defined in the superclass.

Why not Simple if-else?

As previously demonstrated, the Factory Method pattern can provide a high degree of flexibility to your code. Although this level of dynamic implementation may not always be necessary, using the Factory Method approach offers additional benefits. By avoiding the use of conditional statements like if-else for object creation, the code becomes easier to maintain. Additionally, the Factory Method pattern increases testability by allowing for the entire method to be mocked during testing.

Furthermore, the Factory Method pattern strongly supports four fundamental Object-Oriented Programming principles: encapsulation, abstraction, polymorphism, and the Open/Closed principle.

Factors Should be Taken into Consideration

By considering following factors, you can determine whether the Factory Method pattern is the right solution for your specific situation.

The number of products or object types: The Factory Method pattern is most useful when you have a large number of related objects that need to be created.
The complexity of object creation: If creating an object is a complex process that involves multiple steps, it makes sense to use a Factory Method to encapsulate that complexity.
Dependency injection: If you need to create objects that depend on other objects, you can use the Factory Method to inject those dependencies into the objects being created.
Testability: Using the Factory Method can make your code more testable by allowing you to easily create mock objects for testing.
Extensibility: The Factory Method pattern can make your code more extensible by allowing you to add new products or object types without changing the existing code.

Conclusion

The Factory Method is a design pattern that has many benefits and can make your code more dynamic, flexible, and maintainable. The pattern allows you to create objects without having to know the exact class of the object that will be created. This level of abstraction provides many benefits, including better encapsulation, abstraction, polymorphism, and adherence to the open/closed principle.

When creating a Factory Method, there are several factors that you should take into consideration. These include the complexity of the objects being created, the need for flexibility and extensibility, and the maintainability of the code. By carefully considering these factors, you can create a Factory Method that provides maximum benefits and reduces the risk of errors and maintenance problems.

In conclusion, the Factory Method is a powerful design pattern that can help you create more dynamic, flexible, and maintainable code. By following best practices and considering the key factors, you can create a Factory Method that provides many benefits and improves the overall quality of your code. Whether you are a beginner or an experienced developer, the Factory Method is a pattern that you should consider adding to your design toolbox.

Nginx Reverse Proxy in Localhost and Docker: A Comprehensive Setup Guide

ritwikmath — Tue, 18 Apr 2023 04:09:55 +0000

Introduction:

Creating a web application that is accessible to users from different locations while keeping their data secure is essential in today's digital world. In this blog post, we will guide you through the process of setting up a Nginx reverse proxy in Docker, with the frontend built using React and the backend using Node.js. We will provide a step-by-step guide to creating an Nginx reverse proxy that only allows access to the client and server through Nginx, without exposing any ports from Docker, making the application more secure. By the end of this blog post, you will have a comprehensive understanding of how to create a secure and robust web application that can handle traffic from all over the world, ensuring your users' data remains safe. So let's dive in and get started!

Prerequisites

Before getting started with the setup, there are a few prerequisites that need to be in place. Firstly, you will need to have Node.js and npm installed on your system to install and run the React and Node.js applications. Additionally, you will need to install Docker and Docker Compose, which will be used to set up the Nginx reverse proxy.
If you are unfamiliar with Nginx, it is a popular open-source web server that is used for serving web content, reverse proxying, and more. In this setup, we will use Nginx as a reverse proxy to manage incoming requests to the web application.

To begin, you need to create a directory that will serve as the root directory for the web application.

Setting up the Frontend with React:

To create a new React application, you can use the create-react-app CLI tool. Here's how you can run the command to create a new React app named client:

Open a terminal window in the root directory of your project.
Run the command npx create-react-app client. This will create a new React app in a directory named client.
Wait for the command to finish running. This may take a few minutes, depending on your internet speed and computer performance.
Once the command has finished running, you can navigate into the client directory by running the command cd client.
From here, you can start the development server by running the command npm start. This will open the app in your default web browser at http://localhost:3000.
Note that the name client is used in this example for the React app, but you can choose any other name that does not include the word react. This is because react is a reserved name and may cause conflicts with other packages.

Change directory to /client/src. Open your preferred code editor and load the file "App.js".

Final Client Code



import React, { useState } from 'react';
import './App.css';

function App() {
  const [users, setUsers] = useState([]);

  const fetchData = async () => {
    const response = await fetch('/api/users/');
    const data = await response.json();
    setUsers(data['users']);
  };

  return (
    <div className="App">
      <button onClick={fetchData}>Fetch User Data</button>
      {users.length > 0 && (
        <ul>
          {users.map((user) => (
            <li key={user._id}>{user.name}</li>
          ))}
        </ul>
      )}
    </div>
  );
}

export default App;

The provided code is an example of a React functional component that displays a button to fetch user data from a Node.js backend API. When the button is clicked, the component triggers the fetchData function using async/await syntax. The function makes a request to the /api/users endpoint of the Node.js backend, extracts the "users" property from the JSON response, and updates the "users" state variable using the setUsers function.

Setting up the Backend with Node.js:

To set up the backend of the web application, you need to create a folder named server and navigate to it using the command line. Next, you can run the command npm init -y to create a package.json file in the folder, which will be used to manage the project dependencies.

Afterwards, you will need to create two files in the server folder: server.Dockerfile and server.js. The server.js file contains the backend code that will be executed when you run the command npm start.

To add necessary functionality to the backend of the web application, you will need to install two Node.js modules, express and cors. Express is a popular web framework that simplifies the creation of server-side applications, while cors is a middleware that enables cross-origin resource sharing.

Also run, npm install --save-dev nodemon to install nodemon package as development dependency. Once nodemon is installed, you can use it to automatically restart your Node.js application whenever changes are made to the code. To start your application with nodemon, simply replace the node command with nodemon in your start script in package.json.



{
  "name": "server",
  "version": "1.0.0",
  "description": "",
  "main": "server.js",
  "type": "module",
  "scripts": {
    "start": "nodemon server.js",
    "prod": "node server.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "cors": "^2.8.5",
    "express": "^4.18.2"
  },
  "devDependencies": {
    "nodemon": "^2.0.22"
  }
}

Package.json has been modified to prevent the server from failing due to configuration errors.

Final Server Code



import express, { Router } from "express";
import cors from 'cors';

const app = express();
const port = 8000;

app.use(express.json());
app.use(express.urlencoded({ extended: true }));
app.use(cors());

const users = [
    {
        '_id': 1,
        'name': 'Ritwik Math'
    },{
        '_id': 2,
        'name': 'John Doe'
    },{
        '_id': 3,
        'name': 'Jane Doe'
    }
]

const promise = new Promise((resolve, reject) => {
    setTimeout(() => {
        resolve(users)
    }, 3000)
})

const route = Router();

route.get('/users', async (req, res, next) => {
    try {
        const data = await promise;
        return res.status(200).json({
            'message': 'Fetched successfully',
            'users': data
        })
    } catch (error) {
        console.log(error.message)
    }
});

app.use(route);

app.listen(port, () => {
    console.log(`App is running on http://localhost:${port}`)
})

This code creates a new Promise that resolves with an array of users after a 3-second delay. Then, an HTTP route is defined using the Express.js Router. This route listens for GET requests to the /users endpoint and uses async/await syntax to fetch the users data from the Promise and return it as a JSON response. When a user makes a GET request to the /users endpoint, the async function defined for this route is executed. This function waits for the Promise to resolve using await, and then returns a JSON response with the fetched data. If the Promise is rejected for any reason, the catch block will execute and log the error message to the console. This code demonstrates how Promises can be used to handle asynchronous operations in JavaScript, and how async/await syntax can make it easier to write asynchronous code that looks and behaves more like synchronous code.

Test result

Open the App.js file of your React app in a code editor.
Find the part of the code where the URL for the API endpoint /api/users is defined.
Change the URL in this code to http://localhost:8000/users. Make sure you save the file after making the change.
Start your React app by running the command npm start in your terminal.
Open your web browser and navigate to http://localhost:3000 (or the URL your app is running on).
If everything is working properly, you should see a list of users displayed in the browser that is fetched from the http://localhost:8000/users endpoint. If you see the list, congratulations! You've successfully setup the backend and front end.

Change the url back to /api/users.

Setting up the Nginx Reverse Proxy in Localhost:

This example requires setting up nginx configuration using port 80. Ensure that port 80 is available on your system, or choose a different port. If you use a different port, remember to include it in the URL, for instance, /api/users:81.

To implement reverse proxy using nginx container, create a directory named nginx and within it, create a file named nginx.conf. This file will be active in the nginx container.



server {
    listen 80;

    location / {
        proxy_pass http://127.0.0.1:3000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:8000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

To load the Nginx configuration from the appropriate directory, you need to copy the nginx.conf file to /etc/nginx/conf.d. To do this, run the following command with sudo privileges: sudo cp nginx/nginx.conf /etc/nginx/conf.d/. Default .conf file of nginx loads configirations from this directory.
The setup acts as a reverse proxy on the local host, enabling access to the client side via http://localhost and the server side via http://localhost/api. The client and server upstream are designated as http://127.0.0.1:3000/ and http://127.0.0.1:8000/ respectively.

Docker Environment Setup

Create client.Dockerfile and server.Dockerfile in client and server directory respectively. To establish the necessary Docker environment, we've taken a few important steps. First, we've configured the Dockerfile for both the client and server components. Additionally, we've crafted a customized docker-compose file that will orchestrate the deployment and operation of the entire application stack. By leveraging these foundational components of Docker's infrastructure, we can ensure a streamlined, efficient and scalable approach to our software deployment process.

client.Dockerfile



FROM node:18

WORKDIR /app

COPY ./ ./

RUN npm install

EXPOSE 3000

CMD ["npm", "run", "start"]

server.Dockerfile



FROM node:18

WORKDIR /app

COPY ./  ./

RUN npm install

EXPOSE 8000

CMD ["npm", "run", "start"]

Above two Dockerfiles used to build a Docker image for a React and Node.js applications respectively.

FROM node:18 specifies the base image to use for this application. In this case, it uses the official Node.js Docker image with version 18.
WORKDIR **/app** sets the working directory of the container to /app. This is where the application code and files will be stored.
COPY ./ ./ copies the contents of the current directory (where the Dockerfile is located) to the container's working directory. This includes the application code and files.
RUN npm install runs the npm install command in the container. This installs all the dependencies required by the application.
EXPOSE 8000 exposes port 8000 of the container to the docker network. This means that the application running in the container can be accessed through this port in Docker network.
CMD ["npm", "run", "start"] specifies the command to run when the container is started. In this case, it runs the npm run start command, which starts the application. This command will be executed automatically when the container is launched. Create docker-compose.yml in root directory. The purpose of docker-compose.yml is to define and orchestrate the deployment and operation of multiple Docker containers that work together to make up a complete application stack. It enables developers to define and configure the various services required by the application, including their dependencies and networking, in a single file. This makes it easier to manage and deploy complex applications in a consistent and repeatable manner. ```yaml

networks:
dev:
driver: bridge

Above markup creates a docker network dev. Now add all the applicaions (services) under `services` block.
```yaml


services:
  server:
    build:
      context: ./server
      dockerfile: server.Dockerfile
    image: dev-server
    container_name: dev_server
    tty: true
    restart: unless-stopped
    working_dir: /app
    volumes:
      - ./server:/app
      - /app/node_modules
    networks:
      - dev

Above configuration shows a "server" service defined within a docker-compose.yml file. Let's take a closer look at each configuration option:

build: Specifies how the container image will be built. In this case, it references a Dockerfile located in the ./server directory.
image: Specifies the name for the resulting image that will be created from the Dockerfile.
container_name: Sets the name for the running container. In this case, it's set to "dev_server".
tty: Allocates a pseudo-TTY for the container, which is necessary for certain interactive processes.
restart: Defines the restart policy for the container. In this example, the container will be automatically restarted unless it is explicitly stopped.
working_dir: Sets the working directory for the container. In this case, it's set to "/app".
volumes: Defines the volumes to be mounted in the container. In this example, the server directory is mapped to the /app directory in the container, and the /app/node_modules directory is mounted as a named volume.

networks: Specifies the network to which the container will be connected. In this example, it's connected to the "dev" network.

docker-compose.yml



networks:
  dev:
    driver: bridge

services:
  nginx:
    image: nginx:stable-alpine
    container_name: nginx
    restart: always
    ports:
      - "80:80"
    volumes: 
      - ./nginx:/etc/nginx/conf.d/
    networks:
      - dev

  server:
    build:
      context: ./server
      dockerfile: server.Dockerfile
    image: dev-server
    container_name: dev_server
    tty: true
    restart: unless-stopped
    working_dir: /app
    volumes:
      - ./server:/app
      - /app/node_modules
    networks:
      - dev

  client:
    build:
      context: ./client
      dockerfile: client.Dockerfile
    image: dev-client
    container_name: dev_client
    tty: true
    restart: unless-stopped
    working_dir: /app
    volumes:
      - ./client:/app
      - /app/node_modules
    networks:
      - dev

Change the nginx.conf within nginx directory to following.
nginx.conf



upstream client {
  server client:3000;
}

upstream server {
  server server:8000;
}

server {
    listen 80;

    location / {
        proxy_pass http://client/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /api/ {
        proxy_pass http://server/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

In a Docker network, containers can communicate with each other by their container names as if they were hostnames. When you define a service in a Docker Compose file, a network is automatically created and all the containers for that service are connected to that network.
In the context of Nginx, an upstream block defines a group of servers that can be used as a proxy for client requests. It is typically used when you want to distribute incoming traffic across multiple servers or when you want to implement a load balancer.

Run sudo docker compose up -d where docker-compose.yaml is located. The docker-compose up -d command is used to start Docker containers defined in a Docker Compose file in the background and detach the terminal from the container's console output. Access the client side through http://localhost/

Docker Stats

Forem: ritwikmath

Python Design Patterns Cookbook: Recipes for Clean and Reusable Code (Facade)

Design Patterns: An Introduction and Explanation

Facade Design Pattern

Introduction

Issue You May Face

A Logical Solution

Using Facade Design Pattern

Code Example

Differences with Factory Design Pattern

Factors Should be Taken into Consideration

Conclusion

Python Design Patterns Cookbook: Recipes for Clean and Reusable Code (Factory Method)

Design Patterns: An Introduction and Explanation

Factory Design Pattern

Introduction

Issue You May Face

A Logical Solution

Using Factory Method

Code Example

Why not Simple if-else?

Factors Should be Taken into Consideration

Conclusion

Nginx Reverse Proxy in Localhost and Docker: A Comprehensive Setup Guide

Introduction:

Prerequisites

Setting up the Frontend with React:

Setting up the Backend with Node.js:

Setting up the Nginx Reverse Proxy in Localhost:

Docker Environment Setup

Resources: