DEV Community: Marcelo Albuquerque

Utilizando Pool de conexões com MySQL2 em uma aplicação Next.js

Marcelo Albuquerque — Sun, 12 Nov 2023 20:26:42 +0000

Uma breve análise da utilização do Pool de conexões do MySQL.

Considerações

Next.js com a App Router
Banco de dados MySQL utilizando Amazon RDS for MySQL
Pacote MySQL2

Explicando o Problema

Trabalhando em uma aplicação comecei a receber uma mensagem de erro muito incomoda: Too many connections, o código errno é o 1040.

Bem, obviamente havia algo errado. Antes de analisar o código da função para conexão ao bando de dados, observei que minha aplicação realizava muitas chamadas desnecessárias, então passei a guardar algumas informações em states e trabalhei na otimização geral do código da aplicação.

Essa etapa foi muito importante, pois não podemos simplesmente sair disparando chamadas para o banco de dados de forma irresponsável.

Então enfim cheguei no código da função que realiza a conexão com o banco de dados e comecei a verificar - antes de realizar qualquer mudança - a quantidade conexões ao banco de dados toda vez que carregava a aplicação:

show status where `variable_name` = 'Threads_connected';

O que observei foi um número crescente de conexões, que invariavelmente poderia chegar ao limite do meu banco de dados na AWS, utilizo o Amazon RDS for MySQL.

Analisando a implementação atual

Agora observe o meu código de conexão ao banco de dados:

// libs/mysql/index.ts

import mysql from 'mysql2/promise';

/*
  Com essa implementação, o número de conexões precisa ser muito controlado.
*/
export async function MySQL() {
  const connection = await mysql.createConnection({
    host: process.env.MYSQL_HOST,
    user: process.env.MYSQL_USERNAME,
    database: process.env.MYSQL_DATABASE,
    password: process.env.MYSQL_PASSWORD
  });

  return connection
}

O detalhe principal é que estou utilizando o método createConnection. E esta implementação precisa ser cuidadosamente estudada para ser implementada, pois toda chamada a ela irá gerar uma nova conexão ao banco de dados e claramente atingir o limite passa a ser apenas uma questão de tempo ou simplesmente de escalabilidade da aplicação.

Então comecei a ir atrás de soluções, estudar um pouco mais sobre implementações de conexão ao banco de dados MySQL.

Já havia ouvido sobre Pool de Conexões, mas nunca dei a devida atenção.

Um pool de conexões é um cache de conexões de banco de dados que são compartilhadas e reutilizadas para melhorar a latência e o desempenho da conexão. Quando seu aplicativo precisa de uma conexão de banco de dados, ele pega uma emprestada do pool temporariamente. Assim que ele termina de usar a conexão, ela é devolvida ao pool para ser reutilizada da próxima vez em que o aplicativo precisar de uma conexão de banco de dados.

Aplicando a solução

Ótimo, conceitualmente é fantástico. A biblioteca que utilizo: MySQL 2 possuí este recurso, então bastava implementar e realizar os testes:

// /libs/mysql/index.ts

import mysql from 'mysql2'

export async function MySQL() {
  const connection = mysql.createPool({
    host: process.env.MYSQL_HOST,
    user: process.env.MYSQL_USERNAME,
    database: process.env.MYSQL_DATABASE,
    password: process.env.MYSQL_PASSWORD
  });

  const pool = connection.promise()

  return pool
}

Observe que agora estou utilizando o método createPool.

Estou exportando uma função assíncrona, observe que a connection gera uma promise.

Vou deixar aqui apenas um exemplo de como utilizar esse Pool de conexões para gerar uma consulta no banco de dados:

// /api/consulta/route.ts

import { NextRequest, NextResponse } from 'next/server'
import MySQL from '/libs/mysql'

export async function GET( req: NextRequest ) {
  try {
    const mysql = await MySQL()

    const query = `SELECT * FROM produtos`
    const [ rows ] = await mysql.execute( query )

    // Extremamente importante. Encerrar a conexão.
    await mysql.end()

    return NextResponse.json( rows )
   } catch ( error ) {
    return NextResponse.json( error )
   }
}

Conclusão

Ao passar a utilizar o Pool de conexões observei que o número de conexões ao banco de dados diminuiu drasticamente, utilizando basicamente apenas uma única conexão.

Algo extremamente importante nessa implementação é o encerramento da conexão: await mysql.end() principalmente utilizando funções assíncronas, caso contrário, o resultado seria o mesmo de utilizar o método createConnection.

Infelizmente não dediquei o devido tempo ao estudo do MySQL, com certeza teria percebido esse problemas antes, mas deixo aqui para aqueles que de alguma forma possam estar enfrentando problemas semelhantes.

Comandos SQL que podem ser úteis

Exibir a quantidade de conexões ao banco de dados:

SHOW STATUS WHERE `variable_name` = 'Threads_connected';

Para analisar a proveniência das conexões:

SHOW processlist

Exibe o número máximo de conexões que seu banco de dados suporta:

SHOW VARIABLES LIKE "max_connections";

Referências

Também quero destacar uma postagem no Medium que me foi de grande ajudar, até considero que essa postagem deveria fazer parte da documentação oficial do MySQL 2. O autor se chamar Jorgen Lundgren.

Também obtive ajuda em uma pergunta no Stack Overflow onde nas respostas os usuários citaram diversos comandos úteis para o MySQL.

Implementando Editor.js com Next.js utilizando Typescript

Marcelo Albuquerque — Sun, 05 Nov 2023 22:17:37 +0000

Basicamente o Editor.js é um WYSIWYG editor. Tenho certeza que irá se surpreender com essa solução e ficar ainda mais impressionado sabendo que é gratuíta. E ao meu ver está muito a frente de outras soluções pagas.

Conheça o Editor.js. E também considere fazer uma doação para o projeto. São poucos projetos gratuítos com esse nível de qualidade.

A proposta deste tutorial é mostrar sua implementação com o Next.js utilizando Typescript.

Vamos utilizar o App Router.

Criando o componente Editor

Primeiramente vamos construir um componente que irá exportar uma div onde o Editor.js será renderizado após a tela estar pronta para o usuário.

// components/Editor.tsx

'use client'

import { useRef } from 'react';

import EditorJS from '@editorjs/editorjs'

// Esta função irá garantir que o componente seja renderizado uma única vez
const RenderEditor = ( ElementId: string ) => {
  const rendered = useRef<false | true>( false )

  if ( !rendered.current ) {
    rendered.current = true;

    // Aqui chamamos a execução do EditorJS e também podemos passar os parâmetros necessários para execução
    new EditorJS({
      holder: ElementId
    });
  } else {
    return
  }
}

export default function Editor() {
  const elementId = 'editorjs' // Defina aqui o ID para o elemento onde o Editor.js será renderizado

  RenderEditor( elementId )

  return (
    <div id={ elementId }></div>
  )
}

Importando o Componente

Para importar o componente vamos utilizar o next/dynamic.

Essa implementação se faz necessária para evitar erros na execução do Editor.js, lembrando que oficialmente não existe um componente React, mas podemos construir nosso próprio componente e utilizar sem nenhum problema.

// page.tsx

import dynamic from "next/dynamic";

const Editor = dynamic(() => import("components/Editor"), {
  ssr: false,
  loading: () => <p>Loading ...</p>,
})

export default async function Page() {
 return(
   <Editor />
 )
}

Com essa implementação o Editor.js deverá ser executado sem erros no seu Fron-end.

Gostaria de destacar uma resposta no Stackoverflow que me auxiliou na construção da função que garante que o Editor.js será renderizado uma única vez.

Até mais!!!

Como exportar base de dados utilizando MySQLWorkbench para AWS RDS

Marcelo Albuquerque — Fri, 03 Nov 2023 19:17:53 +0000

Após realizar o export de uma base de dados que possuo na AWS RDS e tentar importá-la recebi a seguinte mensagem de erro:

Access denied; you need (at least one of) the SUPER privilege(s) for this operation

O problema está no processo de exportação, devemos desativar uma diretiva que por padrão está em AUTO:

set-gtid-purged - Add 'SET @@GLOBAL.GTID_PURGED' to the output.

No painel de exportação, no canto superior direito, encontramos a opção: Advanced Options.... Ao acessá-la devemos alterar o valor da diretiva para OFF.

Resolvendo problema ao realizar migração de dados utilizando a opção Migration Wizard no MySQLWorkbench no MacOS

Marcelo Albuquerque — Fri, 03 Nov 2023 19:00:41 +0000

Ao iniciar o processo de migração tudo transcorre normalmente até chegar ao processo "STEP BULK DATA TRANSFER" onde recebemos o seguinte erro:

dyld: Library not loaded: @executable_path/../Frameworks/libmysqlclient.dylib
  Referenced from: /Applications/MySQLWorkbench.app/Contents/MacOS/wbcopytables
  Reason: no suitable image found.  Did find:
    file system relative paths not allowed in hardened programs

ERROR: Determine number of rows to copy: Error getting row count from source tables, wbcopytables exited with code -6
Failed

Esse problema ocorre pois a instalação do MySQLWorkbench não cria o arquivo com o nome libmysqlclient.dylib, no lugar, a instalação cria outro arquivo com um nome semelhante: libmysqlclient.21.dylib.

Para resolver o problema, podemos simplesmente realizar uma cópia do arquivo libmysqlclient.21.dylib e renomeá-lo para libmysqlclient.dylib:

Podemos acessar o diretório Applications onde se localizam as aplicações instaladas e ao localizar o MySQLWorkbench devemos clicar com o botão direito do mouse e escolher a opção Show Package Content, assim podemos navegar dentro do pacote de instalação. Em seguida acessamos a pasta Content > Frameworks onde se localiza o arquivo libmysqlclient.21.dylib.

Basta realizar a cópia e renomeação do arquivo para tudo funcionar normalmente.

Auth0 getSession() com Typescript no Next.js

Marcelo Albuquerque — Wed, 25 Oct 2023 02:07:15 +0000

Para obter as informações do usuário logado em server-side o Auth0 dispõe da função getSession().

A função getSession() não retorna diretamente o objeto contendo as informações do usuário, primeiramente é preciso acessar o objeto user dentro de getSession().

Em Typescript isso pode trazer alguns problemas, pois esse objeto não está devidamente tipado.

A documentação do Auth0 nos orienta a desestruturar o objeto user:

import { getSession } from '@auth0/nextjs-auth0';

export default async function ProfileClient() {
  // Typescript Error: Property 'user' does not exist on type 'Session | null | undefined'.
  const { user } = await getSession();

  ...
}

Observe que a melhor forma, realmente seria a de desestruturar o objeto, em JavaScript nenhum erro será retornado, porém, em TypeScript o erro é claro.

Adotei a seguinte abordagem: Criei uma tipagem customizada idêntica a utilizada ao obter as informações do usuário em client-side. No lado do cliente podemos utilizar a função useUser() e desestruturar o objeto user, aqui a tipagem funciona perfeitamente, portanto, apenas copiei a tipagem correta.

import { getSession } from '@auth0/nextjs-auth0';

// Tipagem customizada idêntica a função `useUser()` do client-side
type userSessionProfileTypes = {
  email: string;
  name: string;
  nickname: string;
  picture: string;
  sub: string;
  updated_at: string;
  org_id: string;
}

export default async function ProfileClient() {
  const userSession = await getSession()

  if ( userSession !== undefined && userSession !== null ) {
    // Aqui podemos utilizar a tipagem customizada
    const user = userSession.user as userSessionProfileTypes

    ...
  }

  ...

Dessa forma podemos utilizar o objeto user e acessar facilmente suas chaves.

NextAuth - Implementando "Custom Login Pages" com "Credentials Sign in" utilizando App Router

Marcelo Albuquerque — Sun, 15 Oct 2023 17:11:55 +0000

Quero abordar um assunto muito específico relacionado a implementação de uma página de login personalizada com Credentials Sign in utilizando NextAuth com a estrutura App Router do Next.js.

Algo que ficou muito claro para mim é que o NextAuth foi construído para funcionar com a estrutura Pages Router do Next.js e sua compatibilidade com a App Router definitivamente não é a ideal.

Entendendo a lógica de funcionamento

Ao optar por utilizar uma página de login personalizada é preciso ficar atendo aos requisitos para tal. Afinal, aqui estamos optando por personalizar a experiência de Login de nossos usuários, o que de fato pode ser algo extremamente positivo, porém, também pode ser um tanto trabalhoso.

Quero focar na implementação do login com credenciais, onde defino uma lógica personalizada para verificar o usuário.

Vamos pensar no cenário onde necessitamos validar o nome e senha do usuário. A documentação do NextAuth nos orienta a criar um formulário relativamente simples, porém, com uma informação crucial: csrfToken.

<form method="post" action="/api/auth/callback/credentials">
    // Este campo recebe o csrfToken e é obrigatório, porém, é um campo oculto.
    <input name="csrfToken" type="hidden" defaultValue={ csrfToken } />
    <input id="email" name="email" type="email" placeholder="Digite seu Email" required />
    <input id="password" name="password" type="password" placeholder="Digite sua Senha" required />

    <button type="submit">Entrar</button>
</form>

O problema

Aqui reside o maior problema! Como obter o csrfToken? Bom, o NextAuth nos oferece uma função para obtê-lo: getCsrfToken(), conforme podemos ver na documentação. Essa função funciona muito bem na Pages Router do Next.js, porém, ela simplesmente não funciona na App Router. Não funciona pois ela retorna um token diferente do realmente definido pela aplicação.

Esse token é armazenado como um cookie em nosso navegador e é muito fácil fazer essa comparação.

Como obter o CSRF Token da forma correta

O Next.js nos oferece uma função para obter os cookies do navegador.

import { cookies } from 'next/headers'

export default async function SignIn() {
    const cookieStore = cookies()

    // Observe que estou utilizando uma variável de ambiente
    const csrfToken = cookieStore.get( `${ process.env.NEXTAUTH_CSRF_TOKEN }` )?.value.split( '|' )[0]

    return '...'
}

A explicação do código é relativamente simples, obtenho o cookie informando o seu nome e recupero a parte dele que realmente necessito.

O ponto principal aqui é que em desenvolvimento o nome do cookie é next-auth.csrf-token e em produção __Host-next-auth.csrf-token, por esse motivo defini uma variável de ambiente para informar o nome correto do cookie.

Essa é uma implementação simples que resolve o problema.

import { cookies } from 'next/headers'

export default async function SignIn() {
    const cookieStore = cookies()
    const csrfToken = cookieStore.get( `${ process.env.NEXTAUTH_CSRF_TOKEN }` )?.value.split( '|' )[0]

    return (
        <form method="post" action="/api/auth/callback/credentials">
            <input name="csrfToken" type="hidden" defaultValue={ csrfToken } />
            <input id="email" name="email" type="email" placeholder="Digite seu Email" required />
            <input id="password" name="password" type="password" placeholder="Digite sua Senha" required />

            <button type="submit">Entrar</button>
        </form>
    )
}

Resolvendo problema de "foreign key constraint" ao migrar o Ghost CMS da v4 para v5

Marcelo Albuquerque — Fri, 05 May 2023 23:59:07 +0000

Ao atualizarmos o Ghost para sua versão 5, diversos scripts de migração são executados, incluindo scripts que realizam alterações no Banco de Dados. E é justamente um desses scripts que ao não conseguir realizar uma mudança na base de dados, impossibilita a execução do Ghost.

Esse script tenta realizar uma mudança que afeta uma tabela com foreign key constraint , o que é bloqueado pelo Banco de Dados.

O script em questão, tenta executar o seguinte:

alter table `subscriptions` modify  `tier_id` varchar(24) not null

Podemos observar que ele tenta executar uma mudança na tabela subscriptions e nos retorna o seguinte erro:

Message: Ghost was able to start, but errored during boot with: alter table `subscriptions` modify  `tier_id` varchar(24) not null  - Cannot change column 'tier_id': used in a foreign key constraint 'subscriptions_tier_id_foreign'
Context: [object Object]
Help: Error occurred while executing the following migration: 2022-10-18-05-39-drop-nullable-tier-id.js

Para solucionar esse problema devemos desabilitar a checagem foreign keys antes de executar o script, após a execução da query podemos reabilitar a checagem normalmente. O script a seguir deve ser executado diretamente na base de dados de forma manual:

USE ghost_test; # Aqui seleciono a base de dados onde a tabela se encontra
SET foreign_key_checks = 0; # Desabilito as checagens foreign keys
alter table `subscriptions` modify  `tier_id` varchar(24) not null; # Executo a query que o Ghost tentou realizar
SET foreign_key_checks = 1; # Reabilito as checagens foreign keys

Agora, de volta ao Ghost, podemos executar o comando para iniciar sua execução:

ghost start

Processo finalizado!

Instalação e configuração do Strapi com Amazon Linux 2023

Marcelo Albuquerque — Wed, 03 May 2023 17:20:35 +0000

Nunca havia utilizado o Strapi de forma efetiva anteriormente, apenas realizei pequenos testes para tentar entender sua lógica. A instalação no ambiente local não oferece nenhum "desafio" por assim dizer, basta seguir a documentação oficial e nenhum problema deve surgir.

A coisa começa a ganhar contornos complexos de fato, no ambiente de produção, que é o foco desta documentação que vos escrevo.

Como em produção trabalho constantemente com o ambiente da AWS, esta documentação é focada no Amazon Linux 2023, que podemos simplesmente considerá-la como uma distribuição Linux desenvolvida pela AWS, bem como a Amazon Linux 2. São sistemas desenvolvidos para se integrarem de forma otimizada a serviços da AWS. Porém, nada impede que possamos utilizar esta documentação em outros ambientes como o Ubuntu, basta seguir a mesma lógica.

E preciso dizer que uma das maiores motivações que tive para escrever esta documentação, foi justamente a falta de uma documentação oficial bem detalhada focada em ambientes de produção. Chega a ser curioso e acredito não ser algo exclusivo do Strapi, mas me estranha uma ferramenta tão popular falhar nesse aspecto. Devemos lembrar que o Strapi possuí uma solução gerenciada, porém, os valores podem afastar e até assustar a maioria dos interessados.

Preparação do ambiente

Usuário

Vamos começar falando sobre o usuário. Na Amazon Linux 2023, bem como, na Amazon Linux 2 o usuário padrão é o "ec2-user" e é justamente com esse usuário que realizaremos todas as configurações, não sendo necessário mudar para o "root" ou criar algum outro usuário.

Servidor Web

Aqui estamos utilizando o NGINX que pode ser facilmente instalado com o gerenciador de pacotes dnf :

sudo dnf install nginx

Node.js

Vamos utilizar o Node.js que também pode ser facilmente instalado com o gerenciador de pacotes dnf :

sudo dnf install nodejs

Estrutura de pastas

Tenho o costume de criar a estrutura de pastas para o NGINX em /var/www , porém, pode ser que você estruture em outro local. Caso queira utilizar a estrutura deste exemplo, basta seguir:

sudo mkdir /var/www

Agora podemos navegar até a pasta www :

cd /var/www

Vamos criar a pasta para nosso projeto:

sudo mkdir strapiapp.com.br

A aplicação será executada pelo usuário atual, porém, como estamos trabalhando com os diretórios de sistema, utilizamos o comando sudo para criar as pastas necessárias. Portanto, devemos alterar o owner do diretório do projeto para que todas as execuções não necessitem do comando sudo .

sudo chown ec2-user:ec2-user strapiapp.com.br

Também vamos definir permissões para o diretório do projeto:

sudo chmod 775 strapiapp.com.br

E finalmente navegamos até o diretório do projeto:

cd strapiapp.com.br

O resultado é a seguinte estrutura de diretórios: /var/www/strapiapp.com.br .

Instalação do Strapi

Vamos instalar a última versão do Strapi a partir do diretório atual:

npx create-strapi-app@latest .

## Observer que não estamos utilizando o comando sudo

# 'npx' executa o comando de um pacote npm
# 'create-strapi-app' é o pacote Strapi
# '@latest' indica que vamos instalar a última versão do Strapi
# '.' informo que desejo utilizar o diretório atual para a instalação sem a necessidade de criar um novo diretório e informar o nome do projeto

Caso ainda não tenha o pacote create-strapi-app instalado, será informado que é necessário realizar sua instalação:

Need to install the following packages:
  create-strapi-app@4.10.2
Ok to proceed? (y)

Basta confirmar e seguir.

Após o processo de instalação do pacote ser finalizada, necessitamos informar as configurações do nosso projeto.

Para este projeto estou trabalhando com um Banco de Dados MySQL configurado e instalado em outro host. A primeira questão é referente ao modo de configuração, e aqui seleciono o modo "Custom (manual settings)", pois pretendo configurar esse projeto manualmente.

? Choose your installation type (Use arrow keys)
  Quickstart (recommended)
❯ Custom (manual settings)

# A diferença entre esses modos é que no "Quickstart (recommended)" uma base de dados (SQLite) é criada localmente para facilitar a criação do projeto. Porém, estamos falando de configurar um projeto em Produção e essa configuração básica não atende nossas necessidades.

Em seguida somos questionados sobre a nossa preferência de linguagem entre "Javascript" e "Typescript":

? Choose your preferred language
  JavaScript
❯ TypeScript

# Aqui estou selecionando Typescript por uma preferência estritamente pessoal, selecione a linguagem que lhe trouxer mais conforto.

Agora somos questionados sobre qual banco de dados vamos utilizar:

? Choose your default database client
  sqlite
  postgres
❯ mysql

# Como informei anteriormente, já possuo um cliente MySQL previamente configurado em outro host, então simplesmente seleciono a opção "mysql"

Informe o nome do seu banco de dados utilizado para o projeto:

? Database name: strapi_app

# Previamente criei uma base de dados com o nome "strapi_app"

Informe o host de seu banco de dados:

? Host: host.domain.us-east-1.rds.amazonaws.com

# Observe que o domínio "host.domain.us-east-1.rds.amazonaws.com" é apenas um exemplo, informe aqui o host do seu banco de dados.

Informe a porta de comunicação:

? Port: (3306)

# A porta de comunicação padrão é a 3306, informe outro valor caso seja o seu caso.

Agora informe o usuário de seu banco de dados:

? Username: admin

# Aqui informo que o nome do usuário é admin, informe o valor correto para seu caso.

Senha de acesso ao banco de dados:

? Password: ******

Informe se sua conexão de banco de dados possuí SSL:

? Enable SSL connection: (y/N) N

# No meu caso, não utilizo SSL para me comunicar com o bando de dados.

O processo de instalação será iniciado:

Creating a project with custom database options.
Creating a new Strapi application at /var/www/strapiapp.com.br.
Creating files.

Ao final do processo, caso tudo tenha transcorrido corretamente, receberemos a seguinte mensagem:

Dependencies installed successfully.
Initialized a git repository.


Your application was created at /var/www/strapiapp.com.br.

Available commands in your project:

  yarn develop
  Start Strapi in watch mode. (Changes in Strapi project files will trigger a server restart)

  npm run start
  Start Strapi without watch mode.

  npm run build
  Build Strapi admin panel.

  npm run strapi
  Display all available commands.

You can start by doing:

  cd /var/www/strapiapp.com.br
  npm run develop

Trabalhando com o Strapi

Algo que também me incomodou em relação a documentação e tutoriais espalhados pela internet é a falta de uma análise mais técnica em relação ao Strapi, ou seja, como de fato ele funciona, como ele pode me ajudar em um ambiente local, e principalmente como ele deve ser instalado e configurado em um ambiente de produção.

Como o Strapi funciona?

De uma forma simples e direta, para que você consiga estruturar um projeto utilizando o Strapi, você sempre irá executá-lo no modo "develop" e após ter criado toda estrutura utilizando o "Content-Type Builder" é que vamos gerar o "Build" para enfim rodarmos em produção no modo "start".

Você não conseguirá criar nenhum "Content-Type" no modo "start", caso tente, receberá a seguinte mensagem:

The autoReload feature is required to use this plugin. Start your server with `strapi develop`

Primeiros passos

Mesmo sem termos criado nenhum "Content-Type", podemos gerar o build inicial para termos acesso a área administrativa:

npm run build

E enfim, executamos o comando para executar de fato o Strapi:

npm run start

O Strapi será executado na porta 1337 .

Configurando Proxy Reverso no NGINX

Aqui vou deixar um exemplo simples de como configurar um proxy reverso com redirecionamento automático para https .

server {
    listen 80;
    listen [::]:80;

    if ($host = 'strapiapp.com.br') {
        return 301 https://strapiapp.com.br$request_uri;
    }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name strapiapp.com.br;
    root /var/www/strapiapp.com.br;

    ssl_certificate "/etc/letsencrypt/live/strapiapp.com.br/fullchain.pem";
    ssl_certificate_key "/etc/letsencrypt/live/strapiapp.com.br/privkey.pem";

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:1337;

    }
}

Criando um serviço utilizando Systemd

Para que a execução do Strapi seja automática, ela deve ser controlada pelo sistema e não pela interação com o terminal de comandos, portanto, vou detalhar os passos para que seja criado um serviço "Systemd" que irá persistir mesmo após a reinicialização do sistema.

Diretório que armazena os serviços "Systemd":

/lib/systemd/system

Vamos navegar até esse diretório:

cd /lib/systemd/system

Vamos criar um arquivo para armazenar as informações de execução desse serviço:

sudo nano strapi_strapiapp-com-br.service

O arquivo deve conter as seguintes informações:

[Unit]
Description=Strapi systemd service for project: strapiapp-com-br
Documentation=https://docs.strapi.io/dev-docs/deployment

[Service]
Type=simple
WorkingDirectory=/var/www/strapiapp.com.br
User=ec2-user
Environment="NODE_ENV=production"
ExecStart=/usr/bin/npm run start
Environment=CI=true
Restart=always

[Install]
WantedBy=multi-user.target

Agora podemos ativar esse serviço para que sua execução seja persistente:

sudo systemctl enable strapi_strapiapp-com-br

E finalmente podemos excutar o Strapi através do "Systemd":

sudo systemctl start strapi_strapiapp-com-br

Finalizado!

Esta é uma documentação técnica que abrange os principais pontos para executar o Strapi em um ambiente de produção. Espero que tenha sido útil pra você, qualquer coisa me chama para um bate-papo!