Finally..

On Tue, May 23, 2017 at 5:28 PM, Maksim Kotlyar <[email protected]>
wrote:

> Here's one more example: A MQ based spool for Swiftmailer.
>
> example: https://github.com/php-enqueue/enqueue-sandbox/blob/
> master/swiftmailer/send.php
> spool implementation https://github.com/php-enqueue/enqueue-
> sandbox/blob/master/swiftmailer/QueueSpool.php
>
> On Tuesday, May 23, 2017 at 1:54:17 PM UTC+3, [email protected] wrote:
>>
>> Hi,
>>
>> I'm one of the core maintainers of the prooph project.
>> We've defined a common Message interface https://github.com/p
>> rooph/common/blob/master/src/Messaging/Message.php
>> that acts as the basic building block for all our packages. We tried to
>> keep the interface as simple as possible.
>> As you can see prooph messages support the architectural patterns CQRS
>> and Event Sourcing (our main focus) by defining a message type
>> and a message name.
>>
>> Type is important because commands and queries should only have one
>> handler/consumer whereby events can have many listeners (fanout).
>> Message name is mainly used for routing and to describe the intent of the
>> message (DDD / Event Sourcing).
>>
>> Our messages are *immutable* similar to what PSR-7 defines for Req / Res.
>>
>> Furthermore messages have:
>> - a uuid (could be generalized to be only a string or we need a PSR for
>> UUIDs ;) )
>> - metadata (custom key => value pairs)
>> - payload (application data)
>> - createdAt (a \DateTimeImmutable because it includes micro seconds)
>>
>>
>> IMHO a messaging API PSR is too much but a *Message PSR* (like PSR-7 is)
>> would be nice.
>> Http req / res are very similar to other types of messages and in fact
>> Zend promotes this for years:
>> stdlib MessageInterface: https://github.com/zendframewo
>> rk/zend-stdlib/blob/master/src/MessageInterface.php
>> http messages implement stdlib: https://github.com/zendframewo
>> rk/zend-http/blob/master/src/AbstractMessage.php
>>
>> We have PSR-7 (which is a good thing) but we have no general PSR for
>> messages. If we would have such a PSR then
>> libraries dealing with messaging could build their logic on top of it.
>>
>> For example prooph messaging system integrations rely on prooph's message
>> interface. We have integrations for Bernard, amqp, ZeroMQ, AWS SQS (not
>> open source)
>> and HTTP for inter process communication and the same message interface
>> is used to route messages within an application, let event sourced
>> aggregates record domain events
>> which are then stored in an event store and pulled by projections.
>> All these use cases are supported by this "simple" interface and it did
>> not change much over the last 4 years.
>> I'm not saying it is a perfect foundation for a PSR (f.e. we rely on
>> Ramsey\Uuid) but I think a message interface defined by a PSR should not be
>> more complex than the prooph message interface.
>> Everything else can be designed around it (like done with middleware
>> PSR-15)
>>
>> Best regads,
>> Alex
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/php-fig/1b5e09e4-546f-4a83-9617-9cf35641033a%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/1b5e09e4-546f-4a83-9617-9cf35641033a%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAAKrFTw_chFfaHnM4-t4rG3df%3D5qeOiTLm46Tt3zGmrsjS_6%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to