[Messenger] Very naive serialization #33368
Comments
|
This issue looks like a duplicate of #31230
All this can be solved with a custom serializer which can be configured by yourself. We can make this easier. It's just a question how. See also #32049 |
|
@Tobion thanks for answering. I think each of those two problems can be solved independently. EDIT: actually #33369 is a duplicate of #31230 but not this one. |
|
As for #32049 it's a meta issue, it actually exposes 3 very different aspects of plugging the messenger in an heterogeneous environment. |
I think this is a critical feature that should be in core, as a transport developer I should not care about the serialization/deserialization process, for example, how does the AMQP transport handles the I agree this would cause problems with the |
|
@Nyholm, maybe I am wrong here, but you at happyr created something with serializing and versioning of messages IIRC. |
|
Correct. I created a custom serializer that decouples the application from the actual message. See https://github.com/Happyr/message-serializer I find @pounard idea of content negotiation interesting. Ie the serializer should look at the content type header and know what to do. However, that sounds awfully complex and would rarely ever be used. I mean, you are responsible of both the client and the server, so you always know what content-type you are using. I would recommend someone writing their own implementation of serializer. It does not have to be complex. See https://github.com/Happyr/message-serializer/blob/master/src/Serializer.php |
|
Thanks for your feedback 👍🏻 |
Thanks. I wouldn't call that negotiation thought, if the transport gives a content-type, there's nothing to negotiate about, it's a fact the serializer must handle, in my opinion.
It's not complex, I don't think so, transport gives a content type, you give it to the serializer component, the general idea is very simple. It's only about detecting the content-type, normalizing it if necessary (that would be the job of the serializer itself actually, but that's another matter) and sending it along with the rest of the content. At the beginning I started to think on how to implement it as a decorator, to keep the single object responsibility principle, but that's actually not possible since the default messenger serializer has one and only one content type configured at a time and will never propagate anything to the serializer component.
Not if you plug it on a message broker that connects multiple applications. It seems like all messenger component developers tend to think that it will never be used to communicate with non Symfony applications ?
I agree that this must remain extensible, it's a good thing, but why the messenger component should not take care of content-type ? It's one single thing to care of. It's a common concern, I think that having this per default will avoid many people the need to write their own implementation. The more people will have to write their own, the more bugs there will be into the wild. It really is boilerplate code that I'd like to not rewrite into each project, nor add a new dependency on each project for. |
|
The current state of the messenger component gives you some great default values. The serializer is easy to get started with and "it just works". When you want to communicate between different applications it will be far more complex and generic solutions are not good enough. The Messenger component will give you abstraction points where you can write custom logic. The Happyr Messenger Serializer gives you an example of that. If one feel like one have a super smart serializer that should also be shipped with the Messenger component, feel free to submit a PR or open an issue with a specific description how it will work. Im closing this issue because it is inactive for a while and because the discussion has not shown that something should be changed from the current behaviour. (Only open questions about how a new serializer may work has been discussed) |
Uh oh!
There was an error while loading. Please reload this page.
Symfony version(s) affected: 4.2, 4.3
When I look at the code of the
Symfony\Component\Messenger\Transport\Serialization\Serializerclass, it seems that the serialization format (as "format" in the symfony/serializer component semantics, but I'd prefer to call that "content type") is a property of the Serializer class, and it's fixed and always the same.This means that:
I might be missing something, but I'm reading the code, looking through the issues, and for the record using the messenger since 4.2 release (which means quite enough months) and I don't see anyway to come around this.
Worst thing is that if you let the default format be, have a live application, then change it by configuration for any reason at all, then deliver your new version, all stalling unprocessed yet messages will fail because they cannot be unserialized and you will loose them for eternity.
I can see some easy solutions, and all can be implemented at the same time:
add an optional
$contentTypeparameter on thedecode()function so that the receiver could pass an arbitrary content type, for example, AMQP transport might get the content type from thecontent-typemessage property (which is in the spec of the 0.9 and 1.0 versions),in the
encode()function add acontent-typeheader alongside thetype, and use that indecode()if present instead of the default one,add an additionel
ContentTypeStamp, this way API users can force a content type while publishing the message, which would be either kept in the encoded message, or converted to thecontent-typeheader in theencode()function.If the three are present and conflict while decoding, arbitrarily define an order of preference on which to use, personally I'd go for "receiver given content type" (the real one it seems), "header content type" (serializer enforced) then "ContentTypeStamp" (should not be present anymore at decoding) as a last resort.
Additionally, depending upon the transport (for example AMQP, that's the only one I actually read part the spec and tested, I'm not an expert just an amateur with it) you could have content types such
application/json,text/xmloramqp+some/other, but the serializer component is totally unable to handle those, so the messenger component should carry a mimetype to serializer format conversion routine.In all cases it's a requirement that:
The text was updated successfully, but these errors were encountered: