8000 [Messenger] ease usage when dealing with "external" messages · Issue #49094 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[Messenger] ease usage when dealing with "external" messages #49094

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.

Sign up for GitHub

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

Jump to bottom
Closed
nikophil opened this issue Jan 24, 2023 · 10 comments
Closed

[Messenger] ease usage when dealing with "external" messages #49094

nikophil opened this issue Jan 24, 2023 · 10 comments
Labels
Messenger Stalled

Comments

@nikophil
Copy link
Contributor
nikophil commented Jan 24, 2023 •
edited
Loading

Description

Hello,

this issue is a follow up of this PR, I'll try to give a little bit more context on what are the motivation behind this, and I would like to come to a consensus before starting the work 😅

Related to #49081, when it comes to deal with messages coming from another app, messenger has some drawbacks.

The main problem is to define per transport :

  • which format we want to deserialize messages from
  • a (de)serialization context
  • and also which serializer service should be used in \Symfony\Component\Messenger\Transport\Serialization\Serializer, this is quite useful when dealing with big messages that requires specific serialization.

The solution I prefer is the one @ro0NL proposed: add a new prototyped messenger.serializers and deprecate messenger.serializer

Prototype would be:

messenger:
    serializers:
        name:
            default: ~ # exactly one with default:true needed
            serializer: ~ # defaults to `@serializer`
            format: ~ # defaults to json
            context: {}

Afterwards, we need to link transports to our serializers. There is already a key messenger.transports.serializer which do not represent the same thing (we expect an implementation of \Symfony\Component\Messenger\Transport\Serialization\SerializerInterface here). Maybe we could add a transports key in the messenger.serializers prototype?

Another problem is that we don't have any way to differentiate "messenger serializer" that uses "symfony serializer" and which would need serialization context (ie: \Symfony\Component\Messenger\Transport\Serialization\Serializer) from "messenger serializer" which do not use Symfony's serializer (ie: \Symfony\Component\Messenger\Transport\Serialization\PhpSerializer). That's why I think we need a SymfonySerializerAwareInterface which extends \Symfony\Component\Messenger\Transport\Serialization\SerializerInterface.

At the end, my proposal would be:

messenger:
    serializers:
        name:
            messenger_serializer: ~ # any implementation of `\Symfony\Component\Messenger\Transport\Serialization\SerializerInterface`
            default: ~ # exactly one with "default: true" needed

            # the following would only be allowed if `messenger_serializer` implements a new interface "SymfonySerializerAwareInterface"
            symfony_serializer_service: ~ # defaults to `@serializer`
            format: ~ # defaults to json
            context: {}

We would then deprecate passing a service to messenger.transports.serializer and now require to pass one of the prototypes above. If nothing is provided under messenger.serializers, we would use \Symfony\Component\Messenger\Transport\Serialization\PhpSerializer

@weaverryan @chalasr @ro0NL I'd love to have your inputs on this <3
@nikophil nikophil mentioned this issue Feb 6, 2023
Open
@carsonbot
Copy link

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

@carsonbot
Copy link

Friendly reminder that this issue exists. If I don't hear anything I'll close this.

@nesl247
Copy link
nesl247 commented Aug 13, 2023

This has not been resolved.

@carsonbot carsonbot removed the Stalled label Aug 13, 2023
@carsonbot
Copy link

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

@nesl247
Copy link
nesl247 commented Feb 14, 2024

No it hasn't been.

@carsonbot carsonbot removed the Stalled label Feb 14, 2024
@carsonbot
Copy link

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

@nesl247
Copy link
nesl247 commented Aug 15, 2024

No it hasn't been.

@carsonbot carsonbot removed the Stalled label Aug 15, 2024
@carsonbot
Copy link

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

@carsonbot
Copy link

Hello? This issue is about to be closed if nobody replies.

@carsonbot
Copy link

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Messenger Stalled
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@nesl247 @nikophil @carsonbot
0