-
Notifications
You must be signed in to change notification settings - Fork 2
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
Comments
Para manter registro: |
@Dovyski o que acha da ideia? |
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. |
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 =] |
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.
The text was updated successfully, but these errors were encountered: