Coder Social home page Coder Social logo

queue-interop's Introduction

Queue Interoperability

Latest Stable Version Monthly Downloads Total Downloads License

About

queue-interop tries to identify and standardize a common way for PHP programs to create, send, receive and read MQ messages to achieve interoperability.

Through discussions and trials, we try to create a standard, made of common interfaces but also recommendations.

If PHP projects that provide queue implementations begin to adopt these common standards, then PHP applications and projects that use MQs can depend on the common interfaces instead of specific implementations. This facilitates a high-level of interoperability and flexibility that allows users to consume any MQ transport implementation that can be adapted to these interfaces.

The work done in this project is not officially endorsed by the PHP-FIG. We adhere to the spirit and ideals of PHP-FIG.

Installation

You can install this package through Composer:

# Install a Queue Interop compatible transport, for example 
$ composer require enqueue/fs

Examples

Send a message:

<?php

use Enqueue\Fs\FsConnectionFactory;

$context = (new FsConnectionFactory())->createContext();

$context->createProducer()->send(
    $context->createQueue('aQueue'), 
    $context->createMessage('aBody')
);

Consume a message:

<?php

use Enqueue\Fs\FsConnectionFactory;

$context = (new FsConnectionFactory())->createContext();

$consumer = $context->createConsumer($context->createQueue('aQueue'));

$timeout = 5000; // 5sec
if ($message = $consumer->receive($timeout)) {
    // process the message.

    $consumer->acknowledge($message);
}

Find out more here:

Compatible projects

Projects

Implementations

Amqp interop

There is AMQP interop built on top of Queue Interop. It is completly compatible with queue interop and only adds some AMQP specific features:

  • Queue\Exchange declaration
  • Queue\Exchange Binding.
  • Basic consume support.
  • and other AMQP specific features.

Compatible projects

Workflow

Everyone is welcome to join and contribute.

We try to not break BC by creating new interfaces instead of editing existing ones.

While we currently work on interfaces, we are open to anything that might help towards interoperability, may that be code, best practices, etc.

License

MIT license

queue-interop's People

Contributors

aistis- avatar askozienko avatar benceszalai avatar francislavoie avatar joubertredrat avatar kartavik avatar makasim avatar samnela avatar sylfabre avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

queue-interop's Issues

Quick review of queue-interop with some comments

Hi @makasim

I viewed queue-interop a few months ago but never had time to properly give some feedback when you started the project, sorry.

Having worked on PSR-11, I can give you a bit of advices if you ever want to push this on the PHP-FIG for a PSR. So here we go:

PHP 5 vs PHP 7:

I saw you discussed the issue here (#2). You decided to go for PHP 5 support a few month ago, but the tide has turned since then. Then newly passed PSR-15 is PHP 7+ only and upcoming PSR will be PHP 7+. So you should definitely target PHP 7 now.

Naming:

The interfaces are named PsrXxx. For instance PsrMessage. "Psr" does not add any value. On the other hand, you like the Interface suffix. I know many people feel it's wrong to have an Interface suffix (I'm part of those), but there has been a poll on the PHP-FIG mailing list 2 years ago and it was decided to go with the suffix.

So you should rename your interfaces this way:

  • PsrMessage => MessageInterface

Immutability:

PSR-7 objects (RequestInterface and ResponseInterface) are immutable. This is a very nice property to have as it prevents a number of side-effect bugs. It could be useful to have that in Queue-interop also (so you could drop all the setters from Message and replace those with withXxx methods).

Scope:

This is a big one. I think your interfaces have way too many methods. You want to cover all the existing features of all queuing systems. Maybe you should rather target what all systems have in common (i.e. send and consume) rather than putting all possible features of all systems in your interface.

For instance:

PsrProducer::setDeliveryDelay seems highly suspicious to me. First of all, the "delivery delay" notion could belong to a message rather than to a producer. It can be nice for producers to have default values, but this is an implementation detail, it has nothing to do in an interface. Then, an interface with setters is usually a code smell (if you want to know why, see https://ocramius.github.io/extremely-defensive-php/)

I really don't have much time to look in depth at queue-interop, but if you can get some people interested on the PHP-FIG mailing list (I know, it's hard), I'm sure you could get a ton of feedback that would probably change quite radically the structure of your interfaces. I started this way with container-interop, and it's really a great learning opportunity when you have all those skilled people looking at your code. So give it another try and try to gather some more feeedback, it's worth it!

Drop PHP 7.1 and 7.2 support

Would you be willing to drop support for PHP 7.1 and 7.2? If yes I'd be happy to open a Pull Request that does this.

Message creation should not depend on context

Hello,
Thanks for the initiative.

I have a suggestion. Object creations depend on PsrContext , which looks like a technical leak.
Also, it brings a strong dependency on the context.

This is the current interface:

$context->createProducer()->send(
    $context->createQueue('aQueue'), 
    $context->createMessage('aBody')
);

With this interface, if I want to write a service pushing a message, it would either depend on:

  • PsrContext, which is technical, and more than what I need (I don't want to consume the message there),
  • or PsrProducer, plus handwritten QueueFactory and MessageFactory to hide the context.

What about having PsrMessage and PsrQueue as plain PHP objects ?

$context->createProducer()->send(
    new PsrQueue('aQueue'), 
    new PsrMessage('aBody')
);

Typically, I would let a dependency injection container manage PsrProducer instantiation.
Then, my business class would just depend on the producer to send messages.

The producer being provided by the context has all necessary data to decorate the message and queue with technical information, without the end developer having to specify it.

This is in my opinion more DX. It would also reduce the PsrContext interface responsibility to PsrConsumer and PsrProducer creation.

Should the interop supports 5.x PHP?

That's more a poll rather than an issue. So if you think it has to require PHP7.1 as put ๐Ÿ‘ if you think it worth supporting 5.x put ๐Ÿ‘Ž .

Proposals

This is a list of places where queue interop was proposed or could be helpful:

(The list is updated regularly)

Master branch more recent than develop

The Problem

Not sure what the Git workflow used here is, but develop, which usually represents the latest unstable version, should probably not be behind master, which usually represents the latest stable.

Further more, for the reasons mentioned above, the masterbranch should not be the main branch of the repository.

Suggested Solution

  1. Merge master into develop
  2. Direct features/bugfixes to develop from that point onward.
  3. Make develop the main branch of the repository.

Still maintained?

Is this effort still maintained? It appears to have no stable releases, just alphas, but Packagist reports a whole crapload of dependent packages and millions of installs. I'm not sure what to make of that. The most recent alpha tag also doesn't list PHP 8 compatibility, but master does.

Context: I am investigating possible queue solutions for TYPO3 and this is one I am considering. But if it's not actively maintained and PHP 8.1-friendly then it's not really an option for us.

Traits to implement Interfaces

Would you consider a PR with Trait to implement common methods defined by Interfaces?

I've in mind this Interop\Queue\Message interface.

Almost all implementations define the same method bodies which makes a lot of code duplicate that could be cleaned up.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.