Os 3 elementos da composição de backend que você precisa conhecer para planejar um backend
(maily.so)O núcleo de um ambiente de backend está em entregar dados ao usuário com estabilidade. Para isso, três elementos centrais são indispensáveis: servidor web, WAS e banco de dados. Esses três vêm evoluindo para resolver os problemas que surgiram ao longo do desenvolvimento da web. Tecnologias avançadas como monitoramento, balanceamento de carga, cache, pipelines de CI/CD e Kubernetes são como construir uma casa que pode desabar a qualquer momento se não houver antes uma compreensão desses três elementos.
Primeiro, o papel do servidor web
O principal papel do servidor web era ser um servidor de arquivos que entrega arquivos, e exemplos representativos incluem Nginx, Apache, IIS e Caddy. Esses servidores web são altamente otimizados e se destacam em sua função básica de fornecer arquivos estáticos.
Segundo, o surgimento e o papel do WAS (Web Application Server)
O WAS funciona recebendo uma determinada requisição, executando um programa previamente definido e exibindo ao usuário o resultado produzido por esse programa. Pode-se dizer que essa forma marcou o verdadeiro nascimento do backend: o momento em que o servidor deixou de apenas exibir arquivos e passou a pensar, calcular e processar lógica. Enquanto o servidor web sempre retorna a mesma página estática, o WAS retorna páginas dinâmicas.
Terceiro, a necessidade e o papel do banco de dados
O banco de dados desempenha o papel de armazenar dados de forma permanente, gerenciá-los com segurança e controlar o acesso simultâneo.
Além disso, outros conhecimentos muito úteis para o planejamento de backend incluem o design de APIs RESTful (princípios de projeto de API baseados no estilo arquitetural REST, como design de URL centrado em recursos, significado do HTTP (GET, POST, PUT, DELETE etc.) e uso de códigos de status), autenticação (compreensão básica de formas de autenticação e autorização de usuários, como autenticação baseada em sessão, além da definição de políticas de gestão de usuários) e tratamento de erros (conceitos sobre o tratamento de casos excepcionais, essenciais para garantir a estabilidade do sistema).
8 comentários
Tem gente que acha que backend no mundo só usa protocolo web
Dizem que são os 3 elementos centrais do backend, mas aí aparece servidor web e já fico desnorteado
Como coisas como ALB e CDN já fazem tudo o que se espera que um servidor web faça, não entendo por que insistir exatamente nisso. Vocês por acaso têm algum caso real de segurança que só pôde ser bloqueado porque havia um servidor web?
Se o ALB substitui funcionalmente o servidor web e os usuários não conseguem acessar diretamente o backend, como o WAS, então podemos considerar que isso atende à configuração do ambiente de segurança existente. E muitos serviços ainda continuam operando em ambientes on-premises.
Do ponto de vista da segurança, ainda acho que é necessário separar o Web Server e o servidor WAS. Isso não muda em um ambiente cloud-native. Backends como o WAS não devem ficar em uma camada à qual o usuário possa se conectar diretamente.
Ainda faz sentido entender os conceitos de servidor web / WAS?
Na época em que Java EE, php e CGI estavam em alta, era uma distinção adequada, mas hoje em dia praticamente qualquer linguagem já vem com seu próprio servidor HTTP embutido, e com o surgimento e a popularização de conceitos como ALB, API Gateway, CDN e Object Storage, os tempos mudaram.
Pelo contrário, sem esse contexto histórico, a noção de Web Server e WAS — que é bem diferente do cenário atual — já não parece mais um conceito adequado e me dá a impressão de que só acaba trazendo ainda mais confusão para quem está começando.
No setor de fintech, por causa dos requisitos de segurança, ainda há muitos ambientes em que Web-WAS ficam separados. Como a gente nunca sabe em que tipo de ambiente vai cair, acho certo se preparar para qualquer cenário rs
Mesmo no ambiente de nuvem atual, isso ainda é usado para equilibrar com eficiência múltiplos WAS dentro de uma única instância para lidar com grande volume de processamento.
Se houver poucas requisições de rede, talvez não seja necessário.
Concordo. Acho que ensinar os princípios do 12-factor app e os padrões cloud-native seria mais prático. O conceito em si já está ultrapassado demais.