Forem: Abraão Duarte

Simple Node Application with Docker + Nginx + Postgres + Docker Compose

Abraão Duarte — Tue, 11 Jun 2024 12:07:00 +0000

Hi everyone, this is my first time trying to create a small tutorial where I will show how to run a Node application with Docker, Nginx with load balancing, Postgres, and Docker Compose. If you have any feedback at the end, please let me know; I will appreciate it. Also, English is not my native language, so if you find grammar errors, sorry about it.

I will assume that you have Docker and Docker Compose installed on your machine. This tutorial was made on Ubuntu OS.

If you don't have Docker and Docker Compose installed, you can visit the Docker website to see how to install Docker. For Docker Compose, you can check this link: Docker Compose.

Let's get down to business.

1 - Create a route using Hono.js

Hono.js is a nice framework that helps us build Node apps. This article does not aim to teach Hono.js; I will create a simple route to print Hello World!

First, create a new folder on your machine using the command line:



~ mkdir example

Enter your folder and let's install some libraries. I will be using pnpm, a package manager like npm or yarn but with some differences. If you don't have it installed, you can access the straightforward instructions in the documentation: pnpm

Install hono and typescrypt



~ pnpm init // To create the initial package.json
~ pnpm install hono
~ pnpm install @hono/node-server
~ pnpm install -D typescript

After installing these packages, you should run the command below to create a default tsconfig.json, which is the TypeScript configuration of the project.



~ npx tsc --init

Now create a folder called src, and inside it, create the file server.ts:



~ mkdir src
~ touch src/server.ts

In the server.ts add the code below.



1 import { Hono } from "hono";
2 import { serve } from "@hono/node-server";
3 import { logger } from "hono/logger";
4
5 const Server = {
6     start: () => {
7         const app = new Hono();
8         app.use(logger());
9 
10        app.get("/", (c) => c.text("Hello World!"));
11
12        serve(
13            {
14                port: 3000,
15                fetch: app.fetch,
16            },
17            (info) => {
18                console.log(`Listening on http://localhost:${info.port}`);
19            },
20        );
21    },
22 };
23
24 Server.start();

Here we have a simple server that will provide an endpoint returning "Hello World!".

You should install the tsx package to run the server:



~ pnpm install -D tsx

And in the package.json under the scripts section, we add this line:



"start": "npx tsx ./src/server.ts"

Now in your terminal you can run:



~ pnpm start

Now our app is running. You just need to open your browser and go to the address http://localhost:3000/ and you will see the page with the Hello World!.

2 Configure docker for our server

Now we will configure a Dockerfile for our app. I will not explain the Docker syntax in detail, but this is a simple Dockerfile.

In the root of the project create a Dockerfile



~ touch Dockerfile

Now put this code inside the Dockerfile:



1 FROM node:22-alpine
2
3 COPY . /app
4
5 WORKDIR /app
6
7 RUN npm install -g pnpm
8
9 RUN pnpm install
10
11 EXPOSE 3000
12
13 CMD ["pnpm", "start"]

1 - FROM - This will tell the name of the image that we want to use.
2 - COPY - We are making a copy of everything from our project and putting in the app folder from our container.
3 - Workdir - We tell the container from what folder we want to execute our commands.
4 - RUN - We use this to install dependencies inside our container, in this case we are installing pnpm.
5 - EXPOSE - Here we say what port our container will use. PS: Is not the port of our machine (host).
6 - CMD - We pass which commands the container should run at the end.

Now create the build from our dockerfile:



~ docker build -t my-server:1.0 . // You can put the name you want

The dot . is for the command run the Dockerfile from the folder you are.

If you want to see the container just use the command:



~ docker ps -a

Now run the container with this command:



~ docker run my-server:1.0

Access the http://localhost:3000/ you will see a problem:

We cannot access the address because the app is running only inside the container, and we didn't specify which port from our machine the container should use.

Let's try again, but now mapping the port from the container to a port on our machine (host):



~ docker run -p 3000:3000 my-server:1.0

Now if you access the http://localhost:3000/ you'll see that the app running because we told Docker to map port 3000 from the container to port 3000 on our machine. PS: You could use another port here if you want.

Now the app is working with Docker; let's configure Nginx.

3 - Configure Nginx with load balancing

Nginx is an open-source web server software used for reverse proxy, load balancing, and caching.

In the root of the project, create a new folder called nginx , and inside it, create the Dockerfile.



~ mkdir nginx
~ touch nginx/Dockerfile

Before we configure Nginx, let's see it working on our machine. Put this code inside the Dockerfile.



1 FROM nginx:latest
2
3 EXPOSE 80

Here we are getting the latest image from nginx from Dockerhub and exposing the port 80 from the container. Now we can build and run it. Go to the nginx folder in your terminal and run:



~ docker build -t my-server-nginx:1.0 . // My container will have the name my-server-nginx:1.0
~ docker run -p 9000:80 my-server-nginx:1.0

The second command runs our Nginx, listening to port 9000 on our machine. If you access http://localhost:9000/ you'll see the page:

Now let's configure load balancing for our Nginx. First, inside the nginx folder, create nginx.conf



~ touch nginx.conf

Let's edit the ´nginx.conf' and add these lines:

The upstream backend is responsible for our load balancing. Load balancing is a technique that distributes network traffic across multiple servers to prevent bottlenecks and improve performance. For more information, you can visit this link.

PS: The proxy_pass domain (line 18) should match the name you put in the upstream (line 7), in this case, backend.

In the upstream, we specify that we'll have two servers. Every time we access http://myserver.local Nginx will redirect the request to one of these two servers, preventing server overload.

In the Nginx Dockerfile, we can add a new line after the instruction FROM:



COPY ./nginx.conf /etc/nginx/nginx.conf

Your Dockerfile should look like this:

To make it easy to run everything together, let's configure Docker Compose.

4 - Configure Docker Compose

In the root of the project, create docker-compose.yml and add the code below:



version: '3.9'

services:
  app:
    build: 
      context: .
    volumes:
      - ./:/usr/app
      - /usr/app/node_modules
    ports:
      - 3000:3000
    networks:
      - app-network

  app2:
    build: 
      context: .
    volumes:
      - ./:/usr/app
      - /usr/app/node_modules
    ports:
      - 3001:3000
    networks:
      - app-network

  nginx:
    build:
      context: ./nginx/.
    container_name: my-server-nginx
    ports:
      - "80:80"
    depends_on:
      - app
      - app2
    networks:
      - app-network

networks:
  app-network:
    driver: bridge

Note that we have two instances or containers for our server, app and app2. If you change these names, you'll need to change the name in the nginx.conf inside the upstream.

Also, in nginx.conf inside the upstream, you should put the port that you exposed in your container, in our case, 3000. I don't know why, but when I tried to put the port of my machine, it didn't work.

To access http://myserver.local/ you will need to edit your /etc/hosts file.



~ sudo vim /etc/hosts

At the end of the file, add this line:



127.0.0.1 myserver.local

Now save the file and try to exit from vim 🤣

In your terminal run:



~ docker-compose up

This command will start the apps and Nginx. Now you can access the route at http://myserver.local/, and every time you refresh the page, you will see that the request is sent to one of the servers, sometimes to app and sometimes to app2.

5 - Configure Postgres

I will not connect the app with the database; I will show just how to set up Postgres, and you can connect as you wish.

In our docker-compose.yml, add the following lines after the Nginx section:



postgres:
    container_name: postgres
    restart: always
    image: postgres
    ports:
      - 5432:5432
    environment:
      POSTGRES_USER: docker
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: myserver
    networks:
      - app-network
    volumes:
       - postgres:/data/postgres


volumes:
    postgres:

You can stop the containers using this command and start again:



~ docker-compose down // stop the containers
~ docker-compose up

To view your database, you can install dbeaver I have been using DBeaver for a long time (thanks bop for recommending it 🙏🏻).

Notice that we have three environment variables that Docker will use. You can change their values if you want.

In DBeaver, you can click on new database connection, select Postgres, and fill in the database, password, and user fields with the values with environment variables in the docker-compose.yml.

Notice that the:
1 - host = localhost # default
2 - username = docker # This comes from POSTGRES_USER inside docker-compose.yml
3 - password = postgres # This comes from POSTGRES_PASSWROD inside docker-compose.yml
4 - database = myserver # This comes from POSTGRES_DB inside docker-compose.yml

With all this, you will have a simple start project with hono.js + nginx + postgres + docker.

And that's it, folks! Thank you for reading this far. If you liked the post, please give it a like.

If you have feedback or questions, let me know.

Repository: github

SDG

CLEAN CODE - BOAS PRÁTICAS

Abraão Duarte — Thu, 10 Jun 2021 22:29:10 +0000

Atualmente estou lendo o livro Clean Code, escrito por Robert C. Martin, conhecido como Uncle Bob, por isso, decidi escrever um artigo com algumas dicas importantes que encontrei na leitura e que tem me motivado a escrever códigos melhores.

Boa parte do tempo dos desenvolvedores de software é gasto escrevendo códigos, portanto devemos ter um cuidado em como escrevemos esses códigos, nós nos expressamos por meio dos códigos que escrevemos e, eles devem ser legíveis e de fácil compreensão.

Talvez você já tenha percebido que nos passamos grande parte de nosso tempo dando manutenção, seja em sistemas legados e antigos, seja nos nossos próprios códigos que escrevemos a pouco tempo, estamos sempre acrescentando algo novo, corrigindo erros, melhorando, etc. Justamente por causa disso que devemos nos esforçar por escrever códigos melhores, mais legíveis, para que a manutenção e mesmo a evolução do sistema seja mais fácil e menos dolorosa.

Quando nos deparamos em situações onde precisamos dar manutenção em algum código ruim, essa tarefa pode ser tornar demorada, difícil e cara, pois iremos gastar um tempo maior do que gastaríamos caso esse código estivesse mais legível 😠. E já vou adiantando, escrever código limpo não é uma tarefa simples e fácil, antes é algo trabalhoso, em outras palavras, você irá suar a camisa, nesse processo você irá errar, e também ver outros errarem, mas não desanime. No fim das contas como o próprio autor do livro diz:

Escrever código limpo é uma arte e vai tempo e prática. 😲

O que seria um código limpo? Juntando algumas definições que encontrei no livro, pode se dizer que: ‘um código limpo é elegante e eficiente, que faz somente uma coisa, aquilo que ele se propõe a fazer. É algo simples e direto, legível e claro. É um código bem testado, bem escrito’.

Para escrever código limpo precisamos estar atentos aos detalhes, pois eles são importantes e no fim das contas fazem a diferença.

Dado essa introdução, irei apresentar algumas sugestões que encontrei no livro e que acho válido compartilhar, os códigos de exemplo estarão em Javascript, porém os conceitos podem ser aplicados em qualquer linguagem.

Nomes são importantes, portanto seja cuidadoso.

Você já deve ter se deparado com nomes de variáveis, funções, métodos que eram obscuros e difíceis de compreender. Para entendermos esses nomes, gastamos um tempo maior que gastaríamos se o nome estivesse claro. Isso mostra que dar nomes corretos e claros fazem diferença.

1. Use nomes que revelam seu propósito.

Um nome deve ter significado que diz o que ele faz ou ao que ele se refere. Se um nome precisa de um comentário, então ele já não revela seu proposito.

Exemplo ruim: 🙈

const d = new Date();
const y = d.getYear();
const m = d.getMonth();

Exemplo bom: 😁

const date = new Date();
const year = d.getYear();
const month = d.getMonth();

2. Use distinções significativas

Exemplo ruim: 🙈

getDetails();
getData();
getRecord();

Às três funções parecem ser a mesma coisa, não existe uma distinção clara que diz o que essa função está fazendo.

Um exemplo melhor pode ser o seguinte: 😁

getUser(); // É melhor que os exemplos acima.

3. Use nomes fáceis de se pronunciar, ou pelo menos que sejam pronunciáveis.

Você já se deparou com nome de variáveis que são impronunciáveis? Isso é uma má prática.

Veja o seguinte exemplo: 🙈

const yyyymmdstr = ‘2021-06-09’;

É uma variável que não tem como pronunciar seu nome. Poderíamos rescrever da seguinte maneira: 😁

const currentDate = ‘2021-06-09’;

4. Use nomes que sejam fáceis de se buscar.

Por exemplo, nomes de uma letra só: const d = new Date(); são difíceis de se pesquisar e irá trazer uma infinidade de resultados

Outro exemplo: 🙈

setTimeout(blastOff, 86400000);

Pesquisar por número que não trazem nenhum significado não, é algo muito bom, e podem acabar retornando resultados inesperados, podemos escrever da seguinte maneira: 😁

const MILLISECONDS_PER_DAY = 86400000;

setTimeout(blastOff, MILLISECONDS_PER_DAY);

Dessa maneira você pode pesquisar pelo nome da variável e também está claro o que esse numero representa.

5. Nomes de classes devem ter nomes com substantivos

Exemplo: 😁

class User {}
class Customer {}

6. Nome de métodos é uma boa prática ter verbos

Exemplo: 😁

getUser();
deleteUser();
handleVote();

Escreva funções melhores

Estamos escrevendo funções a todo momento, é importante que essas sejam claras e legíveis.

Funções devem ser pequenas, você já deve ter se deparado em algum momento com funções com dezenas de linhas, que fazem várias coisas. Funções assim são difíceis de dar manutenção, pois é difícil entende-las.

Algumas dicas para escrever funções melhores

1. Faça apenas uma coisa

Funções devem fazer somente uma coisa e devem fazê-la bem.

Uma boa forma de sabermos se nossa função faz mais de uma coisa é se conseguimos extrair outras funções dela.

Exemplo ruim: 🙈

function emailClients(clients) {
    clients.forEach(client => {
        const clientRecord = database.lookup(client);
        if (clientRecord.isActive()) {
            email(client);
        }
    });
}

Essa função tem mais de uma responsabilidade, ela pega os dados do cliente e verifica se o cliente está ativo.

Poderíamos separar da seguinte maneire: 😁

function emailActiveClients(clients) {
    clients.filter(isActiveClient).forEach(email);
}

function isActiveClient(client) {
    const clientRecord = database.lookup(client);
    return clientRecord.isActive();
}

Veja, cada função é responsável por fazer apenas 1 coisa.

As funções devem fazer uma coisa. Devem fazê-la bem. Devem fazer apenas ela. 😲

2. Um nível de abstração por função

Vários níveis de abstração dentro de uma função sempre geram confusão.
Exemplo: 🙈

function parseBetterJSAlternative(code) {
    const REGEXES = [ // ... ];
    const statements = code.split(" ");
    const tokens = [];
    REGEXES.forEach(REGEX => {
        statements.forEach(statement => { // ... });
    });
    const ast = [];
    tokens.forEach(token => { // lex... });
    ast.forEach(node => { // parse... }); }

Veja essa função, é difícil entender o que acontece mesmo ela sendo pequena. Imagina uma função com o triplo do tamanho, fazendo várias coisas, é difícil dar manutenção nessas funções.

Veja como poderíamos escrever: 😁

function parseBetterJSAlternative(code) {
    const tokens = tokenize(code);
    const syntaxTree = parse(tokens);
    syntaxTree.forEach(node => { // parse... });
}

function tokenize(code) {
    const REGEXES = [ // ... ];
    const statements = code.split(" ");
    const tokens = [];
    REGEXES.forEach(REGEX => {
        statements.forEach(statement => {
            tokens.push(/* ... */);
        });
    });
    return tokens;
}

function parse(tokens) {
    const syntaxTree = [];
    tokens.forEach(token => {
        syntaxTree.push(/* ... */);
    });
    return syntaxTree;
}

3. Use nomes descritivos

Mesma regra que usamos para variáveis, que sejam claro e legível e diga o que a função faz.

Não tenha medo de criar nomes extensos, pois eles são melhores que um pequeno e enigmático.

4. Parâmetros de funções

Devemos evitar passar vários parâmetros para uma função, o ideal é que nossas funções recebam no máximo 2 parâmetros.

Veja o seguinte exemplo: 🙈

function createMenu(title, body, buttonText, cancellable) {
    // doSomething
}
createMenu("Foo", "Bar", "Baz", true);

Veja que é confuso e muito fácil esquecer de passar um parâmetro e quebrar a função.

Prefira fazer assim: 😁

function createMenu({ title, body, buttonText, cancellable }) {
    // doSomething
}
createMenu({
    title: "Foo",
    body: "Bar",
    buttonText: "Baz",
    cancellable: true
});

Dessa maneira fica mais clara, você sabe o que é o que.

5. Parâmetros lógicos

Parâmetros lógicos é uma má prática, pois mostra explicitamente que a função faz mais de uma coisa.

Veja: 🙈

function createFile(name, temp) {
    if (temp) {
        fs.create(`./temp/${name}`);
    } else {
        fs.create(name);
    }
}

O parâmetro temp é um booleano, isso implica que a função tem mais de uma responsabilidade.

Poderíamos fazer: 😁

function createFile(name) {
    fs.create(name);
}

function createTempFile(name) {
    createFile(`./temp/${name}`);
}

Veja que evitamos passar valores booleanos como parâmetro de função.

6. Evite efeitos colaterais

Efeitos colaterais são mentiras. Sua função promete fazer apenas uma coisa, mas ela também faz outras coisas escondidas.

Efeitos colaterais são perigosos, e muitas vezes difíceis de se identificar.

Veja esse exemplo: 🙈

let name = "Ryan McDermott";

function splitIntoFirstAndLastName() {
    name = name.split(" ");
}
splitIntoFirstAndLastName();
console.log(name);

A variável name está sendo modificada na função splitIntoFirstAndLastName isso é ruim, pois em um arquivo com dezenas de linhas, você se perderia para encontrar os lugares onde essa variável está sendo modificada. Você não saberia qual é o valor de name uma vez que em cada função ela pode ter um valor.

Evite variáveis globais.

Veja como poderíamos fazer: 😁

function splitIntoFirstAndLastName(name) {
    return name.split(" ");
}
const name = "Ryan McDermott";
const newName = splitIntoFirstAndLastName(name); console.log(name); // 'Ryan McDermott';
console.log(newName); // ['Ryan', 'McDermott'];

A variável name é um parâmetro da função, e assim não tem nenhum efeito colateral ao alterar esse parâmetro na função.

7. Evite repetição

Duplicação de código pode ser um grande mal no seu software, sempre que você ver que você está repetindo muito código, extraia isso para funções.

Escreva comentários com responsabilidade

Por vezes o uso de comentários é para compensar o nosso fracasso em nos expressar no código.

É melhor você ter um código legível com poucos comentários do que um código complexo, difícil de ler com vários comentários.

Não insira comentários em um código ruim, refatore ele.

Comentários imprecisos são muito piores do que nenhum. O único lugar onde pode-se encontrar a verdade é no código. Só ele pode dizer o que ele realmente faz, comentários podem mentir.

Comentários ruins

Comentários esquecidos no código.
Comentários redundantes, por exemplo:

    // Function that get users
    const getUsers = () => {...}

Comentários longos
Comentários ruidosos

    // Return the day of month
    const getDayOfMonth = () => {...}

Códigos como comentários

Conclusão

A conclusão é que se você é um programador você deveria se importar com seu código, se seguirmos essas dicas, ou pelo menos algumas delas, já estaremos escrevendo códigos melhores.

Ao escrever código limpo estaremos ajudando futuras pessoas que venham dar manutenção no nosso código, e também estaremos ajudando a nós mesmo, caso no futuro tenhamos que dar manutenção no código que fizemos.

Este é apenas alguns pontos que eu achei interessante nos primeiros 4 capítulos do livro, espero ainda trazer mais alguns artigos a respeito do assunto.

Fonte

Martin, Robert C. Código Limpo: Habilidades práticas do agile software. Ed. Revisada São Paulo: Alta Books, 2011.

Exemplos: https://github.com/ryanmcdermott/clean-code-javascript