-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Messenger] Add TransportInterface as first class citizen sender+receiver #27164
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.
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
Conversation
887d7b4
to
bd0733d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea.
Interestingly, that was in the original proposal but @lyrixx had a strong 👎 for it being a unnecessary abstraction layer.
@@ -33,7 +33,7 @@ public function __construct(EncoderInterface $messageEncoder, Connection $connec | ||
/** | ||
* {@inheritdoc} | ||
*/ | ||
public function send($message) | ||
public function send($message): void |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m not fond of the idea of enforcing void
as a result. Senders might return something later on, we shouldn’t close that door IMHO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing void should be ok for the bc policy. See symfony/symfony-docs#9717
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough.
*/ | ||
public function receive(callable $handler): void | ||
{ | ||
($this->receiver ?? $this->getReceiver())->receive($hander); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems ternary operator fits better here (same below) ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you mean, doesn't feel like to me :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @yceruto mean next variant:
$this->receiver ? $this->receiver->receive($hander) ? $this->getReceiver()->receive($hander)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant ($this->receiver ?: $this->getReceiver())->
instead, as $this->receiver
is always defined I don't see the need for ??
, but probably I'm missing something here :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$this->receiver
is null
until $this->getReceiver()
is called a first time. So makes sense to use the null-coalescing operator rather than ternary for this :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the manual:
The null coalescing operator (??) has been added as syntactic sugar for the common case of needing to use a ternary in conjunction with isset(). It returns its first operand if IT EXISTS and is not NULL; otherwise it returns its second operand.
So ternary operator fits better in this case as $this->receiver
always exists (i.e. this var is defined always), but NVM it's just a detail, ??
works fine too.
This one should be rebased |
bd0733d
to
e3f800f
Compare
e3f800f
to
379b8eb
Compare
PR rebased |
Thank you @nicolas-grekas. |
…n sender+receiver (nicolas-grekas) This PR was merged into the 4.1 branch. Discussion ---------- [Messenger] Add TransportInterface as first class citizen sender+receiver | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - The current design misses an opportunity to reuse the same connection for the sender and the receiver parts of a transport. By making `TransportInterface` a first class citizen, we simplify the wiring logic, we allow sharing the same connection for both the sender and the receiver, and we provide a natural point to lazily create the connection. Live from Las Vegas :)  Commits ------- 379b8eb [Messenger] Add TransportInterface as first class citizen sender+receiver
This PR was merged into the 4.1 branch. Discussion ---------- [Messenger] Fix AMQP Transport | Q | A | ------------- | --- | Branch? | 4.1 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #27164 | License | MIT | Doc PR | - - [x] Fix typo - [x] Fix create `Connection` instance - [ ] Add test Commits ------- b8a4d5a Fix AmqpTransport
…nterface (ogizanagi) This PR was merged into the 4.1 branch. Discussion ---------- [Messenger] Fix AMQP Transport factory & TransportFactoryInterface | Q | A | ------------- | --- | Branch? | 4.1 <!-- see below --> | Bug fix? | yes | New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files --> | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | #27164 <!-- #-prefixed issue number(s), if any --> | License | MIT | Doc PR | N/A Seems like we did review a bit fast here 😅 Commits ------- 98967cd [Messenger] Fix AMQP Transport factory & TransportFactoryInterface
This PR was merged into the 4.1 branch. Discussion ---------- [Messenger] Fix the transport factory after moving it | Q | A | ------------- | --- | Branch? | 4.1 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #27164 | License | MIT | Doc PR | ø `ChainTransportFactory` was renamed but the `messenger.xml` wasn't changed. Commits ------- 7a091d9 Fix the transport factory after moving it
This PR was submitted for the master branch but it was squashed and merged into the 4.1 branch instead (closes #9727). Discussion ---------- [Messenger] Update the messenger documentation - [x] Fixes #9641 with the middleware configuration. - [x] Fixes #9617 with the multiple bus configuration. - [x] Change adapters to transports (waiting merge: symfony/symfony#27129) - [x] middlewares config entry is renamed middleware (symfony/symfony#27177) - [x] in the config, message buses names are the full service id you'll use (symfony/symfony#27162) - [x] Add TransportInterface as first class citizen sender+receiver (symfony/symfony#27164) Commits ------- c3c3528 Few updates following review 64bfd75 Change wording and don't use `.`-based services so it's just clearer e1f3b5a Fix the formating of the method name 9b7b85f Update the example of using multiple buses to use DI's `bind`s c76b2c2 Uses the full service name when configuring the buses from the YAML configuration 2409798 Middleware does not have a plural a20286d Add a note about the symfony serializer pack 10f46eb Introduce the `TransportInterface` ef70bc0 Add a documentation about the middlewares 3ff8cfe Add multiple buses configuration and type-hint example a4bc592 Rename the adapters to transport
The current design misses an opportunity to reuse the same connection for the sender and the receiver parts of a transport. By making
TransportInterface
a first class citizen, we simplify the wiring logic, we allow sharing the same connection for both the sender and the receiver, and we provide a natural point to lazily create the connection.Live from Las Vegas :)