Questão de Programação — Conceitos básicos de programação — FCC 2025
Programação›Conceitos básicos de programação
Código
fc075552
Banca
FCC
Órgão
TRT - 6ª Região (PE)
Ano
2025
Nível
Superior
Cargo
Analista Judiciário - Área Apoio Especializado - Especialidade: Tecnologia da Informação
Ao usar o Gateway APl com o Service Discovery no contexto da PDPJ-Br, a principal consequência para o frontend em uma aplicação baseada em microsserviços é que o
AGateway API diminui a necessidade de autenticação, uma vez que o Service Discovery é integrado ao SSO.
Bfrontend deve configurar manualmente os IPs e portas dos serviços disponíveis na plataforma.
Cfrontend se torna o responsável pela chamada direta de cada microsserviço individualmente.
DGateway APl reduz o número de chamadas externas que o frontend precisa fazer, tornando a comunicação mais eficiente.
Efrontend deve gerenciar manualmente as atualizações de endpoint de cada serviço individual registrado.
Revelar gabarito e comentário▾
GabaritoD — Gateway APl reduz o número de chamadas externas que o frontend precisa fazer, tornando a comunicação mais eficiente.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Gateway API e Service Discovery em Microsserviços
Gabarito: letra D. Em arquiteturas de microsserviços, o Gateway API atua como um ponto único de entrada, combinado com Service Discovery para localizar dinamicamente os serviços. A principal consequência para o frontend é que ele faz uma única chamada ao gateway, que então roteia para os microsserviços internos, reduzindo o número de chamadas externas e tornando a comunicação mais eficiente.
A questão cobra o entendimento do papel do Gateway API (API Gateway) e do Service Discovery em um ambiente de microsserviços, que são padrões arquiteturais essenciais para desacoplar o frontend dos detalhes de infraestrutura dos serviços.
1Frontend faz 1 chamada ao Gateway
2Gateway consulta Service Discovery
3Gateway roteia para microsserviço interno
4Resposta retorna ao frontend via gateway
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
A presença do Gateway API não diminui a necessidade de autenticação; a autenticação é um requisito de segurança que pode ser centralizada no gateway, mas não reduzida. O Service Discovery também não está integrado ao SSO (Single Sign-On) por padrão — o SSO é uma solução de identidade separada.
Alternativa B — ❌ Incorreta
O frontend não precisa configurar manualmente IPs e portas dos serviços. Essa é justamente a função do Service Discovery: abstrair a localização dos serviços, permitindo que seus endereços sejam descobertos dinamicamente.
Alternativa C — ❌ Incorreta
Em uma arquitetura com Gateway API, o frontend não chama diretamente cada microsserviço. O frontend se comunica apenas com o gateway, que faz o roteamento para os serviços internos. Chamar cada microsserviço individualmente seria um anti-padrão que expõe a complexidade e pontos de falha.
Alternativa D — ✅ Correta ⟵ GABARITO
O Gateway API reduz o número de chamadas externas que o frontend precisa fazer, pois ele consolida múltiplas requisições em uma única chamada ao gateway, que internamente resolve e roteia as requisições para os microsserviços relevantes. Isso simplifica o frontend, melhora a eficiência e reduz a latência de comunicação.
Alternativa E — ❌ Incorreta
O gerenciamento de atualizações de endpoints não é responsabilidade do frontend. O Service Discovery cuida de registrar e remover instâncias de serviços, e o Gateway API utiliza essas informações para rotear as requisições, evitando que o frontend tenha que lidar com mudanças de endereços.
PEGA ESSA DICA!
Lembre-se: Gateway API = *ponto único de entrada; Service Discovery = **localização dinâmica***. Juntos, eles isolam o frontend da complexidade da malha de microsserviços. Uma boa forma de fixar: o frontend só conhece o gateway, nunca os serviços individuais.