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

README: Add information about production readiness #7

Open
sadfun opened this issue Apr 11, 2024 · 2 comments · Fixed by #12
Open

README: Add information about production readiness #7

sadfun opened this issue Apr 11, 2024 · 2 comments · Fixed by #12
Assignees
Labels
documentation Improvements or additions to documentation help wanted Extra attention is needed

Comments

@sadfun
Copy link

sadfun commented Apr 11, 2024

While the library looks promising and well-written, it's still risky to use new libraries instead of battle-tested ones.

It would be good to understand exactly what experience the development team has of using this library internally, what results it produces, and how the developers themselves assess its readiness for production.

@sadfun sadfun changed the title README: Add information production readiness README: Add information about production readiness Apr 11, 2024
@m3talux m3talux added documentation Improvements or additions to documentation help wanted Extra attention is needed labels Apr 11, 2024
@m3talux m3talux pinned this issue Apr 11, 2024
@m3talux
Copy link
Collaborator

m3talux commented Apr 15, 2024

Here is a summary of how we tested the library internally before releasing it to the public:

  1. All of our microservices are tested via cucumber testing, using the following library: https://github.com/cucumber/godog
    a. We test that the setup is correct: Queues, bindings, and exchanges are up and ready
    b. We test that events are well received and consumed
    c. We test that events are emitted and present in the target queue
  2. For the keep-alive and fault-tolerant mechanisms, we use a technique called "Chaos testing":
    a. We drop the RabbitMQ server at random points in time
    b. We make sure microservices keep functioning normally
    c. We up the RabbitMQ server
    d. We make sure that the cache is emptied (events are sent/consumed) and that events are flowing normally
    e. Logs help a ton to trace any unwanted or unexpected error.

By following the 2 points for almost 3 years, we have continuously confirmed and re-confirmed that Gorabbit is as solid as we wanted it to be.

Now, to provide something similar to Gorabbit and offer a metric that users can trust, I suggest a very similar approach:

  1. Cucumber tests that will cover the client's functionalities: Publishing/Consuming and the manager's functionalities: set up.
  2. Chaos testing for the keep-alive mechanisms: A container-based approach that would instantiate one or many publishers/consumers and a single RabbitMQ server that would shut down at random times. We can then define a list of events we expect to be sent and evaluate that the same list is well received.

@m3talux
Copy link
Collaborator

m3talux commented May 8, 2024

Small update on the issue, I'm working on a test file for the Manager. It was recommended by someone on Reddit to use testcontainer-go for managing a docker container for a RabbitMQ server. The work is ongoing on my branch. I'll create a PR as soon as I am done covering all of the manager.

Branch: https://github.com/m3talux/gorabbit/tree/manager-unit-tests

@m3talux m3talux self-assigned this May 9, 2024
@m3talux m3talux linked a pull request May 9, 2024 that will close this issue
@m3talux m3talux reopened this May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants