Performance NGINX comprometida por falsa responsabilidade

[ppKrauss]

Exemplo: BR-SP-SaoPaulo~CD existe e é resolvido pelo endpoint depois de ser validado pelo NGINX, nas BR-SP-SaoPaulo~CE nem sequer foi resolvido, o próprio NGINX descartou: sem maiores explicações, o usuário nem sabe que foi erro de sintaxe.

O retorno de código de erro, sempre que possível, deve ser delegado ao resolvedor de nomes, apenas o "alto nível do endpoint" fica a cargo do NGINX. Com isso, além de ser mais correto para a mensagem de erro, reduzimos a carga de CPU (por complexidade de regex) no NGINX... Portanto a "falsa responsabilidade" será considerado bug.

Três níveis de análise sintática

Analisando src/config.nginx temos:

1. location: faz apenas o roteamento, delega a responsabilidade dos prefixos.
   Exemplo errado location ~* "^/(urn|geo):lex:([a-z]{2}(;[a-z\.]+)?(;[a-z\.]+)?)\.json(/cover/base16h(1c)?)?$"
   Exemplo certo location ~* "^/(?:urn|geo):lex:[^/]+\.json(?:/cover/base16h(1c)?)?$"
2. rewrite: implementa apenas a sintaxe necessária e suficiente para a chamada de função.
3. função: convencionamos que funções de resolução, api.f(), demandam balanço entre a resolução genérica (com CASE para demais funções) e especializada. Novamente, o ideal é não sobrecarregar nem a performance nem a manutenção do NGINX.
   Em casos de funções muito simples e com demanda por alta performance, todavia, pode ser útil "reusar a CPU já gasta pelo NGINX processar a regex", mas são casos raros a serem devidamente justificados através de benchmark da performance.
   PS: O usual em syntatic parsing é essa segmentação passo a passo, daquilo que é 100% certo segmentar.

Sugestão de correção

Casos mais graves:

• location ~* "^/geo:osmcodes:([A-Z]{2})~([0123456789BCDFGHJKLMNPQRSTUVWXYZ]+)(,[0123456789BCDFGHJKLMNPQRSTUVWXYZ]+){0,}\.json$" para simples location ~* "(?i)^/geo:osmcodes:.+\.json$", e respectivo rewrite "(?i)^/geo:osmcodes:([A-Z]{2})~(.+)\.json$"... Testar diversos casos porque o \.+ pode não se comportar conforme esperado.
• ... cuidado, se (?i) é ignore-case, não adianta nada no rewrite sem usar ~* antes no location.

---

Dá issue osm-codes/BR#11:

Levar as issues específicas para cada país, por exemplo osm-codes/gridMap-draftPages#82 é exclusiva do Brasil.. Mas antes precisamos de NGINX enxuto como diretiva geral, e algum script de verificação de não-conflito. Ideal os scripts NGINX serem gerados por template Mustache e então o mesmo JSON que alimenta o Mustache-NGINX alimenta também um python de teste.

Dá issue #50:

Definir regrexes em CSV ou JSON. As regexes podem ser de dois tipos: genérica-global (no WS), e específica por sobrescrita (no país).

Cada país precisa do eu próprio gerador de NGINX a partir de CSV ou JSON (local!) que alimentará Mustaches.

Em outra issue já comentamos também que o ideal é cada país ter seu make_conf.yaml para configuração do AFAcodes da jurisdição (incluindo projeção etc.), independente de ter sido automatizada ou não, permite gerar a documentação automatizamente e oferecer maior transparência quanto à definição do AFAcode.