Download the PHP package happyr/message-serializer without Composer
On this page you can find all versions of the php package happyr/message-serializer. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download happyr/message-serializer
More information about happyr/message-serializer
Files in happyr/message-serializer
Package message-serializer
Short Description Serialize classes the good way.
License MIT
Informations about the package message-serializer
Message serializer
This package contains some interfaces and classes to help you serialize and deserialize a PHP class to an array. The package does not do any magic for you but rather help you to define your serialization rules yourself.
Install
See integration with Symfony Messenger.
The Problem
When you serialize a PHP class to show the output for a different user or application there is one thing you should really keep in mind. That output is part of a public contract that you cannot change without possibly breaking other applications.
Consider this example:
This will output:
Even if you doing something smart with json_encode
you will get:
This might seem fine at first. But if you change the Foo
class slightly, say,
rename the private property or add another property, then your output will differ
and you have broken your contract with your users.
The solution
To avoid this problem we need to separate the class from the plain representation.
The way we do that is to use a Transformer
to take a class and produce an array.
This transformer is only responsible to convert a Foo
class to an array. The
reverse operation is handled by a Hydrator
:
With transformers and hydrators you are sure to never accidentally change the output to the user.
The text representation of Foo
when using the Transformer
above will look like:
Manage versions
If you need to change the output you may do so with help of the version property.
As an example, say you want to rename the key bar
to something differently. Then
you create a new Hydrator
like:
Now you simply update the transformer to your new contract:
Differentiate between "I cant hydrate message" and "Wrong version"
Sometimes it is important to know the difference between "I dont not want this message" and "I want this message, but not this version". An example scenario would be when you have multiple applications that communicate with each other and you are using a retry mechanism when a message failed to be delivered/handled. You do not want to retry a message if the application is not interested but you do want to retry if the message has wrong version (like it would be when you updated the sender app but not the receiver app).
So lets update FooHydrator2
from previous example:
SerializerRouter
If you dispatch/consume messages serialized with Happyr\MessageSerializer\Serializer
and default Symfony messenger to same transport you might wanna use
Happyr\MessageSerializer\SerializerRouter
. This serializer will decide whether
it will use Happyr\MessageSerializer\Serializer
to decode/encode your message
or the default one from Symfony messenger.
Integration with Symfony Messenger
To make it work with Symfony Messenger, add the following service definition:
If you automatically want to tag all your Transformers and Hydrators, add this to your main service file:
Then finally, make sure you configure your transport to use this serializer:
Note about Envelopes
When using Symfony Messenger you will get an Envelope
passed to TransformerInterface::getPayload()
. You need
to handle this like:
Pro tip
You can let your messages implement both HydratorInterface
and TransformerInterface
:
Just note that we cannot use a constructor to this class since it will work both as a value object and a service.