Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Communication method #1

Open
brianUtn98 opened this issue May 30, 2024 · 5 comments
Open

Communication method #1

brianUtn98 opened this issue May 30, 2024 · 5 comments

Comments

@brianUtn98
Copy link

What is the chosen method to communicate all components present in the ecosystem? I would use a Message broker, like RabbitMQ or something alike.

@solanoepalacio
Copy link
Collaborator

Hmmm, I wouldn't say "all components", I can foresee that we'll need more than one transport. I can definitely think of scenarios where we can benefit of the easy error handling provided by synchronous communication methods such as http and grpc, and on the other hand I can also think of places we'll need queuing and event mechanisms

@solanoepalacio
Copy link
Collaborator

solanoepalacio commented May 30, 2024

As for what to use as the underlying messaging technology, this posses a whole another question...

@solanoepalacio
Copy link
Collaborator

On one side I think: if we want to have Kamaji become part of the open source tools facilitating the usage of wormhole protocol, then we'd need to choose an open source technology for the messaging layer. Otherwise, I'd recommend to just get started using SQS since it's what we already have setup and it's really easy for us to work with...

@solanoepalacio
Copy link
Collaborator

If we were to go with the open source technology path... You've got a kafka fan in front of you :)

@brianUtn98
Copy link
Author

When I was using RabbitMQ in the past, I was able to see a couple of benefits of using kafka instead... but was too late.

I don't really mind the brand we could use, you are right is best to use a open source one. Is just that I see benefits on using a message broker like Rabbit, Kafka or any queue oriented messaging service, because of the asynchronous handling of messages with those tools. It also decouple components from each other. As you said, using that kind of infrastructure makes error handling difficult while using grpc or http is pretty straight forward. A lot of things to think about :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants