Implementação do CLI

[viniagostini]

O CLI deve ser uma aplicação que permite processar um conjunto de planilhas para um mês específico localmente obtendo os mesmo resultados da execução automática.

Para funcionar o CLI precisa das seguintes variáveis de ambiente: SENDGRID_API_KEY, PCLOUD_USERNAME, PCLOUD_PASSWORD é de sua responsabilidade capturá-las e instanciar seus respectivos clientes que serão passados para o processor executar o trabalho.

Além disso, o CLI recebe como parâmetro em sua chamada alguns argumentos, são eles: mês, ano e caminho para o diretório onde estão as planilhas

[danielfireman]

Também acho que será importante receber a URL para o parser.

Além do diretório onde estão as planilhas, também é importante receber a URL do index.html que se deseja realizar o crawling. Claro que essas flags são mutuamente excludentes.

[viniagostini]

Uma preocupação que eu tenho é em como passar as planilhas contidas em um diretório para o processor. Pensei aqui agora e uma alternativa talvez seja adicionar ao processor um parâmetro que seja uma interface que possui uma função GetSpreadsheets, essa recebe um path retorna um slice com conteúdos e os nomes dos arquivos. Assim, o CLI passa para o processor um cara que busca as planilhas no diretório passado como parâmetro e o Worker continua passando o crawler, precisando assim apenas mudar a assinatura da função Download. O que acha @danielfireman?

[viniagostini]

Também acho que será importante receber a URL para o parser.

Concordo.

Aí caso o CLI receba uma URL, ele passa o crawler mesmo :)

[danielfireman]

Uma preocupação que eu tenho é em como passar as planilhas contidas em um diretório para o processor. Pensei aqui agora e uma alternativa talvez seja adicionar ao processor um parâmetro que seja uma interface que possui uma função GetSpreadsheets, essa recebe um path retorna um slice com conteúdos e os nomes dos arquivos. Assim, o CLI passa para o processor um cara que busca as planilhas no diretório passado como parâmetro e o Worker continua passando o crawler, precisando assim apenas mudar a assinatura da função Download. O que acha @danielfireman?

Essa função é quase mesma coisa que o crawler, certo? Assim, o que você está efetivamente propondo é passar o crawler como função para o processor (ou até mesmo remover ele e passar o slice com conteúdo das spreadsheets + nomes). É uma solução que pode funcionar sim, porém tenho outra ideia.

Como já conversamos por alto, acho que o ideal é o processor receber a URL do index.html, a url do parser e os demais clientes. Daí a sua pergunta deve ser, como fazer para o processor receber um index local?

Criar uma função que só existe na CLI (lembrando que a CLI é o lugar de colocar as coisas locais) que recebe esse diretório das planilhas (que também é um parâmetro que só existe na CLI, não existe no worker) e cria um index temporário baseado nele. Daí esse index é passado para o processor e o crawler pode realizar uma checagem simples: se for local, ler o arquivo; se for remoto baixar o arquivo (Se não quiser Go suporta isso de forma bem elegante, com Transports, RegisterProtocol e FileTransports.

O que acha?

[viniagostini]

Eu acho que essa abordagem resolve o problema também, mas que adiciona mais complexidade.

Pensando no fluxo de trabalho, sempre que fôssemos utilizar o CLI, antes precisaríamos gerar um arquivo index.html se a coisa for local. Conversamos sobre uma ferramenta que faz isso de forma automática, mas ainda assim, isso adiciona o trabalho de implementar a ferramenta e um passo a mais no workflow para rodar o CLI.
Isso seria seria compreensível se fosse em troca de manter o crawler mais próximo do seu estado atual ou até torná-lo mais simples. No entanto, essa abordagem adiciona ao mesmo uma complexidade a mais, que é decidir se os links para os arquivos são locais ou remotos e tratar isso.

Talvez eu não esteja enxergando os benefícios dessa abordagem, mas a outra me parece mais simples, tanto de usar quanto de implementar.

[danielfireman]

Acho que a que você sugeriu parece mais simples sim, porém adiciona complexidade no crawler, worker e processor. Ela espalha complexidade por várias partes do sistema,

Você vai ver que vai precisar escrever quase a mesma quantidade de código para esse novo método que getSpreadsheets do que para gerar o arquivo index intermediário (se você estiver usando esse critério para definir complexidade, acho que não será muito mais não). A diferença é onde essa complexidade fica. No caso que você está propondo será espalhada entre o crawler, worker e o processor, na minha proposta ficará toda no processor.

Digo que ficará espalada no processor, worker e crawler, pois o worker também precisará de uma instância dessa função para utiliazar o processor. Esse acoplamento me cheira mal.

[danielfireman]

Em resumo: você está achando que vai precisar programar muito menos, porém isso não vai acontecer.

Por outro lado, seguindo o caminho que você sugeriu, você vai precisar lidar com interfaces e espalhar lógica por mais lugares, o que é me parece mais difícil e feio.

[viniagostini]

Talvez eu tenha me expressado mal na hora de falar sobre a ideia, mas na minha cabeça, as modificações seriam as seguintes:

crawler: Passa a receber uma url em vez de mês e ano. Além disso passa a retornar o slice de conteúdo de arquivos + nomes. Mas essas já eram mudanças que teríamos que fazer de qualquer maneira.
worker: Gera a url usando o mês e o ano, instancia o crawler e passa para ambos para o processor, que é de fato quem fará a chamada para o crawler passando a url. CLI: Caso uma url seja passada, apenas instancia o crawler e passa como parâmetro ele e a url para o processor. Caso seja um path local, instancia um cara que varre esse o diretório pegando o nome e conteúdo dos arquivos, passa esse path e o cara que varre os arquivos para o processor que por sua vez vai invocá-lo. processor: passa a receber como parâmetro uma url e uma interface/função, substitui a chamada para o crawler por uma chamada para essa função passando a url recebida.

Eu vejo o crawler mais simples, porque ele agora só precisa receber uma url e capturar os arquivos daquela url. É um trabalho natural do worker gerar as urls, uma vez que é ele que itera sobre os meses. O CLI ganha de graça a url e o path e é trivial definir quem é que ele vai instanciar para passar para o worker. O processor perde completamente seu acoplamento com o crawler, o que o torna muito mais simples de reusar e robusto (e.g. se a gente quiser passar a fazer o parsing de outras páginas que contém planilhas, ou se a página do CNJ mudar e precisarmos implementar outro crawler)

Maaaaas ainda me falta muita experiência em Go pra dizer ao certo se essa abordagem é a mais bacana ou não. Estou indo por intuição aqui. Então se tu disser que a outra abordagem de fato é a mais adequada, eu confio e vamo simbora nela mesmo!

[viniagostini]

O CLI foi implementado com sucesso!