aws
SNS / SQS Service Mapping Rethink
I'm aware that in the current copilot definition there is only one way to subscribe to events, ie through a worker service as described in #4635
This is a really uninspired use of the copilot interface with regard to AWS's only distributed service orchestration tool. Currently without rolling your own permission / config implementation many use cases involving subscribing to events in the load-balanced service or backend services are not permitted.
That means that there is currently is no way to have a process interact with the web and to receive signals via SQS / SNS topics. The current implementation covers may be 50% of use cases, but you're leaving alot on the table.
My suggestion would be to drop the worker service concept all together, and merge that with backend service. This allows you to create an event graph which allows for alot more interesting implementations than the one-way definition currently defined.
Please make this happen!
@SoundsSerious Thanks for the thoughtful post!
My suggestion would be to drop the worker service concept all together, and merge that with backend service.
I feel like more generally, this sounds like a design pattern where, we provide a service backbone (i.e. the backend service), and give users the options to add "plugin"s to that service. A Load-Balanced Web Service would be adding a "web" plugin on the backbone (under the hood it adds a few LB listener rules, security group rules, etc.). Similarly, a Worker Service would be adding a "subscribe" plugin.
This is an interesting idea that can be explored more. To be completely open frank, I agree with you that worker service probably could have been implemented as the ability to subscribe on top of a backend service.
Glad you agree! I think this would help take copilot to the next level with significant ability to orchestrate services together!
It seems like implementation was really related to the feature request so hats off to team copilot for making that happen :)
Thats sounds like a useful refactor! although I am far from an expert on AWS service orchestration
I think I'm unblocked for now since I can just modify permissions and write the features I need to but I do really want to see this framework takeoff!
Thanks!