Subscription vs Polling

[lucasconstantino]

On the e-mail you sent us, you mentioned you spent some time studying subscription as a possible solution for #3. Honestly, that would be an outstanding path - though perhaps way too complex for such small benefit on the application. Your solution went on with a polling technique, provided by the Apollo already. Could you elaborate on the benefits of a subscription approach over polling, and what drawbacks there might be with it?

[AlyoshaS]

Pooling forces the refresh on a specified interval. Subscriptions listen to the mutations and only refresh when they happen on the server. It seems better to me having something that only changes when certain event happens than requests in the event loop every 0.5s even if you don't have new events. And in the docs, they suggest subscriptions for chat applications.
Also thinking about other tasks (replies, mentions, logout...), having subscriptions would be a good choice.

@lucasconstantino

[lucasconstantino]

These are all good points. But let's get out of the "chat application" context for a moment. Do you see any situations where polling would actually be a better choice than subscriptions?

[AlyoshaS]

Ok, português porque fiquei bem confusa agora. De todas as situações que me vieram na cabeça, ex. um carrinho de compras, uma aplicação de provas online, um Airbnb... enfim, na maioria faz mais sentido ter algo escutando o evento específico. Única coisa que consegui pensar seria uma aplicação que mostre algum dado em um determinado tempo: exemplo uma aplicação de cotação da bolsa de valores ou de criptomoedas e que seja especificado que a atualização daquele gráfico se dá em determinado período de tempo. Exemplo se minha aplicação tiver um plano gratuito que informa as atualizações a cada 5 minutos e o plano pago informar em tempo real, talvez? @lucasconstantino

[lucasconstantino]

@AlyoshaS minha intenção aqui era ver se você colocaria na problemática não só o benefício ao usuário final, mas ao sistema em si: dependendo da quantidade de usuários, modelos baseados em subscription são excessivamente pesados para o servidor. Polling junto de cacheamento de recurso e invalidação de cache pode conseguir tirar todo o peso de processamento da aplicação e mover esse peso para uma CDN, por exemplo!

Fica a sugestão: sempre leve em consideração custo x benefício de cada funcionalidade levando em consideração todos os pontos de interação possíveis.

Um exemplo interessante que já vivenciei era um sistema em que havia uma interface que apenas uma pequena parcela de usuários teria contato. Era algo bastante administrativo, nesse caso. No começo do projeto, porém, tínhamos uma preocupação bastante grande com compatibilidade desse sistema em diversos browsers, visto que haviam também usuários finais. Depois de algum tempo, percebemos que fazia muito mais ignorar problemas de compatibilidade (ou mesmo performance) na parte administrativa, pois sairia simplesmente mais barato garantir a máquina física em que esses usuários teriam acesso (um bom tablet, por exemplo) do que gastar preciosas e custosas horas de desenvolvimento :)

[AlyoshaS]

@lucasconstantino, o que eu havia entendido era que Subscriptions seria uma solução melhor levando em consideração o que eu falei na primeira resposta. Eu realmente não consegui abordar pelo seu ponto de vista e acho que isso se dá justamente pelo fato de eu não ter estudado tanto back-end ou até mesmo a falta de experiência. De qualquer forma, vou voltar na documentação e estudar novamente e, principalmente, essa a parte de cacheamento de recurso.
Vou levar como regra sua sugestão daqui pra frente e muito obrigada pela explicação detalhada, ficou bem fácil de entender o ponto que você queria que eu analisasse.