Je n'ai absolument rien contre RabbitMQ et je pense qu'il y a des architectures où il est pertinent.
Mais je suis plutôt partisan des approches 'lean' où on évite des usines à gaz pour 2-3 fonctionnalités qui nous intéressent. Il est parfois plus rapide de coder une fonctionnalité que d'apprendre à utiliser (et maintenir, et déployer, etc) des outils complexes. Je ne suis pas non plus partisan de l'approche inverse que consiste à tout coder tout seul.
tu ne fais que du requête/réponse
Non, c'est juste le cas pour gRPC, pas pour BERT ou du protobuf sur TCP (voire UDP), par exemple
Grâce au mécanisme de supervision des processus, le module Registry ci-dessus gère parfaitement la connexion/reconnexion d'un client. Est-ce cela dont tu parles ?
que c'est celui qui envoi le message qui doit gérer la stratégie de rejeu d'un message
Oui, sauf que mettre en œuvre une stratégie à base de timeouts, de retries, voire de files d'attentes différentiées se fait en quelques dizaines de lignes de code, à comparer à la configuration d'un outil comme RabbitMQ (+ configuration du code client).
que tu ne peut pas lisser ta charge en empilant des messages dans une fille ou si tu le fait c'est plus fragile parce que la file est géré par le destinataire et pas commune à plusieurs instances du destinataire
Je n'ai rien contre RabbitMQ (écrit en erlang en plus :D ) mais j'ai vu plusieurs cas où son utilisation n'était pas justifiée et créait un overhead énorme, pas seulement en terme de latence mais surtout en terme d'intégration et de maintenance.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Comparatif avec d'autres langages orientés "actor model"
Posté par Jean Parpaillon . En réponse à la dépêche Sortie d’Erlang/OTP 24. Évalué à 1.
Je n'ai absolument rien contre RabbitMQ et je pense qu'il y a des architectures où il est pertinent.
Mais je suis plutôt partisan des approches 'lean' où on évite des usines à gaz pour 2-3 fonctionnalités qui nous intéressent. Il est parfois plus rapide de coder une fonctionnalité que d'apprendre à utiliser (et maintenir, et déployer, etc) des outils complexes. Je ne suis pas non plus partisan de l'approche inverse que consiste à tout coder tout seul.
Non, c'est juste le cas pour gRPC, pas pour BERT ou du protobuf sur TCP (voire UDP), par exemple
Voir le module elixir Registry.
Grâce au mécanisme de supervision des processus, le module
Registryci-dessus gère parfaitement la connexion/reconnexion d'un client. Est-ce cela dont tu parles ?Oui, sauf que mettre en œuvre une stratégie à base de timeouts, de retries, voire de files d'attentes différentiées se fait en quelques dizaines de lignes de code, à comparer à la configuration d'un outil comme RabbitMQ (+ configuration du code client).
Voir GenStage
GenStage gère très bien le back pressure.
Je n'ai rien contre RabbitMQ (écrit en erlang en plus :D ) mais j'ai vu plusieurs cas où son utilisation n'était pas justifiée et créait un overhead énorme, pas seulement en terme de latence mais surtout en terme d'intégration et de maintenance.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier