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

OSS RMQ Docs: Document/Separate the common path V's the less common paths #1691

Open
pstack2021 opened this issue Jul 21, 2023 · 2 comments
Open

Comments

@pstack2021
Copy link
Contributor

Is your feature request related to a problem? Please describe.

A customer wanting to install/use RMQ as a message broken may take different paths:

Common Path:
Install RMQ - > access management UI (declare queues, publish and consume messages, add a bindings, etc), -> basic CLI commands -> perf-test -> go the tutorials (document the steps of the common path )

OR

Less Common Paths:
What are they? What are the most popular ones we have come across so far or we know of and need to be documented, lets include these paths in documentation and point to the different documentation topics user needs to access to walk these paths.

Describe the solution you'd like

As an initial solution for this, we could do something along the lines of the following on the page of OSS RMQ docs:

If you just want to install OSS RMQ, experiment with it on your workstation, go here, then do X, then do Y.

However if the above is not what you want, refer to the following paths which may suit your needs better:

  • Use Case 1
  • Use Case 2
    ....

(we could put these use case paths in a table

Describe alternatives you've considered

No response

Additional context

No response

@mkuratczyk
Copy link
Contributor

I think another path is this:

  1. a developer with no RabbitMQ experience joins a team/company where RabbitMQ is used
  2. there's already an app that uses RabbitMQ, therefore the they start from the very end of the workflow you mentioned - they have an app, they want to set up a RabbitMQ instance and run the app against it

I'd imagine in this case the flow is somewhat reverted:

  1. they start RMQ the same
  2. but then they may need to immediately go into debugging connectivity (authentication? TLS?)
  3. only once the app is running (connected), they may want to start exploring RabbitMQ itself (Management UI, what are those exchange and bindings, etc)

@pstack2021
Copy link
Contributor Author

Thanks @mkuratczyk for your feedback.

@HowardTwine @DigitalBlasco @edbyford @michaelklishin @MirahImage please add any additional thoughts here please, I will then organise a meeting to discuss further when I return from PTO on the week of August the 14th, thanks.

If I have left anyone out here that needs to provide feedback, please cc' them, thanks.

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

2 participants