Push vs Poll quand un retard important (heures) est acceptable

De nos jours, il semble logique que l'interrogation soit une mauvaise pratique et pousser est la voie à suivre lors du développement d'applications mobiles qui nécessitent de recevoir constamment des données d'un serveur distant.

Tous les principaux magasins mobiles proposent leur version d'un service de notification push:

• Service de notification push d'Apple
• Google Cloud Messaging pour Android
• Service de notification push Microsoft

Cependant, je me demande dans quelle mesure cette hypothèse est valable. Je veux dire, si j'ai une application qui interroge un serveur distant seulement quelques fois par jour, et à laquelle les "notifications" n'ont pas besoin d'être envoyées instantanément (un délai important est acceptable), alors ce serait une bonne décision interroger les données au lieu de les pousser?

Merci d'avance!

L'interrogation est toujours acceptable lorsque le temps réel n'est pas une nécessité. Ce que vous devez vous demander, c'est pourquoi utiliseriez-vous l'un au lieu de l'autre?

Le but d'un service push est un couple de choses; il peut y avoir beaucoup moins de trafic pour vous si vos poussées sont des émissions et un fournisseur tiers fait la diffusion - cela vous permet d'envoyer un message et d'en recevoir des milliers. Mais comme vous le constatez, le plus grand avantage d'un service push est la nature en temps réel qui permet des mises à jour immédiates pour atteindre vos consommateurs. Cependant, lorsque vous effectuez des push, vous ne voulez vraiment jamais pousser de gros ensembles de données si vous diffusez, et vous êtes également à la merci du service push tiers que vous utilisez (si vous en utilisez un).

Le but d'un sondage est de vérifier périodiquement les différences de données, où la période de mise à jour peut avoir un SLA acceptable d'inexactitude jusqu'à une certaine période. Un sondage demandera à tous vos clients de demander périodiquement les données, ce qui signifiera une connexion demandée pour chaque client en cours d'exécution et la nécessité d'un service en direct capable de surveiller ces données avec précision pour les servir aux sondeurs. Avoir des données précises à servir signifie une certaine persistance des données qui prendra du temps sur le disque et la maintenance.

Donc, à partir de cela, nous pouvons voir que si vous avez des préoccupations concernant le trafic réseau ou la maintenance d'un service (ce qui signifie éventuellement authentifier / autoriser les demandes, les enregistrer, ce qui prend de l'espace disque, toutes les exigences normales de maintenance d'un service), alors vous ne le faites pas '' Je ne veux pas forcer les clients à voter. Cependant, si le cas d'utilisation nécessite la transmission d'un ensemble de données particulièrement volumineux ou si vous ne pouvez pas être connecté à une API tierce qui peut changer dans le temps ainsi que leur SLA ou leurs frais, un système de sondage local peut être applicable, bien que la maintenance les frais généraux peuvent être considérablement plus élevés. Alternativement, vous exécutez peut-être déjà le service et les données persistent, de sorte que l'interrogation est un ajout léger à l'infrastructure déjà en place, ce qui rend l'interrogation plus souhaitable.

Mais au point central que vous faites, vous avez raison; si le temps réel est nécessaire , l'interrogation ne fonctionnera pas. Dans le cas contraire, il vous suffit de faire le calcul sur la façon périodique les données peuvent être vérifiées multiplié par votre base de clients multiplié par la taille de votre ensemble de données pour déterminer si le coût du réseau va être la peine, ou si un service push serait mieux où vous pouvez toujours simplement pousser un événement de changement qui leur permet de demander le grand ensemble de données dans une étape secondaire (bien que l'atomicité de ces étapes puisse être quelque chose dont vous devez faire attention en fonction de la criticité des données).

Le vote devrait être bien dans votre cas. Et vous n'aurez pas à vous intégrer à un autre système (ou à plusieurs systèmes pour plusieurs plates-formes).

Les spécificités de l'appareil peuvent cependant être un problème. Pouvez-vous interroger de manière fiable lorsque l'application n'est pas centrée sur l'appareil? (peut ou peut ne pas être un problème pour vous). Votre capacité à le faire peut dépendre de la technologie que vous utilisez pour développer l'application.

Bien sûr. C'est aussi plus facile (méfiez-vous des pointes de traction si tout le monde tire sur le même horaire).

Cela dit, je contesterais l'hypothèse selon laquelle «un délai important est acceptable», compte tenu des attentes des utilisateurs mobiles. ('Les cartes ne sont pas mises à jour en temps réel! Inacceptable!' - ou - 'Je sais que c'est le service météo, mais je vais continuer à appuyer sur ce bouton de rafraîchissement toutes les cinq secondes jusqu'à ce que les prévisions pour demain deviennent ensoleillées!')