Set default message name if no one is found.

[wysow]

Simple solution to fix #57

[danizord]

This way all unnamed messages would be routed to the same handler, not sure if this is a good approach. 🤔 Can't you configure SNS to set a message name before pushing it to the queue?

I've been thinking about separating the routing mechanism into a separate middleware, so that you can pipe middlewares in between that handles these edge cases:

// Validates worker request and extracts message attributes
$pipeline->pipe(WorkerMiddleware::class); 

// Here you can optionally pipe additional middlewares in between, for instance:
$pipeline->pipe(IdentifyAwsInternalEventsMiddleware::class);

// Routes to a specific handler based on message name
$pipeline->pipe(MessageRouterMiddleware::class);

Also it allows you to use a different routing mechanism, such as https://github.com/prooph/service-bus for example.

What do you think @bakura10 @wysow?

[bakura10]

I agree that having an additional middleware to process the request and set a name dynamically would be a better approach to me.

[wysow]

@danizord sounds really good for me, will update my PR in this way ASAP.

[wysow]

@danizord by the way our use case is S3 CreateObject event => SQS so here the process is totally automatic and nothing can be added to the message, so here the solution is that the new middleware will extract the message name from the body of the event.

[wysow]

@danizord @bakura10 here is a first try to handle S3 events, what do you think about it? We already use it and are satisfied about it right now.

Now we need to find an exhaustive list of all AWS internal events that can be send to a SQS queue and what are their contents...

[bakura10]

Hi,

No no sorry, I think there was a misunderstanding here and I think you misunderstood @danizord idea. I think what he suggested is that you handle that at your own level, in your application code, not in ZfrEbWorker. I'd definitely like to keep ZfrEbWorker agnostic of all possibly AWS events.

What it what you had in mind @danizord ?

[wysow]

@bakura10 @danizord As ZfrEbWorker stands for ZFR Elastic Beanstalk Worker it sounds legit to embed all AWS internal events here as Elastic Beanstalk is one of the AWS services, don't you think?

[danizord]

@wysow It's not optimal maintaining an IdentifyAwsInternalEventsMiddleware that covers every AWS service with their different data structures. I think it's easier for library consumers to implement custom middlewares as needed :)

59 adds that flexibility to pick only the pieces you need and replace or add custom stuff to the pipeline :)

[wysow]

Sure #59 is a better approach so closing this.