Tecnologias e compatibilidade

Escolher para um problema definido

Stack é o conjunto de tecnologias usado para construir e executar um sistema. Na Oficina Caracol, JavaScript atende dois ambientes: navegador, que apresenta a interface, e Node, que executa servidor, leitura de arquivos e testes. A mesma linguagem não torna os ambientes iguais. O navegador não oferece automaticamente o acesso a arquivos e processos que o Node disponibiliza.

Compatibilidade é a capacidade das partes trabalharem juntas nas condições previstas: sintaxe aceita pelo runtime, APIs disponíveis, formato de dados compartilhado e comportamento nos navegadores escolhidos. Runtime é o programa que executa o código. Antes de discutir ferramentas adicionais, precisamos demonstrar que o caminho mínimo atende os requisitos.

Uma biblioteca pronta pode reduzir trabalho em outro projeto. Aqui, a decisão é usar somente APIs padrão para manter o percurso visível e não introduzir dependências externas. Essa restrição é pedagógica e contextual; não demonstra que bibliotecas são inadequadas em geral. A escolha deve ser revista se requisitos futuros ultrapassarem o que conseguimos manter de modo responsável.

Decisão arquitetural preenchida

ADR é um registro de decisão arquitetural: documenta contexto, escolha, alternativas e consequências. S08 descreve esse tipo de registro. O documento abaixo registra a arquitetura definida para o pacote; a aceitação de resultados de execução continua dependente das provas.

Não escrevemos que B é mais rápida ou segura em termos absolutos. Esses comparativos exigiriam critérios e medições. A justificativa é sua adequação à aprendizagem e às capacidades definidas. Se um participante escolher outra solução como extensão, precisará demonstrar os mesmos requisitos e explicar os novos custos.

Prova pequena de compatibilidade

Uma prova técnica curta deve atacar uma incerteza antes de comprometer toda a solução. Para o pacote, o percurso relevante é iniciar o servidor Node, abrir a página no navegador, obter os casos públicos e apresentar estados explícitos. A prova não exige implementar um produto inteiro; exige um resultado que permita aceitar ou revisar a decisão.

Diretório: pratica
Identificar runtime: node --version
Verificar o pacote: npm test
Executar validação: npm run validate
Iniciar percurso integrado: npm start
Endereço local: http://127.0.0.1:3000
Registrar: versão real, navegador, resultado e limites

O número da versão deve vir do ambiente executado, sem copiar uma versão presumida do livro. O teste do Node não substitui a inspeção no navegador: as APIs e as fronteiras são distintas. A prova precisa registrar falhas e diferenças, inclusive uma API não disponível ou um comportamento de interface inadequado.

Procedimento e erros

• Liste requisitos e restrições antes de escolher nomes de ferramentas.
• Compare alternativas com o mesmo critério e registre as consequências.
• Verifique a incerteza mais importante com uma prova pequena e identificável.
• Registre o ambiente realmente testado e a condição de revisão da escolha.

Exercício resolvido e gate

Dados: a interface abre corretamente, mas o servidor não inicia no runtime de um colega. Ele propõe adicionar uma biblioteca de interface. Qual investigação corresponde ao problema?

Leitura relacionada

Consultar S18, guia de JavaScript, e S19, documentação de módulos, HTTP, sistema de arquivos e test runner do Node. A disponibilidade de cada API deve ser conferida na documentação da versão realmente adotada.