Donc, je souhaite demander quelque chose que je n'arrive pas à comprendre. Par exemple, j'ai une application qui doit suivre l'emplacement d'APPLICATION_1 et l'emplacement est mis à jour dans la base de données Firebase RealTime, qui est ensuite consommée par mon serveur. Maintenant, je souhaite montrer cette localisation continue sur DEUX autres applications. En faisant un peu de recherche, j'ai appris l'existence de la mise en œuvre des sockets, mais considérez que j'ai 200 utilisateurs qui utilisent APPLICATION_1, et qui fournissent continuellement des données à la base de données Firebase et qui sont ensuite fournies à 400 utilisateurs finaux via le serveur, ce qui signifie maintenir ou garder 400 sockets ouverts dans ce but. Cela semble être une très mauvaise option pour mon serveur car il sera retardé et pourrait finir par ne plus répondre. Cependant, si j'utilise une autre API récursive Callback qui demande au serveur l'emplacement en temps réel de 200 utilisateurs d'APPLICATION_1, c'est également une solution horrible. Je suis un peu bloqué quant à l'approche à adopter pour mettre en œuvre une solution à ce problème spécifique. La limitation est que je n'ai qu'un seul serveur et 3 applications à alimenter en données, qui peuvent en outre être utilisées par de nombreux utilisateurs.
UPDATE
Après mûre réflexion, je suis arrivé aux conclusions suivantes :
-
Établir des connexions Kafka : Comme le fait Youtube ou d'autres sites de streaming de données, la plateforme doit mettre ses ressources en cache et les soumettre à un flux, comme le fait actuellement Kafka. Il serait donc nécessaire d'écrire un wrapper pour le flux Kafka à toutes les extrémités de la plateforme, comme le wrapper web, ainsi que les wrappers ios et Android. Cependant, ce que fait Youtube, c'est qu'il établit initialement une connexion un à un entre le client et le serveur, quelle que soit la distance, mais comme Youtube est une plateforme beaucoup plus GRANDE, s'il sent qu'il y a plus d'utilisateurs qui utilisent ce flux, il fait une copie du flux réel et le publie sur un serveur proche où les clients qui le reçoivent de cette localité sont déplacés. Nous ne pouvons pas faire cela car nous avons une fonctionnalité de serveur limitée.
-
Mettre en œuvre l'API Callbacks : La mise en œuvre de l'API Callbacks semblait initialement très récursive et une mauvaise mise en œuvre, mais par la suite, j'ai fait des recherches sur la plateforme de l'internet des objets et j'ai découvert que l'IOT met en œuvre un autre protocole d'appels API, MQTT qui est une solution beaucoup plus légère, durable et peu gourmande en ressources. Cependant, cette solution nécessite elle aussi des promesses (il faudra y revenir).
-
Obtenir directement le flux de base de données en temps réel de Firebase : Cependant, si 200 utilisateurs d'APPLICATION_1 mettent à jour la base de données Firebase RDB, le coût ne concerne que les 200 utilisateurs d'APPLICATION_1, tandis que si 200 utilisateurs d'APPLICATION_2 et 200 utilisateurs d'APPLICATION_3 récupèrent les données de la même base de données, le nombre total de nœuds passe à 600, ce qui peut s'avérer assez coûteux. L'évolutivité de Firebase est le problème ici.
-
Mise en œuvre des sockets : Les sockets sont gourmands en ports. Bien que leur connexion un à un soit transparente et la communication parfaite, ils ont tendance à devenir un problème lorsque le nombre de nœuds augmente considérablement. Par conséquent, si le serveur est utilisé pour une multitude de processus de traitement de données, ce n'est peut-être pas la solution idéale.
