Push vs Poll quando grande atraso (horas) é aceitável

Hoje em dia parece um senso comum que a pesquisa é uma prática ruim e o caminho a percorrer é o desenvolvimento de aplicativos móveis que exigem o recebimento constante de dados de um servidor remoto.

Todas as principais lojas de móveis oferecem sua versão de um serviço de notificação por push:

• Serviço de notificação por push da Apple
• Google Cloud Messaging para Android
• Serviço de Notificação por Push da Microsoft

No entanto, estou me perguntando até que ponto essa suposição é válida. Quero dizer, se eu tiver um aplicativo que pesquisa um servidor remoto apenas algumas vezes por dia e para o qual "notificações" não precisam ser entregues instantaneamente (um grande atraso é aceitável), seria uma boa decisão pesquisar dados em vez de pressioná-lo?

Desde já, obrigado!

A pesquisa é sempre aceitável quando o tempo real não é uma necessidade. O que você deve se perguntar é: por que você usaria um em vez do outro?

O objetivo de um serviço de push é algumas coisas; pode haver um tráfego consideravelmente menor para você lidar se os seus pushs forem transmitidos e um provedor terceirizado fizer a transmissão - isso permite que você envie uma mensagem e receba milhares de pessoas. Mas, como você observa, o maior benefício de um serviço de push é a natureza em tempo real que permite atualizações imediatas para alcançar seus consumidores. No entanto, ao fazer pushs, você realmente nunca deseja enviar grandes conjuntos de dados se estiver transmitindo e também está à mercê do serviço de push de terceiros que você utiliza (se você utiliza um).

O objetivo de uma pesquisa é verificar diferenças de dados periodicamente, em que o período de atualização pode ter um SLA aceitável de imprecisão até um determinado período de tempo. Uma pesquisa exigirá que todos os seus clientes solicitem os dados periodicamente, o que significa que uma conexão está sendo solicitada para cada cliente em execução e a necessidade de um serviço ativo capaz de monitorar esses dados com precisão para atendê-los aos pesquisadores. Ter dados precisos para servir significa alguma persistência de dados que ocupará tempo de disco e manutenção.

Portanto, podemos ver que, se você tiver preocupações com o tráfego de rede ou a manutenção de um serviço (o que significa possíveis solicitações de autenticação / autorização, registrando-as que ocupam espaço em disco, todos os requisitos normais de manutenção de um serviço), você não não quero forçar os clientes a fazer pesquisas. No entanto, se o caso de uso exigir a transmissão de um conjunto de dados particularmente grande ou você não puder ser vinculado à API de terceiros, que pode mudar com o tempo, bem como com o SLA ou com as cobranças, um sistema de pesquisa interno pode ser aplicável, embora a manutenção sobrecarga pode ser significativamente maior. Como alternativa, você já pode estar executando o serviço e manter os dados persistentes, de modo que a pesquisa é uma adição leve à infraestrutura já existente, o que torna a pesquisa mais desejável.

Embora no ponto central você faça você estar correto; se for necessário em tempo real , a pesquisa não funcionará. Caso contrário, basta fazer as contas sobre o quão periódicos os dados podem ser verificados multiplicados pela sua base de clientes multiplicados pelo tamanho do conjunto de dados para decidir se o custo da rede valerá a pena ou se um serviço de push seria melhor onde você sempre pode enviar um evento de alteração que permita que eles solicitem o grande conjunto de dados em uma etapa secundária (embora a atomicidade dessas etapas possa ser algo que você precisa ter cuidado, dependendo da criticidade dos dados).

A votação deve ser boa no seu caso. E você não terá que se integrar a outro sistema (ou múltiplos sistemas para múltiplas plataformas).

Porém, as especificidades do dispositivo podem ser um problema. Você pode pesquisar de forma confiável quando o aplicativo não está na frente e no centro do dispositivo? (pode ou não ser um problema para você). Sua capacidade de fazer isso depende da tecnologia que você está usando para desenvolver o aplicativo.

Claro. Também é mais fácil (tome cuidado com os picos de puxar se todos estiverem puxando no mesmo horário).

Dito isso, eu contestaria a suposição de que 'um grande atraso é aceitável', considerando as expectativas dos usuários móveis. ('Os mapas não são atualizados em tempo real! Inaceitável!' - ou - 'Eu sei que é o serviço meteorológico, mas continuarei pressionando o botão de atualização a cada cinco segundos até que a previsão para amanhã fique ensolarada!')