Conteúdo original em https://twitter.com/zanfranceschi/status/1572802485055815681
Ei dev,
As eleições estão aí e precisamos falar sobre Estado! Zoeira! 🤭
Bom, talvez você já tenha ouvido os termos STATELESS e STATEFUL. Se tem dúvida sobre esses termos, cola mais pra ficar bem na fita e fazer bonito nos churrascos. 😎
cc @sseraphini
↓
Quando falamos STATELESS ou STATEFUL, geralmente estamos falando sobre a capacidade de correlacionar (ou não) transações dentro de um processo de uma aplicação – um servidor executando uma API, um consumidor que roda em background, etc.
Esses termos estão relacionados sobre como um processo lida com seu estado – STATE.
FULL é cheio, completo. LESS significa "sem".
Ainda não tá suave, né? Guenta aí! Confia! Não desiste de mim ainda.
STATELESS
Um processo stateless é um processo que NÃO correlaciona transações ou instâncias de processamento.
Um exemplo seria abrir um terminal e executar queries em um banco de dados. O resultado da sua query atual não depende do resultado de queries anteriores.
É como se cada query estivesse sendo executada pela 1ª vez.
Muitas aplicações web modernas possuem processos stateless. Elas são mais fáceis de escalar porque a carga pode ser distribuída facilmente entre todos os processos justamente por não haver correlação entre requisições.
De forma resumida e simplificada, um processo stateless é um processo que não mantém informações de processamentos anteriores na memória.
Extrapolando bastante o termo, é como se cada transação fosse uma unidade discreta de processamento – o oposto de contínuo.
STATEFUL
Como você já deve imaginar, um processo stateful é o "oposto" de stateless, pois as transações correlacionam informações de transações anteriores em memória. Ou seja, para chegar ao 3ª passo pela 2ª vez, você provavelmente terá que fazer os passos 1 e 2 novamente.
Por exemplo, para fazer um chatbot (sem banco de dados), você precisaria armazenar as respostas anteriores para responder e oferecer as próximas opções de forma adequada.
Existem aplicações web que são stateful em relação a usuários logados. Ou seja, num arranjo com mais de um servidor, se o usuário loga em um servidor e a próxima requisição cai em outro, esta provavelmente será negada – os outros nós não possuem a informação do login realizado.
Geralmente, aplicações com processos stateful são mais difíceis/chatas de escalar/operar pois precisam manter um mapeamento* entre clientes e servidores específicos.
* Procure por Load Balancer Session Affinity.
MAIS ESTADO!
É importante ressaltar que tudo anteriormente mencionado referente a estado nessa thread, é referente a estado de PROCESSOS e não a estado de aplicações como um todo (servidores web, banco de dados, etc.).
É normal nos referirmos também ao "estado da aplicação" duma forma mais abrangente. É o estado persistido em discos, em bancos, etc.
Afinal, aplicações muito frequentemente possuem estado (usuários, contas, imagens, etc.).
Ou seja, o ESTADO DE APLICAÇÃO geralmente pode ser entendido como o estado somado de todos seus componentes (servidores web, bancos de dados, arquivos, etc.).
E o ESTADO DO PROCESSO (ou a falta dele) é o estado de apenas um componente visto de forma isolada.
Ufa, acabou!
Esse tipo de conceito é mais fácil de entender na prática do que na teoria.
Fiz o meu melhor pra tentar te explicar um pouco sobre o conceito, mas se não ficou muito claro, não tem problema: pergunta aqui. Seu dia-a-dia também vai deixar esse assunto mais claro.
Obrigado demais se você leu até aqui. São pessoas como você que me fazem continuar a produzir esse tipo de conteúdo.
Se puder comentar, dar RT, like, etc. te agradeço demais! Show me some love, please. 💕
Top comments (0)