Digitação dinâmica em toda a pilha de tecnologia - onde reforçar a validade dos dados?

Parece-me que você está prestes a criar uma plataforma interna para compensar a falta de semântica inerente à a língua que você escolheu.

Até mesmo definições de esquema (seja XML DTD ou esquema JSON ou esquema de mongoose ) não fornecerá a você a segurança da análise estática. Tudo o que você realmente pode usá-los é garantir que seu sistema não se depare silenciosamente com comportamento indefinido e acabe falhando.

Não sei ao certo por que você não usa um idioma, isso simplesmente fornece isso imediatamente. Usando uma linguagem tipada dinamicamente e embutindo restrições de tipo em que parece combinar o pior dos dois mundos. Ainda mais, porque as modernas linguagens estaticamente tipadas são capazes de inferir vastas partes dessas restrições implicitamente.

Pessoalmente, sugiro que você dê uma olhada em Haxe 's Backend JavaScript . Existe um site dedicado ao desenvolvimento de node.js com o Haxe - você pode começar por aí. Os tipos anônimos do Haxe podem ser usados rapidamente para vincular fontes JSON de maneira segura, sem qualquer sobrecarga de tempo de execução. Ainda assim, se você desejar, suas instalações de metaprogramação permitirão que você gere automaticamente código de validação a partir do momento da compilação.

Claro que o Haxe não é de longe a única opção disponível para direcionar JavaScript de maneira segura. Então, se você acha que precisa dos benefícios da tipagem estática, você deve investir tempo para encontrar uma linguagem de sua preferência, que realmente incorpore essas informações diretamente em sua semântica estaticamente analisável.

Deixe de lado a noção de tipos.

O ponto principal da digitação dinâmica, pelo menos em idiomas que acertam, é que você não precisa pensar em tipos na maioria das vezes. Verificações de tipo fazem sentido em uma linguagem pré-compilada, porque o compilador pode capturar muitos erros antes mesmo de tentar executar o código, mas quando o código é interpretado ou compilado pelo JIT, os benefícios das verificações de tipo estático são marginal e não pesam contra a flexibilidade adicional que a programação dinâmica tem a oferecer.

Em vez de validar tipos, valide os valores - isto é, se você quiser que algo seja numérico, execute uma verificação 'é numérica'. Se você quiser que algo tenha uma determinada propriedade, verifique se a propriedade existe. Se você quiser que algo esteja em um determinado intervalo, verifique se está de fato dentro do intervalo. Etc etc.

Existem duas filosofias: o mais tradicional check-before-you-go, ou seja, antes de dividir a por b , você garante que b seja diferente de zero; e a rota mais fácil de pedir perdão do que a permissão que o Python usa, ou seja, você apenas divide a por b e depois captura a exceção dividir por zero posteriormente.

Infelizmente, não há nenhuma maneira significativa de fazer isso de forma declarativa que eu saiba. Mas, a fronteira entre código e dados é muito mais desfocada na programação dinâmica - o código também é dado que você pode manipular e os dados podem assumir o papel de código. Uma parte do código javascript que valida um objeto JSON é apenas mais um pedaço de texto, e você pode tratá-lo como simples dados antigos; você pode até mesmo gerar esse texto em tempo de execução e depois executá-lo (embora você deva ser muito cuidadoso com isso, especialmente se usar dados de fontes não confiáveis no processo de geração de código).

No que diz respeito aos esquemas, verificar rigorosamente se um determinado objeto JSON corresponde a um esquema raramente é necessário. Em vez disso, basta verificar se as propriedades necessárias estão lá e se as invariantes de nível de valor são válidas. Se existirem propriedades extras, tudo bem - você simplesmente as ignora. Se algo estiver faltando, você pode resgatar ou substituir um valor padrão. E se algo tem o tipo errado, novamente, você pode liberar (encontrou uma string não numérica onde um número era esperado), ou você pode recuperar (substituir um valor padrão, arredondar, truncar, converter para booleano, etc.).

Outra coisa a considerar é que o XML é muito mais complexo do que o JSON - o XML possui namespaces, atributos, entidades e você precisa decidir como empacotar entre objetos em sua linguagem e representações XML. Em JSON, a escolha geralmente é óbvia - é escalar (int, float, string, booleano, nulo), uma lista simples (matriz) ou uma coleção de valor-chave (objeto).

Infelizmente, existem poucas linguagens (se houver) que obtêm tipos de conversão transparentes - Javascript, PHP, Python, todas elas exigem um tipo explícito de malabarismo ocasionalmente, portanto você não será capaz de alcançar a situação ideal ideal.

Bem, como sua pilha de programação não se importa com os tipos, por que você deveria.

A resposta é que seus usuários podem. Então, o que você quer fazer é impor quaisquer regras comerciais aplicáveis aos seus dados.

Isso pode ser feito por JavaScript nos formulários digitados, codificando a validação no código do servidor Node.js quando uma solicitação é recebida ou, até mesmo codificando as regras em xsd e obtendo o analisador para validar sua entrada xml.

O ponto é que você implementa a validação de regras de negócios e não a validação técnica. Ou seja, você deve verificar regras como "Um número de três dígitos entre 001 e 700", o que significa algo para o usuário final, em vez de "é este numérico". Portanto, se o usuário achar que "A noite anterior ao Natal" é uma data válida e seu aplicativo pode conviver com ela, é uma data válida.