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

Optionally persisting topology (queues, topics and subscriptions) #266

Open
glenjamin opened this issue Jun 21, 2023 · 3 comments
Open

Optionally persisting topology (queues, topics and subscriptions) #266

glenjamin opened this issue Jun 21, 2023 · 3 comments

Comments

@glenjamin
Copy link

Hello!

We current have a setup where we run a copy of our stack in a VM for dev purposes, where a number of our apps communicate via SNS and/or SQS.

In production, we configure our queue and subscription topology via terraform, and configure the IAM so that our applications are only able to send or receive messages.

In dev we run the same terraform against the fake endpoints to sort out queues and subscriptions - but as there's no persitence this gets lost every time we reboot.

Would you be open to a PR which enables a config option for saving SQS and SNS topology into a file whenever it changes, and reloading them on app startup?

I've had a look at the structure of the app, and I think this is quite doable, but would likely require moving the []Messages collection into a separate map - that would give me an easy way to only save when topology changes and to exclude the messages themselves

@Admiral-Piett
Copy link
Owner

@glenjamin Hm, interesting idea. Have you had any luck with just making your changes in a config file and pointing your goaws instance at that? If not, what's missing from that, that you need to see other than you having to make it yourself? That's really the only persistance we have immediately handy.

Though, I could see value in a sort of - "export my state" command into a config file, I'd want to chew on that a bit.

Let me know about the config option. Thanks for thinking it through though!

@glenjamin
Copy link
Author

The main thing I'm hoping to avoid is having to repeat our topology config in multiple places, as that runs the risk of it going out of sync

@Admiral-Piett
Copy link
Owner

Hm, interesting. The only way we currently have to persist a particular setup is through a config file - which I what I would recommend to you in the meantime, event though, you would have to maintain both things you're right. I can see that exporting a current config as being beneficial, though I'll have to think through a design for it. We can leave it here for now.

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