Forem: Layssa Lima

Enfim, Domain Driven Design (DDD)

Layssa Lima — Thu, 29 Jan 2026 22:24:24 +0000

Padrões de projeto no front-end. Parte 2.

Esta é a parte 2 de uma sequência de artigos sobre desenvolvimento de software.

O que é o DDD?

“É um conjunto de princípios com foco em domínio, exploração de modelos de formas criativas e definir e falar a linguagem Ubíqua, baseado no contexto delimitado."

Como falado no post anterior (Padrões de projeto no front-end? - Parte 1), projetos modulares conseguem oferecer um bom meio termo quando monolitos tornam-se caóticos e microsserviços confusos e necessitam de mais pessoas.

Mas depois de entender que modularizar é um bom caminho para o projeto, entra o próximo desafio: definir os módulos.

E essa parte é confusa, pois muitos módulos convergem uns nos outros.

É nesse ponto que o DDD ajuda.

O DDD possibilita a melhor modelagem do software, com foco nas regras da aplicação (princípos, regras e processos) que são complexas e precisam de atenção. Isso permite que o software evolua gradualmente e que diferentes áreas possam conversar entre si sem impactar a outra.

Quando usar?

Utiliza-lo só faz sentido em softwares complexos e apenas.
Uma vez que a proposta é exatamente lidar com a complexidade com mais eficiência.

O que faz um software ser complexo?

As regras de negócio.
As àreas envolvidas e/ou relacionadas.
A interpretação que cada pessoa tem.

A transcrição dessas regras e interpretações em código é o que torna o software complexo.

O DDD

Domínios

O DDD interpreta o projeto dividindo em duas classes:

Domínio
Subdomínio

O Domínio: é o core do negócio.
Exemplo: Um site para transmissões ao vivo.

O Subdomínio: são as partes menores que compõe o domínio central.
Exemplo: chats, players, canais e etc.

Linguagem universal

Ele também ajuda a criar uma linguagem universal, padronizando a nomenclatura e facilitando a interpretação e conversação das àreas.

Bounded Contexts ou Contexto delimitados

O Bounded Contexts consiste em separar a sua aplicação, onde cada sessão será um conjunto de termos, regras e definições consistentes.

Enquanto escrevia esse artigo, eu vi um exemplo no reddit muito bom.

The 'bounded context' is a doll house, inside of it is where you keep things that 'belong' inside - a dining table, a kitchen, and a bathtub. You wouldn't put a tree or a road sign inside, because they don't belong inside.

Um outro exemplo muito bom da mesma thread é de um e-commerce:

No site: O PEDIDO tem informações importantes como preço, impostos e etc.
No armazém: O PEDIDO tem outra 'cara', nele o que mais importa são os códigos e endereços.

Mesmo objeto. Valores e relevâncias diferentes.

Assim, o pedido deve ter as informações necessárias em ambos os setores, mas cada uma é independente.
O setor de pedidos pode adicionar outras formas de pagamentos ou o setor do armazém pode adicionar novas formas de entrega, as alterações não irão sobreescrever o que é relevante pra outra àrea.

Veja a thread

Isso auxília na criação do design da aplicação, tornando-o mais estratégico.

Design do sistema

Com essa visão macro do sistema, é mais fácil mapear as entidades, os procedimentos e eventos de domínio envolvidas na aplicação.

Complexidade de negócio vs Complexidade Técnica

Outra ponto que também é facilitado é separar a complexidade em dois contextos: o que é complexo devido as regras de negócio e o que é complexo por questões técnicas.

Problemas

A visão macro construida até então do domínio, será o ponto de partida para enxergar os problemas que o sistema possui e assim criar subdomínios

Para cada um dos subdomínios deve ser criado um Bounded Context(ver sessão anterior) para a solução final.

Contexto é a chave primária pra nomenclatura

Existe a possibilidade de uma mesma palavra ter significados diferentes, da mesma maneira, pode ocorrer de palavras diferentes, terem significados iguais. Logo, o ideial é delimitar o domínio para que essas entidade(s) possam co-existir.

Diferentes entidades, mesmo nome

Imagine uma empresa b2b e b2c, customer para o b2b é uma empresa, com informações e funções diferentes, enquanto que para o b2c é algo totalmente diferente. Ambos são salvos na entidade 'customer'. Para total compreensão e controle das features, o ideal seria delimitar essas entidades em contextos diferentes.

Mesma entidade, funcionalidades diferentes

Voltando ao exemplo do pedido, o pedido é um só para o site e para o armazé, porém, necessitam de features diferentes.

No site, a entidade pedido precisa lidar com compra/venda
No armazém, retirada, transporte e entrega.

Padrões de mapeamento de contexto

Partnership
Shared Kernel
Customer-Supplier Development
Conformist
Anticorruption-layer
Open host service
Published language
Separate ways
Big Ball of Mud

Mapeamento de contextos

Considerando o exemplo inicial, um site para transmissões ao vivo.

Back-end

Front-end

Padrões de projeto no front-end? - Parte 1

Layssa Lima — Thu, 20 Nov 2025 18:19:43 +0000

Alguns meses atrás me deparei com a necessidade de refazer um projeto front-end do zero. Isso me levou a uma busca por padrões de projetos aplicados ao front-end - algo que, particularmente, não é tão fácil de encontrar quanto no back-end.

Depois de algum tempo estudando sobre monolitos, micro front-ends e monolitos modulares, cheguei a algumas reflexões que rascunho abaixo.

Micro front-end vs. Monolito Modular vs. Monolito

Uma das primeiras questões que veio à mente foi: qual dos modelos adotar? Para isso, considerei os pontos abaixo.

Micro front-end

Pros
Permite que módulos da aplicação sejam desenvolvidos e implantados de forma totalmente independente. Isso reduz acoplamento, facilita escalabilidade e permite que times diferentes evoluam partes distintas da aplicação no seu próprio ritmo. Também possibilita escalar recursos de forma isolada para apenas os serviços que precisam.

Contras
Em contrapartida, aumenta a complexidade da arquitetura. Requer mais infraestrutura, mais pipelines, mais pessoas para dar suporte e, consequentemente, maior custo de cloud. Também exige maturidade para lidar com versionamento, comunicação entre módulos e consistência visual.

Monolito

Pros
É um modelo clássico, simples de gerenciar e que costuma atender bem a maioria das necessidades. O código fica centralizado, o deploy é único e os custos — tanto de pessoal, quanto de infraestrutura — tendem a ser menores.

Contras
Com o tempo, pode se tornar uma base de código altamente acoplada e difícil de manter. À medida que a equipe cresce, o fluxo de trabalho paralelo tende a gerar conflitos e gargalos. Escalar o sistema geralmente exige aumentar recursos da máquina inteira, e não apenas da parte que realmente precisa.

Monolito Modular

O monolito modular traz um ponto de equilíbrio entre os dois extremos. Ele mantém um único projeto e um único deploy, mas organiza o código em módulos bem separados, com responsabilidades claras, limites explícitos e baixo acoplamento.

Dessa forma, múltiplas pessoas podem trabalhar em paralelo — desde que estejam em módulos distintos — sem o mesmo nível de conflito de um monolito comum. Além disso, caso algum módulo precise virar um serviço independente no futuro, o esforço de extração tende a ser muito menor do que em um monolito tradicional.

Mas existe um ponto crucial para que esses módulos façam sentido: DDD. E esse é um tema que vale um artigo próprio.

Construindo uma Aplicação com Comunicação em Tempo Real Usando Fastify, RabbitMQ e Arquitetura Distribuída

Layssa Lima — Thu, 07 Aug 2025 22:33:38 +0000

Há cerca de três meses, participei de um desafio que me deixou bastante empolgada.
Por essa razão resolvi compartilhar como foi o processo de desenvolvimento, as escolhas técnicas que fiz e alguns aprendizados ao longo do caminho.

Aceito sugestões de melhorias.

⚠️ Spoiler: o projeto está apenas no começo, ainda há muito para ser desenvolvido, inicialmente estou compartilhando apenas o que foi feito em um desafio entre 3 e 4 dias

Repositório: Dwitch

O DESAFIO

O objetivo era criar uma aplicação completa:

Frontend e backend
Autenticação
Persistência de dados
Observabilidade
Mensageria

Tudo isso em uma arquitetura distribuída, com documentação do projeto.

Ponto de partida

O primeiro passo foi decidir qual aplicação desenvolver. Como eu já tinha interesse em me aprofundar no tema, optei por criar uma aplicação de transmissão ao vivo, mesmo sabendo que o tempo disponível não permitiria implementar todas as funcionalidades reais desse tipo de sistema.

Arquitetura

O passo seguinte foi definir a arquitetura.
Comecei pensando nas funcionalidades que o sistema deveria ter, organizando-as em módulos e alinhando tudo aos requisitos do desafio.

No desenho, temos um banco PostgreSQL centralizando os dados do sistema e quatro módulos principais:

Auth - autenticação.
Channels - CRUD de canais.
User - CRUD de usuários.
Broadcast - comunicação das transmissões.

Nesse estágio inicial, optei por simular a comunicação em tempo real por meio de mensagens — algo que é bem diferente de uma transmissão ao vivo real, mas que atendia ao escopo e tempo do desafio.

Sobre os módulos

Os módulos foram implementados com Fastify, cuja sintaxe é bastante familiar para quem já trabalhou com Express.
Para mensageria, utilizei RabbitMQ.

Modelagem dos dados

Após visualizar a aplicação e a arquitetura, passei para a modelagem do banco de dados.

Nessa modelagem, estabeleci:

A relação entre usuários e canais
A relação entre canais e transmissões
O vínculo das transmissões com seus respectivos logs

Dessa forma, é possível acompanhar o status de cada transmissão e manter um histórico de alterações.

Ferramentas utilizadas nessa etapa

Diagramas: Draw.io
APIs: Fastify
Mensageria: RabbitMQ
Protocolos: HTTP e WebSocket

💡 Próximos passos: no próximo post, quero detalhar como implementei cada módulo e como configurei a comunicação entre eles.

Se tiverem dúvidas ou sugestões de melhorias, deixem nos comentários!

Building an Application with Real-Time Communication Using Fastify, RabbitMQ, and a Distributed Architecture

Layssa Lima — Thu, 07 Aug 2025 21:32:14 +0000

About three months ago, I took part in a challenge that got me really excited.
That’s why I decided to share how the development process went, the technical choices I made, and some lessons I learned along the way.

Github: Dwitch

I’m open to suggestions for improvement.

⚠️ Spoiler: the project is just getting started — there's still a lot to be developed.
What I'm sharing here is only what was built during a 3-to-4-day challenge.

THE CHALLENGE

The goal was to create a complete application:

Frontend and backend
Authentication
Data persistence
Observability
Messaging

All of this in a distributed architecture, with proper project documentation.

Starting point

The first step was to decide what kind of application to build.
Since I already had an interest in exploring the topic, I chose to create a live streaming application — even knowing that the available time wouldn’t allow me to implement all the real-world features of such a system.

Architecture

The next step was to define the architecture.
I started by thinking about the functionalities the system should have, organizing them into modules, and aligning everything with the challenge’s requirements.

In the diagram, we have a PostgreSQL database centralizing the system’s data and four main modules:

Auth – authentication
Channels – channel CRUD
User – user CRUD
Broadcast – stream communication

At this initial stage, I chose to simulate real-time communication using messaging — which is quite different from actual live streaming — but it fit the scope and time constraints of the challenge.

About the modules

The modules were implemented with Fastify, whose syntax is very familiar to anyone who has worked with Express.
For messaging, I used RabbitMQ.

Data modeling

After visualizing the application and its architecture, I moved on to database modeling.

In this model, I defined:

The relationship between users and channels
The relationship between channels and streams
The link between streams and their respective logs

This structure makes it possible to track the status of each stream and keep a history of changes.

Tools used in this stage

Diagrams: Draw.io
APIs: Fastify
Messaging: RabbitMQ
Protocols: HTTP and WebSocket

💡 Next steps: In the next post, I’ll detail how I implemented each module and how I set up communication between them.

If you have any questions or suggestions for improvement, feel free to leave them in the comments!

Docker: O Que Aprendi na Semana 1 de estudo

Layssa Lima — Thu, 13 Mar 2025 02:16:50 +0000

Nos últimos 6 meses, decidi que focaria na minha carreira e começaria a estudar novas ferramentas. Uma dessas ferramentas é o docker, nesse artigo vou compartilhar importantes conceitos que aprendi na minha primeira semana.

Containers
Containers vs Máquina virtual
Primeiros passos com docker

Containers

Um container é um ambiente isolado para empacotar aplicações, isolando processos e recursos.
A maneira como são montados permite que não consumam muitos recursos da máquina, pois são executados como um processo do sistema operacional da máquina host.
Devido a essas características, cada um pode ser iniciado e parado rapidamente.
São construídos utilizando imagens — que são imutáveis.
A proposta do docker é equalizar ambientes e evitar problemas dessa natureza.

Containers vs Máquina virtual

Antes dos containers era comum utilizar máquinas virtuais.
Mas qual é a diferença?

Máquinas virtuais

Bem, pra começar as máquinas virtuais possuem um sistema operacional individual, ou seja, pra cada máquina virtual, temos um novo sistema operacional completo, incluindo kernel. Além disso, possui um hypervisor para gerenciar as máquinas.

Isso faz com que seja necessário mais recursos, que são usados com menos eficiência, e mais tempo de inicialização.

Containers

Por outro lado, containers compartilham o kernel com o host e mantém a aplicação e dependências isoladas.

Consequentemente, os containers possuem mais eficiência no uso de recursos e têm inicialização mais rápida.

Isso faz com que os containers sejam mais apropriados para escalabilidade e permite a execução de muitas aplicações no host.

O ponto de falha do docker é que todos os containers são controlados pelo docker daemon, uma vez que ele caia, todos os outros caem.

Primeiros passos com docker

Instalando o docker

Para instalar na sua máquina, siga os passos do tutorial do seu sistema operacional:

Windows
Linux
Mac

Primeiros comandos

Inicia container com a imagem informada e gera nome randômico.
docker run <nome da imagem>

Inicia container com a imagem informada e com o nome 'teste'.
docker run --name=teste <nome da imagem>

Remove container com o ID informado - se estiver parado
docker rm <container_ID>

Remove container com o nome informado - se estiver parado
docker rm <container_name>

Força remoção do container - mesmo que esteja parado.
docker rm -f <container_name>

Attach e Detach

Ao iniciar um container seu terminal ficará travado, para evitar isso, faça o detach:

docker run -d <container_id | container_name | image>

Mas caso deseje ler os logs do container no terminal, faça:
docker attach <container_id>

Remoção automática do container após paralização

Para isso, faça:
docker run --rm <image>

Portas dos containers

A porta usada no container é exposta internamente, de maneira que acessando a partir da sua máquina, não é possível acessa-la.

No entanto, para fazer essa configuração, faça:
docker run -p 8080:80

A porta 8080 da sua máquina irá refletir a porta 80 do container.

Persistência de dados e volumes: Bind mounts vs volumes

Ao parar um container, os dados dentro dele serão perdidos, mas uma forma de contornar isso é utilizando Bind mounts ou volumes.

Bind mounts
Compartilha pasta com o host, caso a pasta seja modificada localmente, será refletida no container, é útil em ambientes de desenvolvimento.
Volumes
São gerenciados por pastas isoladas, salvas nos arquivos do host, e são mais performáticos, ideais para produção.

Comandos Bind mounts

Criando Bind Mount:
docker run -dp 3333:80 -v caminho_pasta_local:caminho_pasta_container <imagem>

Comandos Bind mounts

Criando volume:
docker volume create <volume_nome>

Backups com busybox
É uma imagem de utilitários linux, pode ser útil para fazer backups.

Compactar e fazer backup.
docker run --rm -it -v volume_nome:/data -v $(pwd)/backup_host:/backup busybox tar czf /backup/backup.tar.gz /data

Descompactar e restaurar backup.
docker run --rm -it -v volume_nome:/data -v $(pwd)/backup_host:/backup busybox tar xzf /backup/backup.tar.gz -C /data

Conclusão

Esses foram os conceitos que aprendi na minha primeira semana explorando Docker. Em breve, trarei mais descobertas e práticas!

How set Google Tag Manager (GTM) on Nextjs applications with differents themes and IDs

Layssa Lima — Fri, 14 Feb 2025 17:54:11 +0000

This week, I needed to solve a problem with Google Tag Manager (GTM).

The problem was that my platform has different themes for each client, and I needed to insert the GTM code for each theme.

The problem:

Google Tag Manager (GTM) was not working correctly because its ID was being dynamically loaded on the client side. However, GTM needs to be available immediately when the page loads. This caused issues such as:

GTM not initializing at the right time.
Important tracking events (like pageviews) being lost.

For example

// This will not work
function Example(gtmId){
 return <GoogleTagManager gtmId={gtmId} />
}

Solutions Attempted

Loading GTM as a Dynamic Component: GTM was loaded as a dynamic component after the page rendered, which delayed execution and prevented it from working correctly.
Loading GTM Dynamically on the Client Side: GTM was also loaded only on the client side, but since it needs to be available at the initial page load, this approach failed.

The solution

To ensure GTM loads during the initial page render, we use the following approach:

Define Preconfigured GTM Instances

const GoogleTagManagerInstancies: { [key: string]: () => JSX.Element } = {
  cobrand1: () => <GoogleTagManager gtmId="GTM-XXXXXX" />,
  cobrand2: () => <GoogleTagManager gtmId="GTM-YYYYYY" />,
  default: () => <></>,
};

Select GTM Based on Theme

const WaGoogleTagManager = GoogleTagManagerInstancies[activeTheme ?? "default"];

Render the Component

<WaGoogleTagManager />

Why Does This Work?

GTM is statically defined at the initial page load.
The GTM ID is resolved before rendering, ensuring the script loads at the right time.

Conclusion

The issue was caused by GTM being loaded too late, preventing it from executing correctly. The solution ensures that GTM is loaded before rendering, using preconfigured instances and direct rendering in the HTML.

Tudo o que você precisa saber sobre Next.JS para iniciar um novo projeto hoje

Layssa Lima — Wed, 18 Dec 2024 22:12:24 +0000

Introdução
O Projeto
Iniciando
Criando rotas
Organizando as rotas da plataforma
Controlando as Rotas do Projeto
Conclusão

Tudo o que você precisa saber sobre Next.JS para iniciar um novo projeto hoje

1 Introdução

Next.js é um poderoso framework React que vai além do desenvolvimento apenas de front-end. Enquanto o React normalmente se concentra em construir interfaces de usuário, o Next.js possibilita a criação de aplicações full-stack, lidando tanto com o front-end quanto com o back-end em um único framework unificado. Essa abordagem é frequentemente chamada de "Backend for Frontend" (BFF), permitindo criar aplicações completas e robustas com facilidade.

Links importantes:
Repositório no Github

2 O Projeto

O objetivo deste projeto é criar um site de eventos voltado para a venda de ingressos. A plataforma oferecerá ingressos para diversos tipos de eventos e contará com quatro páginas principais: a página de login, um feed de eventos, o processo de compra e a página de resumo do pedido. Abaixo, você encontrará imagens de pré-visualização de cada layout de página.

3 Iniciando

Instale o Node.JS 18.8 ou superior.
Criando o projeto:

npx create-next-app@latest

Em seguida, o terminal exibirá algumas perguntas:

// Este será o nome do seu projeto
What is your project named? eve

// **YES** - Usar typescript melhora a compreensão do código
Would you like to use TypeScript? No / Yes

// **YES** - Eslint ajuda a evitar erros 
Would you like to use ESLint? No / Yes

// **NO** - Neste projeto será usado styled-components
Would you like to use Tailwind CSS? No / Yes

// **YES**
Would you like your code inside a `src/` directory? No / Yes

// **YES**
Would you like to use App Router? (recommended) No / Yes

// **NO**
Would you like to use Turbopack for `next dev`?  No / Yes

// **NO**
Would you like to customize the import alias (`@/*` by default)? No / Yes
What import alias would you like configured? @/*

Agora você pode rodar o comando abaixo para ver a página padrão do Next.js:

  npm run dev

Alternativamente, você pode usar este comando para construir a aplicação como páginas estáticas:

  npm run start

4 Criando rotas

O Next.js fornece uma maneira fácil de lidar com rotas na aplicação com base nos nomes dos caminhos. Vamos explorar cada caso.

1. Rotas comuns

No diretório /src/app, procure o arquivo page.tsx. Esse será o arquivo exibido por padrão ao acessar http://localhost:3000.
Agora, crie uma nova rota: no diretório src/app, crie uma pasta chamada auth. Dentro dela, crie o arquivo page.tsx e adicione o seguinte código:

export default function Auth() {
  return <div>login</div>;
}

Ao acessar http://localhost:3000/auth, você verá o texto "login".

2 - Agrupamento de rotas

Para organizar o código sem impactar a estrutura das URLs, renomeie a pasta auth para (auth) e crie um subdiretório login, mova o arquivo page.tsx para ela.

Agora, verifique duas coisas:

a URL /auth exibirá um erro 404.
a URL /login exibirá o componente corretamente.

Essa abordagem organiza o projeto em módulos sem afetar a experiência do usuário.

4 - Rotas dinâmicas

Crie uma rota dinâmica, ideal para páginas que precisam exibir conteúdo variável, como detalhes de um evento.

No diretório /app, crie uma pasta events e, dentro dela, outra chamada [id]. O nome com colchetes indica uma rota dinâmica.

No arquivo page.tsx dentro da pasta [id], adicione:

// O comando 'use client' é uma diretiva usada no Next.js para indicar que um arquivo ou componente deve ser executado no lado do cliente.
'use client' 

import { useParams } from "next/navigation";

export default function EventInfo() {
    const params = useParams(); // Retrieve URL parameters

    return <div>{params.id}</div>;
  }

Acesse http://localhost:3000/events/111 para visualizar a página.

5 Organizando as rotas da plataforma

Instalando dependências:

npm i styled-components react-query

Criando rotas de autenticação e plataforma

Autenticação: Crie um diretório (auth) com subdiretórios login e register.
Plataforma: No diretório app, crie uma pasta platform com subdiretórios [id] e purchase.

Rotas privadas da plataforma

Dentro da pasta app crie uma pasta chamada 'platform', em seguida crie as seguintes sub pastas:

[id]
purchase

A estrutura das pastas deve parecer com isso:

Nesse momento, iremos criar pastas genéricas, pois este arquivo foca no funcionamento do Next.js.

6 Controlando as Rotas do Projeto - Middlewares

No nosso projeto haverá rotas públicas e privadas, para controlar esse acesso utilizaremos o middleware

O que é um Middleware?

Middleware é uma função executada a cada solicitação de página. Isso permite gerenciar as rotas, autenticação e outras regras. Para isso:

Crie um arquivo chamado middleware.ts na pasta src.
Adicione o seguinte código:

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export default function middleware(request: NextRequest) {
  return NextResponse.redirect(new URL('/home', request.url))
}

3. Adicionando regras às rotas.

No mesmo arquivo, adicione dois arrays para categorizar dois tipos de rotas - públicas e privadas.

// Rotas privadas - necessita de autenticação
const protectedRoutes = ["/platform"];

// Rotas públicas - não necessita de autenticação
const publicRoutes = ["/login", "/register"];

Verificando as regras da rota e a sessão do usuário

Atualize a função do middleware para incluir as validações das rotas e checar a sessão:

export function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl; // URL being accessed
  const userId = request.cookies.get("user-id"); // User session check

  // Função que  verifica se a rota é privada
  const isPrivateRouter = protectedRoutes.some((path: string) =>
    pathname.startsWith(path)
  );

  if (isPrivateRouter && userId) {
    return NextResponse.next();
  }

  if (isPrivateRouter && !userId) {
    return NextResponse.redirect(new URL("/login", request.url));
  }

  // Função que  verifica se a rota é pública
  const isPublicRouter = publicRoutes.some((path: string) =>
    pathname.startsWith(path)
  );

  if (isPublicRouter && !userId) {
    return NextResponse.next();
  }

  if (isPublicRouter && userId) {
    return NextResponse.redirect(new URL("/platform", request.url));
  }

  // Redireciona para o login se a rota for inválida
  return NextResponse.redirect(new URL("/login", request.url));
}

5. Pular execução do middleware em rotas específicas

Se você não quer que o middleware execute em algumas rotas, no mesmo arquivo deve adicionar o seguinte código no arquivo middleware.ts:

export const config = {
  matcher: ['/login'], // não será executada na rota /login
}

7 Navegando entre rotas

Antes de seguir, desabilite o middleware.

Utilizando Next.js para navegar

Next.js permite duas formas para navegação.

Utilizando Link

Para navegação por links, use o componente Link do Next.js em vez da tag <a> padrão do HTML. Isso evita o recarregamento completo da página, proporcionando um melhor desempenho e uma experiência de usuário mais suave.

Exemplo: Crie um botão na página de login para navegar até a plataforma.

Ao clicar no botão, a navegação causará o recarregamento da página.

Então, vamos tentar usar o componente do Next.js.

Ao clicar no botão, a navegação ocorrerá sem recarregar a página inteira.

Usando o Hook do Router

Como alternativa, você pode usar o hook router do Next.js para navegação programática.

Essa abordagem também garante transições suaves e cria a sensação de uma aplicação de página única (SPA).

Com esses métodos, você pode oferecer uma experiência de navegação fluida para os usuários.

7 Conclusão

Neste artigo, exploramos os principais recursos do Next.js, incluindo os fundamentos de roteamento, criação de páginas dinâmicas e aninhadas, organização de código com grupos de rotas e implementação de autenticação e controle de acesso usando middleware. Além disso, aprendemos a otimizar a navegação para uma melhor experiência do usuário, aproveitando o componente Link e o roteamento programático com o hook useRouter. Esses conceitos estabelecem uma base sólida para a criação de aplicações escaláveis e amigáveis ao usuário com Next.js.

Integrating Storybook into an existing next.js project

Layssa Lima — Wed, 18 Dec 2024 21:32:08 +0000

In this article, you'll learn how to integrate Storybook into an existing Next.js project, including support for different themes.

Introduction

Storybook is an open-source tool that allows developers to build, test, and document UI components in isolation.

Install storybook
To get started, initialize Storybook in your project:

npx storybook@latest init

Configure Your Project
Below is an example configuration for integrating Storybook with a Next.js project:

main.ts

// main.ts

import type { StorybookConfig } from '@storybook/nextjs'

import { join, dirname } from 'path'

function getAbsolutePath(value: string): any {
  return dirname(require.resolve(join(value, 'package.json')))
}

const config: StorybookConfig = {
  stories: ['../src/**/*.mdx', '../src/**/*.stories.@(js|jsx|mjs|ts|tsx)'],
  addons: [
    getAbsolutePath('@storybook/addon-onboarding'),
    getAbsolutePath('@storybook/addon-essentials'),
    getAbsolutePath('@chromatic-com/storybook'),
    getAbsolutePath('@storybook/addon-interactions'),
  ],
  framework: {
    name: '@storybook/nextjs',
    options: {},
  },
  staticDirs: ['../public'],
}

export default config

preview.ts

// preview.ts

import { Preview } from '@storybook/react'
import { themesNames } from '../src/theme'

// Contexts providers
import { withThemeProvider } from './themeProvider'

import { RouterContext } from 'next/dist/shared/lib/router-context.shared-runtime'

export const globalTypes = {
  parameters: {
    nextRouter: {
      Provider: RouterContext.Provider,
    },
  },
  theme: {
    name: 'Theme',
    description: 'Global theme for components',
    defaultValue: 'defaultTheme',
    toolbar: {
      icon: 'paintbrush',
      items: themesNames,
      showName: true,
    },
  }
}

const preview: Preview = {
  decorators: [withThemeProvider],
}

export default preview

Note: When configuring Storybook with custom providers, such as themes or global contexts, it’s essential to mock these contexts properly.

Context Providers Setup

themeProvider.tsx

// themeProvider.tsx

import React from 'react'
import { ThemeProvider } from 'styled-components'
import { Decorator } from '@storybook/react'
import { QueryClient, QueryClientProvider } from 'react-query'
import { AppRouterContext } from 'next/dist/shared/lib/app-router-context.shared-runtime'
import { GlobalStyle } from '../src/styles/Global.styles'

const queryClient = new QueryClient()

const themes = {
  // ... all project themes
  // 'projectName' : { ...settings}
}

// Contexts providers
export const withThemeProvider: Decorator = (Story, context) => {
  const selectedTheme = context.globals.theme ?? 'defaultTheme'

  return (
    <QueryClientProvider client={queryClient}>
      <AppRouterContext.Provider
        // Overriding nextjs router functions
        value={{
          push: async () => true,
          replace: async () => true,
          back: () => {},
          prefetch: async () => {},
          forward: () => {},
          refresh: () => {},
        }}
      >
        <ThemeProvider theme={themes[selectedTheme]}>
          <GlobalStyle />
          <Story />
        </ThemeProvider>
      </AppRouterContext.Provider>
    </QueryClientProvider>
  )
}

Example: Button Component

1. Create the Component

Create a new folder for the component at /src/components/button. Inside this folder, add the following file:

/src/components/button/index.tsx

// index.tsx

export default function Button({children, onClick, disabled}){
  return <button onClick={onClick} disabled={disabled}>{children}</button>
}

2. Add Stories

In the same folder, create a file named Button.stories.ts to define the stories for the Button component.

You can use diferents files [js|jsx|mjs|ts|tsx].

/src/components/button/Button.stories.ts

// Button.stories.ts

import type { Meta, StoryObj } from '@storybook/react'
import { fn } from '@storybook/test'

import Button from './'

const meta = {
  title: 'UI/Primary Button',
  component: Button,
  parameters: {
    layout: 'centered',
  },
  tags: ['autodocs'],
  argTypes: {},
  args: { onClick: fn() },
} satisfies Meta<typeof Button>

export default meta
type Story = StoryObj<typeof meta>

export const Primary: Story = {
  args: {
    children: 'Button',
    disabled: false,
  },
  parameters: {
    nextjs: {
      appDirectory: true,
    },
  },
}

export const Disabled: Story = {
  args: {
    children: 'Button Disabled',
    disabled: true,
  },
  parameters: {
    nextjs: {
      appDirectory: true,
    },
  },
}

Run and Build Storybook

To build and run your Storybook environment, use the following commands:

Build Storybook:

  npm run build-storybook

Run Storybook:

  npm run storybook

Finally, you can view Storybook's UI by opening it in your browser. After running npm run storybook, Storybook will be accessible at:

http://localhost:6006

This interface allows you to browse, test, and document your components interactively. Enjoy exploring your UI components with Storybook! 🎉

You should see something like this:

Everything you need to know about Next.JS to start a new application today

Layssa Lima — Tue, 03 Dec 2024 16:46:42 +0000

1. Introduction
2. The Project
3. Starting setup
4. Rounting
5. Project Routes
6. Navigating between pages
7. Conclusion

Everything you need to know about Next.JS to start a new application today.

1 Introduction

Today, we’ll dive into building an application with Next.js!

Next.js is a powerful React framework that goes beyond just front-end development. While React typically focuses on building user interfaces, Next.js enables full-stack applications by handling both the front end and back end in one unified framework. This approach is often referred to as a "Backend for Frontend" (BFF), allowing us to create complete, robust applications with ease.

Importants Links
Github Repository

2 The Project

The goal of this project is to create an event website dedicated to ticket sales. This platform will offer tickets for various types of events and will feature four main pages: the login page, an event feed, the purchase process, and the order summary page.

3 Starting setup

Install Node.JS 18.8 or later.
Creating project

npx create-next-app@latest

Next this, will be show some questions for you:

This will be the name and folder name of your project.
What is your project named? eve

// **YES** - Use typescript is better, for this project, we will be use.
Would you like to use TypeScript? No / Yes

// **YES** - Eslint can help you to avoid errors
Would you like to use ESLint? No / Yes

// **NO** - For this project, we will use styled-components
Would you like to use Tailwind CSS? No / Yes

// **YES**
Would you like your code inside a `src/` directory? No / Yes

// **YES**
Would you like to use App Router? (recommended) No / Yes

// **NO**
Would you like to use Turbopack for `next dev`?  No / Yes

// **NO**
Would you like to customize the import alias (`@/*` by default)? No / Yes
What import alias would you like configured? @/*

Now you can run the command below to see the default Next.js page.

  npm run dev

You can also use this approach, but it will build your application as static pages.

  npm run start

4 Rounting

Next.js provides an easy way to handle routing in your application based on path names. Let’s take a closer look at each case.

1. Commom routing

In the /src/app directory, look for the page.tsx file. Every page file in Next.js is named this way, and you must always export it as the default. This is the default page displayed when you access ´http://localhost:3000´.
Now, let’s create a new route: inside the src/app directory, create a folder called auth. Within this folder, create a file named page.tsx. In this file, let’s add a simple div element with the text "login

export default function Auth() {
  return <div>login</div>;
}

When you access "http://localhost:3000/auth" you need see only this:

2 - Grouping Routes

Sometimes we need to separate our code in more paths, but dont wanna change de url.

Change the 'auth' path to '(auth)' and create a path inside calls 'login' and move the last file to them.

Check two things:

the '/auth' url not working now, if you try access a 404 error will show you.
if you access '/login' you will see our component.

So this help us to create modules in the project without interfering with the user experience.

4 - Dynamic Routes

For a dynamic page, such as a product sales page, the layout should adapt to the product's specific information. In this case, details like the product name and price vary for each product.

We achieve this by using a product ID to fetch the relevant information, typically obtained from the URL.

To implement this, follow these steps:

Inside /app, create a folder named events.
Inside the events folder, create another folder named [id]—the brackets indicate a dynamic route for the product ID.
Inside the [id] folder, create a file named page.tsx.

In page.tsx add this code:

'use client' //<- this is important, because whe are using a hook
//so we need to inform its a client side
import { useParams } from "next/navigation";

export default function EventInfo() {
    const params = useParams(); // get url params

    return <div>{params.id}</div>;
  }

Now you can access '/events/111' and see this:

7 Project Routes

We already know the basics features to start our development, so let's get started intalling the dependencies.

npm i styled-components react-query

Creating authentication pages

Auth routes

Inside '(auth)' path create a "register", your path must looks likes this:

Platform routes

Inside 'app' path create a "platform"
Inside "platform" create "[id]"
Inside "platform" create "purchase"

Your path must looks likes this:

In this step you can create genericals pages, this articles is focus on nextjs features.

7 Project Routes - Middlewares

In our project, there are publics routers and privates routers, to protect and control the access, we need learn about middlewares.

Middlewares is a function that will be execute in every load page and to configure this:

At 'src' path create middleware.ts
Inside the file add this code.

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export default function middleware(request: NextRequest) {
  return NextResponse.redirect(new URL('/home', request.url))
}

Still inside this file, create 2 arrays

// Only authenticated access
const protectedRoutes = ["/platform"];

const publicRoutes = ["/login", "/register"];

Inside middleware function, we will verify the router rule and user session.

export function middleware(request: NextRequest) {
  // URL ACESSED
  const { pathname } = request.nextUrl;
  // USER SESSION
  const userId = request.cookies.get("user-id");

  // FUNCTION TO VERIFY IF IS A PROTECTED ROUTER
  const isPrivateRouter = protectedRoutes.some((path: string) =>
    pathname.startsWith(path)
  );

  if (isPrivateRouter && userId) {
    return NextResponse.next();
  }

  if (isPrivateRouter && !userId) {
    return NextResponse.redirect(new URL("/login", request.url));
  }

  // FUNCTION TO VERIFY IF IS A PUBLIC ROUTER
  const isPublicRouter = publicRoutes.some((path: string) =>
    pathname.startsWith(path)
  );

  if (isPublicRouter && !userId) {
    return NextResponse.next();
  }

  if (isPublicRouter && userId) {
    return NextResponse.redirect(new URL("/platform", request.url));
  }

  // REDIRECT TO LOGIN IF URL IS INVALID
  return NextResponse.redirect(new URL("/login", request.url));
}

If you dont wanna execute the middleware in especifics routers, you can add in the same file this:

export const config = {
  matcher: ['/login'],
}

7 Navigating between pages

In this step, disable the middleware.

To navigate between pages we must to use two ways.

When is a link options, the next component is the better instead the default html tag, because don't re rendering a page and causing a new pre render on server, and the Next Link component doesn't.

For example, create a button at login page for navigate to inside the platform.

When you click at button, you will see a re render page.

So let's try to use the next component.

Navigating like that, do you have a SPA (A SINGLE PAGE APPLICATION), that's made a better user experience.

Another way to do the same thing is using a router hook from next.

Conclusion

In this article, we explored key Next.js features, including the fundamentals of routing, creating dynamic and nested pages, organizing code with route groups, and implementing authentication and access control using middleware. Additionally, we learned how to optimize navigation for a better user experience by leveraging the Link component and programmatic routing with the useRouter hook. These concepts lay a strong foundation for building scalable and user-friendly applications with Next.js

O que é o Nginx?

Layssa Lima — Fri, 07 Apr 2023 20:59:33 +0000

O que é o Nginx?

O Nginx inicialmente foi construído para ser usado como servidor web, em resposta a um problema chamado C10K, esse problema era gerenciar 10 mil conexões simultâneas. Todavia, dado o desempenho ao longo do tempo, a ferramenta foi aumentando as funcionalidades, atuando hoje como: webserver, load balancer, proxy reverso, media streaming, além de proxy para serviços de e-mail.

Como ele funciona?

Hoje o Nginx é um dos servidores mais seguros e escaláveis por usar conexão orientada a eventos e assíncrona. E o que isso significa?

Ele usa o funcionamento de single thread para as requisições recebidas, explicarei logo abaixo, de maneira que pouca memória é necessária.

Ok, mas o que é a single thread?
Analise a imagem abaixo, o nginx possui uma fila de processos, chamada Thread Master, essa por sua vez gerencia os workers, que são os responsáveis por de fato executar a tarefas, onde cada um é alocado em núcleos de processamentos da máquina.

Agora que entendemos as divisões de tarefas dos núcleos, precisamos entender o porquê do nginx ser assíncrono e orientado a eventos.

Veja bem, imagine um servidor que recebe 100 requisições por segundo, onde o tempo de resposta varie e não sabemos ao certo quando o processamento irá ser finalizado. Nesse cenário, não podemos travar o servidor, impedindo que ele receba novas requisições, logo, enquanto uma tarefa X aguarda resposta, outras são resolvidas simultaneamente. Note que aqui encontramos mais uma característica do server, ele não faz com que uma tarefa seja bloqueada em detrimento de outra, há uma reorientação de recursos enquanto aguarda resposta, isso é possível porque é criado um canal de escuta que avisará quando tudo estiver concluído, sendo assim, orientado a eventos.

Você pode ler um pouco mais sobre isso aqui.