Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cacheamento do service token #5

Open
mateusKoppe opened this issue Oct 24, 2020 · 4 comments
Open

Cacheamento do service token #5

mateusKoppe opened this issue Oct 24, 2020 · 4 comments

Comments

@mateusKoppe
Copy link
Member

mateusKoppe commented Oct 24, 2020

Sua solicitação de funcionalidade está relacionada a um problema? Por favor descreva.

Com as novas implementações já não é mais necessário registrar o service token manualmente, porém esse token está sendo buscado a cada requisição fazendo uma requisição http para buscar esse token, o irá pode aumentar o tempo de resposta dessa em todas as requisições.

Descreva a solução que você deseja

Alguma implementação de cache no service token para que essa requisição adicional por baixos dos panos seja desnecessária.

Descreva as alternativas que você considerou

Considerei o armazenamento desse token em um arquivo simples no mesma pasta da aplicação que estará listado no .gitignore, dessa forma não é necessária a configuração de um banco de dados apenas para o armazenamento desse token, a única preocupação que será adiciona com essa abordagem é ter certeza de que a aplicação possui permissão de escrita no servidor pelo menos na mesma pasta que ela está armazenada.
Para a atualização desse token eu considerei que quando uma autenticação falhar por conta do service token então a aplicação ira fazer uma requisição para tentar buscar um novo service token e fará mais uma tentativa de autenticação, caso dessa vez não exista um erro de token ele irá atualizar esse novo token no arquivo de cache.

Com essa abordagem a maioria das requisições feitas não terão o tempo de resposta adicional para que a aplicação busque esse token, somente uma autenticação será mais lenta que será a autenticação que falhar e que buscará um novo service token.
Uma vantagem dessa abordagem sobre o uso de uma rotina cron é que quando o o service token for alteração não será necessário esperar que essa rotina seja atividada, na mesma requisição que falhar já será recuperado o novo service token.
Nada impede que uma cron seja implementada de qualquer forma.

Qualquer outra possível abordagem é muito bem vinda.

@mateusKoppe
Copy link
Member Author

Para manter registro:
Essa discussão foi iniciada no Pull Request #3

@mateusKoppe
Copy link
Member Author

@Dovyski o que acha da ideia?

@Dovyski
Copy link
Member

Dovyski commented Oct 29, 2020

Eu gosto dessa abordagem, mas eu vejo alguns problemas. O principal deles é que não temos garantia de concorrência no acesso. Se pelo menos duas requisições forem processadas ao mesmo tempo (ou em milissegundos de diferença), teremos acesso simultâneo ao arquivo. Isso pode corromper as coisas.

De qualquer forma, acho que essa implementação é válida, contanto que seja desligada por padrão e ligada através de um parâmetro no construtor da classe.

@mateusKoppe
Copy link
Member Author

Concordo com a ideia de poder ligar e desligar isso com um parâmetro, acredito que já estamos aptos para começar a trabalhar nisso então =]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants