DEV Community: Elenndev

Stop Storing Secrets in Your Frontend .env File

Elenndev — Wed, 12 Nov 2025 12:10:07 +0000

The real deal about env variables

By the time i realized it, i had already started to understand environment variables as an always trusted way to store secret values, which well, isn't completely wrong but not the most effective way to understand them, because env variables behave differently on backend and frontend, so understand this difference is super important to avoid some some tricky and risky situation.
But then how do we define what env variables are? The most intuitive way is to say that they are dynamically set values that are set in the environment where a program executes instead of directly in the code, making our applications easier to configure, so they have different behaviors depending on the value defined in that environment.

## value in the development .env file
API_URL=http://localhost:3000/

## value in the prod .env file
API_URL=https://yourdomain/

So since the value isn't explicit in the code, in fact we can say that the value is more secure when we use env variables, you make sure to put the .env file in the .gitignore so git won't track it, and in your backend application code, you use some libraries like dotenv so your app can use these values and since it's a backend application, this value never leaves the server, so yep we're safe so far :).
But when it comes to frontend applications, like React, Vite, etc, we still can use "env variables" but they don't remain secret. They are still env variables because their main functionality, having their value defined within the environment, still remains, but this it's when i remember what i highlighted in the beginning of how thinking of them as an always trusted way to store values can be dangerous.

How frontend deals with env variables

When we run the app, our frontend framework it will produce a static javascript bundle. For example, when we use this in the code:

VITE_SECRET_KEY=abc

const secretKey = import.meta.env.VITE_SECRET_KEY
console.log(secretKey)

This import.meta.env.VITE_SECRET_KEY is replaced with the literal value that we put in our .env file. So when we build and run our application:

npm run build
npx vite preview

Then open the browser's inspect:

Of course you shouldn't console.log your env variables in backend applications, much less at frontend ones, but on this code i just want to show how the literal value of your env variables is going to reach the client.

So i can't use them on the frontend?

Not exactly :p. Using environment variables in the frontend is still something you can do to take advantage of their flexibility and benefits, but only for non-sensitive configuration values such as API endpoints, app modes or even public service keys.
When your frontend needs to use some sensitive information, always use a backend middleware to handle that data securely, so the secret data stays hidden on the server while the frontend still gets access to the functionality it needs.

Dados, rótulos e aprendizado: Entendendo os processos que moldam a inteligência artificial

Elenndev — Sat, 11 Oct 2025 23:50:03 +0000

Introdução

Essa publicação apresenta uma visão clara e objetiva sobre o processo de rotulagem de dados e paradigmas de aprendizagem que formam o treinamento de modelos de IA, servindo como base sólida para um estudo mais aprofundado posteriormente.

Rotulagem de dados

Podemos definir essa rotulagem como o processo de analisar dados brutos e adicionar rótulos significativos e informativos (tags, anotações, palavras-chave) para que a IA possa aprender com esse dado.
Essa etapa é crucial para o aprendizado de um modelo, pois a qualidade das respostas da IA reflete diretamente a qualidade dos dados com os quais ela foi treinada.
Alguns exemplos de rotulagem de dados:

Rotulagem de imagem: Tags relevantes são atribuídos para identificar elementos em uma imagem, permitindo que a IA aprenda a distinguir objetos.
Rotulagem de texto: Adiciona informações úteis ao material escrito para que a IA possa identificar o assunto e os tópicos do conteúdo, diagnosticar erros e sugerir melhorias.
Rotulagem de áudio: Converter dados de áudio para material escrito e extrair dados relevantes como identificar emoções.
Rotulagem de vídeo: Atribuir tags avançadas para que a IA consiga identificar objetos no vídeo, compreender o acontecimento de ações na cena e contexto do momento.

Agora que o conceito desse processo e a sua importância já estão claros, vamos compreender as diferentes maneiras de se realizar a rotulagem dos dados.

Tipos de rotulagem de dados

Rotulagem manual: A Rotulagem é feita manualmente por equipes humanas, essa abordagem é aplicada principalmente em cenários em que a consequência de falha é alta, pois embora seja uma opção mais lenta, garante a alta qualidade dos rótulos.
Rotulagem automatizada: O modelo de machine learning que irá ter a responsabilidade de realizar a rotulagem, portanto esses modelos devem ser capazes de identificar padrões para descobrirem as regras de rotulagem. Aumenta a eficiência do processo, porém se tornam mais vulneráveis a replicação de vieses que os dados originais podem carregar.
Rotulagem semi-automatizada: A rotulagem é feita com a IA que aprende com dados que já foram previamente rotulados, em seguida, a equipe humana vai revisar e corrigir essa rotulagem. Combinando a rotulagem manual e automatizada, essa proposta acelera o processo e mantém a qualidade dos dados.

Paradigmas de aprendizagem

Supervisionada

Essa aprendizagem incorpora uma visão empirista, aonde o conhecimento é construído a partir de experiências. Isso significa que o algoritmo aprende a partir de um conjunto de dados rotulado e que cada amostra do treinamento possui uma entrada-saída esperada.
Durante o treinamento o modelo faz previsões para cada amostra e no final compara os resultados obtidos com os rótulos reais para ajustar os parâmetros e minimizar erros.
A aprendizagem supervisionada tem o objetivo de treinar a máquina para descobrir o padrão e as relações existentes entre os dados, comumente utilizada em classificar imagens e realizar filtros.

Não supervisionada

Ela se baseia em teorias construtivistas pois o sistema organiza os dados brutos por conta própria, buscando padrões e identificando estruturas.
Nessa abordagem as saídas correspondentes são desconhecidas, se mostrando ideal para cenários em que existe uma grande quantidade de dados não rotulados, por isso, é essencial que os resultados sejam analisados por especialistas para garantir a qualidade das saídas e refinar o modelo, sendo bastante utilizada para simplificar informações e para clusterização.

Semi-supervisionada

Esse paradigma combina um conjunto de dados rotulados com dados não rotulados, imitando o aprendizado humano que aprende a partir de experiência e exemplos.
Ela se inicia com o treinamento do algoritmo utilizando o conjunto de dados rotulados e avança usando em seu treinamento os dados não rotulados, dessa forma, os dados rotulados são a base essencial para todo o processo de aprendizado do modelo.

Aprendizagem auto-supervisionada

Muito utilizada em NLP (Processamento de linguagem natural, em inglês, Natural Language Processing), essa abordagem busca gerar rótulos a partir da estrutura dos dados, utilizando os dados não rotulados para criar sinais de treinamento, ou seja, prevendo partes faltantes das entradas, a partir das partes existentes.
Para serem capazes de fazer isso, os modelos devem passar por tarefas pré-treinamento como prever o próximo token, esses exercícios buscam fazer com o que o modelo possa compreender o contexto e as relações dos dados.

Aprendizagem por reforço

Essa aprendizagem se alinha com a abordagem behaviorista, ou seja, o conhecimento é moldado por meio de interações com o ambiente e as recompensas ou penalidades recebidos pelas ações realizadas e espelha processos naturais de aprendizagem.
Nessa forma de aprendizagem ao invés de utilizar dados rotulados ou não rotulados para aprender como nos paradigmas apresentados anteriormente, o modelo aprende a atingir um objetivo em um ambiente incerto, utilizando tentativa e erro para encontrar uma maneira de alcançar aquela meta, recebendo recompensas ou penalidades pelas ações que executa durante o processo.
Embora o engenheiro defina as regras de recompensa, cabe ao modelo descobrir as melhores práticas para maximizar as recompensas.
Um dos desafios para a aplicação dessa paradigma é definir as funções de recompensas pois recompensas mal projetadas pode levar a comportamentos não intencionais.

Conclusão

A rotulagem de dados é o pilar no qual se constrói o aprendizado da inteligencia artificial, e pode ser realizada de diversas maneiras, assim como os paradigmas de aprendizado que oferecem diferentes estratégias de treinamento.
Compreender esses conceitos e diferentes abordagens permite aprimorar a eficiência de modelos éticos e escaláveis.

Referências

Object Calisthenics: um treino para programadores, não para máquinas

Elenndev — Tue, 19 Aug 2025 17:46:12 +0000

Como desenvolvedores o que sempre buscamos é aprimorar a nossa escrita de código, não apenas no sentido de performance, buscando algoritmos mais eficientes, mas também na legibilidade. Afinal, não escrevemos código apenas para a máquina, mas para pessoas, seja outro desenvolvedor ou você mesmo no futuro. Por isso, é fundamental desenvolver utilizando boas práticas, que incluem desde arquiteturas específicas ou simplesmente alguns princípios que quando bem aplicados levam seu código para outro nível.
O que será abordado nesta publicação é o Object Calisthenics, suas regras não só de forma teórica mas também com exemplos trazendo primeiro um código 'bagunçado' e logo em seguida o refatorar aplicando essas regras.
Além desse conceito, ao implementar esse princípio, também serão explicados outros conceitos como:

Guardianship Clause;
Fail-Fast;
Early Return;
Primitive Obsession

Conceito

Primeiro, o que é o Object Calisthenics afinal? Criado por Jeff Bay no seu livro ThoughtWorks Anthology, é um conjunto de princípios que buscam aprimorar a qualidade do código e tornar mais fácil a manutenção e os testes especificamente na programação orientada a objeto.
São as 9 regras:

Only One Level Of Indentation Per Method
Don’t Use The ELSE Keyword
Wrap All Primitives And Strings
First Class Collections
One Dot Per Line
Don’t Abbreviate
Keep All Entities Small
No Classes With More Than Two Instance Variables
No Getters/Setters/Properties

Vamos entender com mais detalhes cada uma delas.

Antes de prosseguir é importante lembrar que não necessariamente é obrigatório seguir todas as 'regras', vão existir exceções e situações em que o que é definido na regra, pode ser considerado 'negociável'.

1. Only One Level Of Indentation Per Method / 2. Don’t Use The ELSE Keyword

Vamos ver as 2 primeiras regras (1. Apenas 1 nível de indentação por método e 2. Não use ELSE) juntas pois elas se completam.
Vamos analisar esse código:

  public Employee(String name, int age, String role, String department) {
    if (!name.equals("")) {
      if (age >= 18) {
        if ("accountant".equals(role) || "seller".equals(role)) {
          if ("sales".equals(department) || "administrative".equals(department)) {
            this.age = age;
            this.name = name;
            this.role = role;
            this.department = department;
          } else {
            throw new IllegalArgumentException("Invalid department");
          }
        } else {
          throw new IllegalArgumentException("Invalid role");
        }
      } else {
        throw new IllegalArgumentException("Invalid age");
      }
    } else {
      throw new IllegalArgumentException("Invalid name");
    }
  }

Este código é bem simples, ele é o método construtor da classe Employee que faz um conjunto de validações dos valores antes de instanciar de fato a classe e prosseguir com o código. Porém mesmo sendo um código simples, já se percebe de cara a quantidade de if's presentes nesse processo de validação, tornando o código complicado de se ler.
Mas as validações são necessárias para instanciar essa classe, então como podemos arrumar isso sem arruinar a funcionalidade do código?
Neste caso é utilizar o princípio do Guardianship Clause juntamente com o Fail-Fast ou o Early Return. Podemos definir esses 3 termos de forma simples:

Guardianship Clause são cláusulas que verificam condições necessárias ou inesperadas no inicio de um método.
Fail-Fast significa algo como errar logo/imediatamente, essa abordagem prioriza a detecção e tratamento imediato de erros e falhas.
Early Return pode ser traduzido como retornar o mais cedo possível, aqui é priorizado a situação esperada do método/função.

Então vamos começar aplicando isso no nosso código, usando a abordagem do Fail-Fast na verificação de if (!name.equals("")) que verifica se name é um nome válido.

  public Employee(String name, int age, String role, String department) {
    if (name.equals("")) {
      throw new IllegalArgumentException("Invalid name");
    }

    if (age >= 18) {
      if ("accountant".equals(role) || "seller".equals(role)) {
        if ("sales".equals(department) || "administrative".equals(department)) {
          this.age = age;
          this.name = name;
          this.role = role;
          this.department = department;
        } else {
          throw new IllegalArgumentException("Invalid department");
        }
      } else {
        throw new IllegalArgumentException("Invalid role");
      }
    } else {
      throw new IllegalArgumentException("Invalid age");
    }
  }

Note que como estamos usando o Fail-Fast, ao invés de verificar se name tem um valor válido, estamos verificando se ele tem um valor inválido para assim tratar logo isso, nesse caso retornando um erro e impedindo que a função prossiga já que o dado não é válido.
Com essa mudança fomos de 4 blocos de if-else para 3, agora é só aplicar a mesma lógica nos 3 ifs restantes:

  public Employee(String name, int age, String role, String department) {
    if (name.equals("")) {
      throw new IllegalArgumentException("Invalid name");
    }

    if (age < 18) {
      throw new IllegalArgumentException("Invalid age");
    }

    if (!"accountant".equals(role) && !"seller".equals(role)) {
      throw new IllegalArgumentException("Invalid role");
    }

    if (!"sales".equals(department) && !"administrative".equals(department)) {
      throw new IllegalArgumentException("Invalid department");
    }

    this.age = age;
    this.name = name;
    this.role = role;
    this.department = department;
  }
}

E agora temos o código funcionando da mesma forma porém dessa vez muito mais legível, sem else, e atendendo também a regra de apenas 1 nível de indentação.

3. Envolva seus tipos primitivos e strings

Muitas vezes acabamos caindo no chamado Primitive Obsession, essa obsessão por tipos primitivos acontece quando usamos tipos primitivos para representar objetos que possuem comportamentos específicos. Essa regra busca eliminar esse problema, encapsulando os tipos primitivos em objetos.
Vamos entender na prática, na forma como código se encontra agora, note como cada atributo tem um comportamento próprio que não são comportamentos primitivos de uma String. Porém as validações dos valores do atributo acontecem dentro do constructor do objeto Employee, ao deixar essas verificações espalhadas pela classe, começamos a violar o princípio de responsabilidade única além de tornar o código menos reutilizável e dificultoso de ser incrementado.
Sendo assim, podemos resolver isso criando uma classe pra cada atributo assim a classe é responsável por fazer a sua própria validação ao ser instanciada:

class Age {
  private int value;

  public Age(int age){
    if (age < 18) {
      throw new IllegalArgumentException("Invalid age");
    }
    this.value = age;
  }

  public int getValue(){
    return this.value;
  }
}

class Name {
  private String value;

  public Name(String name){
    if (name.equals("")) {
      throw new IllegalArgumentException("Invalid name");
    }
    this.value = name;
  }
   public String getValue(){
    return this.value;
  }
}

class Role {
  private String value;

  public Role(String role){
    if (!"accountant".equals(role) && !"seller".equals(role)) {
      throw new IllegalArgumentException("Invalid role");
    }
    this.value = role;
  }

  public String getValue(){
    return this.value;
  }
}

class Department {
  private String value;

  public Department(String department){
    if (!"sales".equals(department) && !"administrative".equals(department)) {
      throw new IllegalArgumentException("Invalid department");
    }
    this.value = department;
  }
  public String getValue(){
    return this.value;
  }
}

Dessa forma, podemos atualizar a classe Employee:

class Employee {
  private Name name;
  private Age age;
  private Role role;
  private Department department;

  public Employee(Name name, Age age, Role role, Department department) {
    this.age = age;
    this.name = name;
    this.role = role;
    this.department = department;
  }
}

4. First class collections

Essa regra diz que se você tem uma coleção de elementos, tenha uma classe dedicada a essa coleção, ao invés de usar diretamente a lista como um atributo de outra classe. Mais uma vez vamos esclarecer isso com um exemplo prático, já temos uma classe para o Employee, vamos criar uma classe para a organização:

class Company {
  private List<Employee> employees;
  private LegalName legalName;
  private CNPJ cnpj;

  public Company(List<Employee> employees, LegalName legalName, CNPJ cnpj) {
    this.employees = employees;
    this.legalName = legalName;
    this.cnpj = cnpj;
  }

  public List<Employee> getEmployees() {
    return employees;
  }

// demais getters...
}

Para aplicar o First Class Collections, vamos encapsular a coleção dentro de uma classe, assim os comportamentos dessa coleção ficarão dentro da sua classe dedicada, então, criando a classe Employees, podemos ter métodos exclusivos do conjunto de instâncias de Employee, como, getters de funcionários de um cargo (Role) ou departamento específicos.

class Employees {
  private List<Employee> value;

  public Employees(List<Employee> employees) {
    if (employees.isEmpty()){
      throw new IllegalArgumentException("Empty employee List");
    }
    this.value = employees;
  }

  public List<Employee> getValue() {
    return value;
  }

  public ByRole(Role role){
    // restante do código
  }
   public ByDepartment(Department department){
    // restante do código
  }
  // outros métodos da **lista** como adicionar um novo employee, remover employees de um departamento especifico, etc...
}

Agora podemos atualizar a classe Company:

class Company {
  private Employees employees;
  private LegalName legalName;
  private CNPJ cnpj;

  public Company(Employees employees, LegalName legalName, CNPJ cnpj) {
    this.employees = employees;
    this.legalName = legalName;
    this.cnpj = cnpj;
  }

  public Employees getEmployees() {
    return employees;
  }
}

5. One Dot Per Line

Vamos adicionar ao Department um chefe do departamento:

class Employee {
  // restante do código ...

  public Department getDepartment() {
    return this.department;
  }

 // restante do código ...
}



class Department {
  // restante do código ...
  private DepartmentHead departmentHead;

  // restante do código ...

  public DepartmentHead getDepartmentHead() {
    return this.departmentHead;
  }
}

class DepartmentHead {
  private Name name;
  private Age age;
  private Role role;

  // constructor da classe

  public Name getName() {
    return this.name;
  }

}

Dessa forma para por exemplo, ter acesso ao nome do chefe do departamento que um Employee X faz parte, teríamos que usar algo como:
employee.getDepartment().getDepartmentHead().getName().getValue().
Quantos pontos aqui né? Da maneira atual, geramos uma espécie de cadeia de chamadas o que resulta na exposição da estrutura da classe sem necessidade pra isso, além de dificultar a leitura do trecho do código.
Podemos resolver isso fazendo com que os objetos tenham métodos que expressem claramente suas intenções, assim ao invés usar o método getDepartment para obter o objeto de departamento do Employee e só depois buscar o nome do DepartmentHead, usamos métodos que vão retornar os valores específicos para isso, vamos esclarecer isso no código:

class Employee {
  // restante do código ...

 // antes:
  // public Department getDepartment() {
    // return this.department;
  // }
  public String getDepartmentHead() {
    return this.department.getDepartmentHead();
  }

// restante do código ...
}

class Department {
  // restante do código

  public String getDepartmentHead() {
    // código antigo: return this.departmentHead;
    return this.departmentHead.getName();
  }
}

class DepartmentHead {
  // restante do código

  public String getName() {
    // código antigo:  return this.name;
    return this.name.getValue();
  }

}

Feito isso, agora para obter o mesmo valor que tentamos antes, precisamos de:

// antes: employee.getDepartment().getDepartmentHead().getName().getValue();
employee.getDepartmentHead();

6. Don’t Abbreviate

Essa regra é bem simples e nem precisa de código para entender, não abrevie!
Mas embora o conceito dela seja simples, muitas vezes violamos essa regra sem nem mesmo perceber. Talvez você já se viu em uma situação em que usou a abreviação como uma forma de fugir da repetição de código, mas aqui já entramos em outro ponto, o problema não está na repetição em si, e sim em algo mais profundo na estrutura do código. Ao seguir essa regra, conseguimos perceber falhas de design que antes poderiam passar despercebidas.

7. Keep All Entities Small

Essa regra diz para mantermos nossas classes pequenas, com no máximo 50 linhas, e naturalmente isso não é nem um pouco fácil e muitas vezes pode se tornar até inviável a depender da complexidade da entidade, isso frequentemente é discutido na comunidade dev, alguns preferem usar essa regra tendo em mente 150 linhas, outros 200, enfim.
Mas como havia dito no início dessa publicação, essas regras são um conjunto de princípios para conseguir alcançar boas práticas, e não uma fórmula perfeita que se seguida rigidamente entrega o melhor software do mundo.
Assim, não tem problema a sua classe passar de 50 linhas, desde que as linhas que constroem essa classe, sejam de fato necessárias, então colocar essa regra em prática é se certificar que o que pode ser reduzido na classe, foi reduzido mas sempre de forma coerente.

8. No Classes With More Than Two Instance Variables

Essa regra diz que não devemos ter mais de 2 instâncias de variável em uma classe, o objetivo dela é reforçar a coesão e composição da classe, pois se uma classe tem vários atributos, isso é um sinal de que ela está assumindo mais responsabilidades do que ela deveria.
Para isso vamos analisar os atributos da classe Employee:

class Employee {
  private Name name;
  private Age age;
  private Role role;
  private Department department;

  // restante do código ...
}

De forma geral, para solucionar esse problema, o que fazemos é quebrar o objeto em objetos menores pra melhor representar o conceito que a classe representa. No nosso exemplo, o nome e a idade são informações pessoais do colaborador, enquanto Cargo e departamento são informações empresariais, então vamos agrupar e corrigir isso:

class PersonalInfo {
  private Name name;
  private Age age;

  public PersonalInfo(Name name, Age age) {
    this.name = name;
    this.age = age;
  }

  // getters e setters
}

class JobInfo {
  private Role role;
  private Department department;

  public JobInfo(Role role, Department department) {
    this.role = role;
    this.department = department;
  }

 // getters e setters
}

class Employee {
  private PersonalInfo personalInfo;
  private JobInfo jobInfo;

  public Employee(PersonalInfo personalInfo, JobInfo jobInfo) {
    this.personalInfo = personalInfo;
    this.jobInfo = jobInfo;
  }

  // restante do código ...
}

9. No Getters/Setters/Properties

Essa regra busca acabar com a exposição de dados internos através dos getters, setters ou propriedades que ao invés de encapsular o comportamento, apenas expõem os dados, violando o o comportamento orientado a objeto.
Vamos ao exemplo no nosso código:

class JobInfo {
  private Role role;
  // restante do código

  public void setRole(Role newRole) {
    this.role = newRole;
  }

 // restante do código ...
}

Da forma atual, para atualizar a informação do cargo, usaríamos o setRole, o que funcionaria, sim, porém vamos lembrar que estamos falando de uma classe, um objeto com seus comportamentos, então algo como mudança de cargo, são ações do contexto, como por exemplo, ser promovido:

class JobInfo {
  private Role role;
  // restante do código ...

  public void promoteToManager(){
    this.role = new Role("manager");
  }

  // restante do código ...
}

Conclusão

O Object Calisthenics não é uma receita perfeita que deve ser seguida à risca, mas um conjunto de exercícios (o nome calistenia não é a toa xd) que nos faz enxergar pontos de melhoria e desenvolver bons costumes quando escrevemos nosso código.
No final das contas, o objetivo é escrever um código que não somente a máquina vai entender e executar, mas que outros desenvolvedores possam compreender, evoluir e manter ao longo do tempo.

MVC X Flux: A diferença entre essas arquiteturas de desenvolvimento

Elenndev — Wed, 18 Jun 2025 13:29:22 +0000

O MVC e o Flux são arquiteturas de desenvolvimento de software populares por prezarem a separação das responsabilidades em uma aplicação, buscando isolar a interface da lógica de negócio.
Embora ambas compartilhem esse princípio, elas também apresentam diferenças na forma de aplicar e estruturar o fluxo de dados e é isso que será abordado nessa publicação.

MVC

Começando com a arquitetura mais velha dentre as duas, o MVC foi desenvolvido para criar um padrão de arquitetura que separasse a aplicação em camadas reduzindo a dependência entre interface, lógica e controle.
As camadas em questão são:

Model: É o Business Object Model (Objeto Modelo do Negócio). Sua responsabilidade é gerenciar e controlar a forma como os dados se comportam por meio das funções lógicas se comportam. Ele é o detentor dos dados e recebe as informações do Controller.
Controller: Camada responsável por intermediar as requisições enviadas pelo View com as respostas fornecidas pelo Model, processando os dados e repassando para outras camadas. De forma simplista, ele controla a comunicação entre os dados e a interação do usuário.
View: Camada responsável por apresentar as informações de forma visual ao usuário e enviar as requisições para o Controller. Então quando uma interação acontece, a interface, ou seja, a View, irá se comunicar com o Controller e este vai enviar os dados para o Model que irá realizar as operações necessárias para atualizar o estado da aplicação, assim o Model pode enviar a resposta para o Controller para que ele atualize a View com as novas informações ou pode tamém se comunicar diretamente com a View. Assim o fluxo de dados é bidirecional, pois a View pode receber atualizações tanto do Model quanto do Controller.

Problemas ao escalar com o MVC e o surgimento do Flux

O Flux foi desenvolvido pelo Facebook com a intenção de ser uma arquitetura que pudesse compensar os problemas que surgem quando se tenta escalar aplicações grandes usando o padrão MVC em interfaces altamente interativas.
O fluxo bidirecional do MVC em grandes aplicações criavam caminhos cruzados de atualizações e assim, geravam complexidade e imprevisibilidade, tornando difícil entender quem mudou o quê na aplicação e podendo surgir problemas de sincronização de estado.
Então o Flux apresenta um fluxo de dados unidirecional, facilitando o rastreamento e manutenção em aplicações complexas.

Entendo o Flux

Como vimos, o Flux é uma arquitetura de desenvolvimento de software que divide a aplicação em camadas e cria um fluxo unidirecional.
As camadas em questão são as seguintes:

Stores: Responsável por gerenciar o estado da aplicação, ela é atualizada cada vez que uma ação é realizada.
Dispatcher: Objeto que gerencia as actions que entram no sistema, quando uma ação surge, ele passa essa ação para os stores registrados.
View: É o componente de interface do usuário, ele é responsável por renderizar a UI e lidar comas interações do usuário. Ele sofrerá uma re-renderização a cada vez que o Store muda de estado. Nesse modelo, a interação do usuário gera um evento, uma action, e esta vai despachar o evento para modificar os dados, essas alterações irão mudar o store de dados e por fim este irá enviar um evento de atualização para a View. O fluxo é unidirecional pois o dispatcher garante que todas as actions passem por ele e a View escuta somente a Store para poder se atualizar.

Principais diferenças

MVC	Flux
A view é atualizada quando o Model Muda	A view é atualizada quando a Store muda
View pode ser atualizada pelo Controller e pelo Model	View atualizada somente quando a Store mudar
Múltiplos pontos de modificação	Caminho único de atualização

Conclusão

Cada uma dessas arquiteturas já se provarão ser eficientes e eficazes no desenvolvimento de software, ambas apresentam vantagens para o desenvolvedor e compartilham semelhanças. Entender as diferenças entre elas ajuda a escolher qual é a mais adequada conforme a complexidade da aplicação, garantindo um desenvolvimento claro, organizado e escalável.

WebSocket: entenda como essa ponte de dados funciona

Elenndev — Mon, 09 Jun 2025 20:35:28 +0000

Introdução

Se você já desenvolveu aplicações que precisam se comunicar em tempo real como chats, jogos online ou sistemas de notificação, provavelmente já ouviu falar do WebSocket. Mas você realmente entende o que é esse protocolo e o que acontece "por baixo dos panos" quando uma conexão WebSocket é estabelecida?
Esse post pretende explicar os conceitos:

Definição de protocolo
Definição do WebSocket e relação com HTTP
WebSocket handshake
Web Socket Frames

Entendendo conceitos primordiais

Antes de partir para explicação sobre o protocolo Web Socket, é essencial termos um entendimento sólido sobre o que é um protocolo afinal.
Um protocolo pode ser entendido como um conjunto de regras que ditam como as informações transmitidas em uma conexão são formatadas, transportadas, recebidas e interpretadas entre os dispositivos de uma rede. Ou seja, é o que permite que sua aplicação desenvolvida com Java, possa se comunicar com uma API desenvolvida com Python por exemplo, independente da linguagem de programação usada para construir o programa, o protocolo é a linguagem comum que torna possível essa comunicação.

Como essa comunicação acontece?

Como dito anteriormente, o protocolo dita como uma comunicação vai ser formatada para ser enviada pela rede de uma API para outra, logo naturalmente é necessário que ambos os lados dessa comunicação estejam seguindo o mesmo protocolo.
Talvez você se pergunte, "como assim o dado precisa ser formatado antes de ser enviado?", isso acontece pois quando se trata de rede, resumindo para facilitar a compreensão, os dados transportados na rede são dados em linguagem de máquina, o velho 0 e 1.
Então se você quer enviar a string "Hello world", antes ela é transformada em código binário, e ai sim, esse valor binário é o valor que vai ser transmitido na rede.
Cada protocolo tem suas próprias regras para fazer essa "tradução", então essa mesma string, ao ser formatada por diferentes protocolos, se tornará um código binário diferente. Por isso a comunicação só vai funcionar se ambos os lados da conexão usarem o mesmo protocolo, além é claro de outros detalhes de segurança.

Entendendo o WebSocket

O WebSocket é um protocolo que permite uma conexão contínua, persistente e bidirecional entre aparelhos, ou seja, é o protocolo que torna possível uma comunicação de via dupla entre o client e o server através de uma mesma conexão.
Então enquanto com HTTPS estamos acostumados com esse fluxo:

Nesse protocolo uma conexão é iniciada com uma requisição e assim que o server envia a response, ela é encerrada.
Com o WebSocket, o negócio é diferente:

Vamos nos aprofundar nessa solicitação, aceitação de conexão e no conceito dos frames mais para frente, mas nesse momento, o que quero destacar é que uma vez feita a conexão, o client consegue enviar e receber várias mensagens do servidor, dentro da mesma conexão.
Uma outra forma de visualizar a diferença do fluxo de comunicação nesses protocolos, é entender uma conexão como uma ponte:

Enquanto no HTTPS essa ponte suporta apenas uma comunicação feita em uma direção por vez, com o WebSocket, varias mensagens, como carros, podem passar por essa ponte em diferentes direções ao mesmo tempo.

Como iniciar uma conexão com o WebSocket

WebSocket handshake

Embora o websocket e o http sejam protocolos distintos, precisamos utilizar o protocolo http para conseguir iniciar uma conexão websocket.
Vamos entender isso melhor voltando para aquele diagrama que apresentei inicialmente:

Começamos com o Client handshake request, que é quando o client faz uma request GET HTTP com um header que solicita um upgrade para o protocolo WebSocket. Essa requisição vai ser basicamente assim:

GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Agora o que acontece é o Server handshake response que é uma response especial que indica se o server aceita ou não a mudança do protocolo atual (HTTP) para o protocolo WebSocket:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Em caso de aprovação e sucesso dessa mudança de protocolo, a resposta do servidor sempre será uma resposta de status 101, qualquer outro status será entendido pelo client como um erro nesse handshake.
Então até o momento, ainda estamos utilizando o protocolo http, uma vez que esse processo de handshake é finalizado com sucesso, ai sim é realizado a troca de protocolo.

WebFrames

Agora que entendemos como essa conexão é iniciada, vamos analisar como a comunicação nela acontece. Enquanto o HTTP como já sabemos é uma comunicação feita através de responses e requests, o WebSocket utiliza frames para se comunicar, esses frames são unidades de informação, uma estrutura de dados que consiste basicamente em um header e um payload. Existem vários tipos de Frames que podem ser classificados como:

Control Frames: Frames que comunicam o estado sobre o WebSocket, é divido em vários tipos como close frame que é usado para encerrar uma conexão, os pings e closing handshake.
Data Frames: Frames que carregam os dados da comunicação. Os Data Frames podem ser fragmentados, ou seja, 1 informação pode ser divida em vários frames para ser transportada. Esses data frames também possuem seus tipos.

Vamos observar a estrutura básica de um frame, disponibilizado pelo Datatracker:

Vamos analisar as partes fundamentais dessa estrutura:

FIN: O primeiro bit do byte, este informa se o frame é o último fragmento ou não daquela informação. Se for 1 é o fragmento final, se for 0 significa que existem mais fragmentos para serem recebidos para que a mensagem seja considerada completa.
OPCODE: Composto pelos últimos 4 bits do primeiro byte. Esses 4 bits definem o tipo de frame.

Tipos de Data Frame

Quando falamos de Data Frames, eles são divididos em diferentes tipos e como mostrado anteriormente, esse tipo é determinado no OPCODE. Por exemplo:

0001 = Informa que é um text frame, que contém um text data codificado em UTF-8.
0010 = Informa que é um binary frame, ou seja, contém conteúdo binário.

Conclusão

O protocolo Web Socket permite uma conexão de duas direções e persistente, tornando possível um melhor desempenho em aplicações que exigem uma troca de dados em tempo real como por exemplo um aplicativo de chat.
Embora na prática, ao implementar esse protocolo em projetos, é comum comum utilizar bibliotecas que facilitam esse processo pro desenvolvedor como por exemplo o Socket.IO em aplicações com Javascript, é fundamental termos conhecimento de como esses processos funcionam.
Um exemplo desse protocolo funcionando na prática, desenvolvido com React e NodeJs, pode ser conferido no GitHub.

Leituras que auxiliaram essa publicação:

Desvendando SSR, CSR, SSG e RSC: Entenda de vez essas siglas do React e Next.js

Elenndev — Sat, 03 May 2025 18:30:08 +0000

Quando decidi ir além do react e me aprofundar nos estudos com Next.JS frequentemente me via cercada por essa sopa de letrinhas, SSR, CSR, RSC, quantas siglas ein?
Em muitos momentos esses conceitos se relacionam e por terem nomes semelhantes podem ser facilmente confundidos principalmente quando estamos iniciando nos estudos.
Esse post tem o objetivo de esclarecer o conceito, diferença e aplicação dos seguintes termos:

SSR
SSG
CSR
React Component
React Element

Diferença iniciais

Antes de se aprofundar nos conceitos um por um, é importante esclarecer o que para mim é a chave para diferenciar eles:
O SSR (Server Side Rendering), CSR (Client Side Rendering) e SSG (Static Site Generation) se referem a estratégia de renderização em nível de página, já o RSC (React Server Components) se refere a renderização dos componentes que posteriormente formarão a página, ou seja, enquanto o output do SSR e CSR é o HTML, o output de um RSC é uma notação customizada, semelhante a um JSON que descreve como deve ser feita a renderização do componente, se essa última parte ficou um pouco confusa, não se preocupe, iremos nos aprofundar com um exemplo logo adiante mas é importante lembrar das diferença chave:

SSR, CSR, SSG: Nível de página
RSC: Nível de componente.

CSR

Conceito

O CSR é a estratégia de renderizar o UI no navegador. Logo após fazer a requisição, a resposta que o servidor entregará será ao invés da página pronta, um html vazio e o pacote de javascript que contém todas as instruções para gerar a página completa, ao chegar no navegador esse código é rodado e a página é computada já com interatividade.
A vantagem é que quando a página é renderizada pela primeira vez ela já será interativa, a desvantagem é que quando o usuário recebe a resposta da sua requisição, ele ainda precisa esperar o código ser rodado no navegador para gerar de fato a página e enquanto isso ele vai ficar visualizando aquela famosa página em branco.

Exemplo na prática

Esse é o conceito que temos contato direto ao trabalhar com React, veja um exemplo simples de um App.tsx que renderiza um componente react

// app.tsx
import Homepage from './pages/Home/Homepage'
function App() {
  return (
    <Homepage/>
  )
}
export default App

// Homepage.tsx
const Homepage = () => {
    console.log("Esse log aparecerá no console do navegador!")
    return (<h1>Esse é o h1 do componente Homepage!</h1>)
}
export default Homepage

O output será algo como:

Primeiro, note que o console.log aparece no console do navegador, além disso ali temos o nosso h1que foi renderizado dentro da div com o id root. Agora desative o javascript da página no navegador e recarregue a página. Vamos ver o que aparece agora:

Uma página em branco que contém apenas a div root, além disso o console.log também não está aparecendo, o que aconteceu?
Aqui o servidor fez a parte dele, ele enviou o código react que o navegador precisa rodar para renderizar o UI, mas como desativamos o javascript do navegador ele não conseguiu completar sua missão de renderizar a página.

SSR (Server Side Rendering), SSG (Static Site Generation) e RSC (React Server Components)

Conceitos

Vamos começar com SSR E SSG pois ambos são bastante semelhantes e passam pelo mesmo processo de "hidratação" da página.
O SSR é a estratégia de renderizar a página completamente no servidor, assim a renderização acontece no server quando a requisição é feita.
Dessa maneira a vantagem é que a resposta da requisição do usuário será a página prontinha, logo o usuário recebe a página rapidamente.
A desvantagem é que esse HTML entregue é completamente estático, a interatividade só é possível depois que acontece o processo de hydration que é uma segunda renderização, vamos entender o que é esse conceito e como ele funciona.
Além do HTML pronto o servidor também envia o pacote javascript, este será rodado no navegador (lembrando que o conteúdo estático da página já está montado) para montar uma DOM virtual e logo em seguida comparar a DOM virtual com a DOM real para que a real seja atualizada com a interatividade.
Esse processo de atualizar a DOM real adicionando interatividade é o que chamados de hydration ou simplesmente hidratação.

Agora o SSG (Static Site Generation) é bastante semelhante ao SSR pois a renderização também é feita no lado do servidor, a diferença é que enquanto no SSR ela é feita em tempo de requisição, no SSG a renderização é feita no momento do build da aplicação.
Assim no SSG também acontece o método de hydration uma vez que o client recebe o html para que a página tenha interatividade.

Diferença entre React Component e React Element

Então antes de prosseguir para os exemplos e ver na prática como o Next lida com os SSR, SSG e afins, precisamos entender realmente o que é um React component e como ele se torna de fato um conteúdo HTML.
É necessário compreender que um React Component é uma função ou classe que retorna um React Element, pode parecer meio abstrato mas podemos facilmente enxergar isso tanto em uma aplicação React como uma aplicação Next, para isso basta importar um componente react e fazer o console.log dele, vamos entender melhor com um exemplo.
Primeiro vamos criar um React Component que retorna uma div e recebe uma props que vai ser usada para ser o id dessa div:

export default function Container({idContainer} : {idContainer :string}){
    return (
        <div id={idContainer}>
            <p>Aqui temos um parágrafo simples</p>
        </div>
    )
}

Agora vamos importar esse componente em uma página mas além de simplesmente renderizar ele, vamos chamar esse container como uma função em um console.log para ver o output dele:

import Container from "./Container";
export default function Page(){
    console.log(Container({idContainer: 'componenteExemplo'}))
    return (<>
        <Container idContainer={'componenteExemplo'}/>
    </>)
}

Agora vamos observar o console.log que colocamos no terminal:

O que estamos vendo aqui é o React Element que o React Component Container retorna, logo assim fica fácil de compreender que o React Element é um plain object que descreve um componente UI como um DOM node, contendo os seus atributos, os atributos do seus componentes filhos e também do seu componente pai, por exemplo nesse caso o nosso componente é do tipo 'div', ele tem um children que é um 'p' com seus próprios atributos e aqui podemos também ver os atributos do elemento pai que é um Page do servidor. Muito massa né?

Já estamos familiarizandos com os React Client Components que vimos logo no começo ao tratar do conceito de CRS, mas no exemplo de agora o que acabamos de ver foi um React Server Component sendo renderizado no Next.js.
O RSC (React Server Component) entra na história como uma maneira de renderizar o componente react no servidor ao invés do navegador, vamos continuar com o nosso exemplo agora focando no Next.JS, vamos criar um componente Counter e colocar ele dentro do nosso componente Container.

Componente Counter:

'use client'
import { useState } from 'react'

export default function Counter(){
    const [counter, setCounter] = useState(0)
    return(<>
        <p>Valor: {counter}</p>
        <button onClick={()=> setCounter(c => c + 1)}
        className='bg-[#ddd]'>
            Adicionar
        </button>
    </>)
}

Note que adicionamos um 'use client' pois por padrão todos os componentes dentro da pasta App no Next.js são Server Components, então para criar um Client Component temos que adicionar esse 'use client' para declarar isso.
Agora atualizando o nosso Container.tsx:

import Counter from "./Counter";
export default function Container({idContainer} : {idContainer :string}){
    return (
        <div id={idContainer}>
            <p>Aqui temos um parágrafo simples</p>
            <Counter/>
        </div>
    )
}

No navegador temos:

Ao clicar no botão, o valor da variável counter muda e ao mudar seu valor, o conteúdo html muda também. Agora desative o javascript e recarregue a página, de primeira parece que não muda nada, mas ao clicar no botão o comportamento esperado que é a mudança do valor da variável e a renderização que atualiza o UI, não acontece, o que isso significa?
Esse é um exemplo de SSG, que é o comportamento padrão do Next.JS para renderização no servidor, ele renderizou a página no momento do build, e quando atualizamos a página a requisição é feita ao server que já está guardando a página pronta e apenas à envia, como desativamos o javascript no navegador o processo de hydration não aconteceu portanto não temos interatividade. Existem várias formas de mudar esse comportamento para SSR ao invés de SSG no Nextjs mas esse não é o foco desse post.

Então, na prática, qual a diferença entre um React Server Component e um React Client Component no Next.js e no React?
O React é voltado para componentes que rodam no client, ou seja, ele transforma os React Elements em DOM por meio da renderização no navegador. Já o Next.js, nos permite que os componentes sejam executados tanto no cliente quanto no servidor.

Componentes do client, que são aqueles marcados como "client" em um app Next.js são renderizados duas vezes: primeiro no servidor (para gerar HTML inicial) e depois no cliente, onde ocorre a hidratação.
Enquanto os React Server Components (RSCs) são executados exclusivamente no servidor e enviados ao cliente como HTML ou como payload serializado. Eles não têm interatividade direta nem acesso a APIs do navegador (como useState, useEffect), e por isso não passam por hidratação.

--
Espero que esse conteúdo tenha ajudado a esclarecer as principais diferenças entre essas siglas tão comuns no universo do React e do Next.js. Se você curtiu, compartilhe com quem também está nessa jornada de aprendizado. Até a próxima! 🚀