SitePoint PHPPHP and RabbitMQ: Advanced Examples (17.10.2014, 16:00 UTC)

In part 1 we covered the theory and a simple use case of the AMQP protocol in PHP with RabbitMQ as the broker. Now, let’s dive into some more advanced examples.

Example 1: send request to process data asynchronously among several workers

In the example of the previous part, we had one producer, one consumer. If the consumer died, messages would continue to stack up in the queue until the consumer started again. It would then process all the messages, one by one.

This can be less than ideal in a concurrent user environment with a fair amount of requests per minute. Fortunately, scaling the consumers is super easy, but let’s implement another example.

enter image description here

Let’s say we have an invoice generation service, where the users just need to provide the invoice number, and the system will automatically generate a pdf file and email it to the user. Generating and sending the email could take even several seconds if the server on which the generation process runs is resource limited. Now suppose we are required to support several transactions per second, how do we accomplish this without overwhelming the server?

We need to implement the following pattern:

enter image description here

Let’s look at our producer class:

<?php
namespace Acme\AmqpWrapper;

use PhpAmqpLib\Connection\AMQPConnection;
use PhpAmqpLib\Message\AMQPMessage;

class WorkerSender
{
    /* ... SOME OTHER CODE HERE ... */

    /**
     * Sends an invoice generation task to the workers
     * 
     * @param int $invoiceNum
     */ 
    public function execute($invoiceNum)
    {
        $connection = new AMQPConnection('localhost', 5672, 'guest', 'guest');
        $channel = $connection->channel();

        $channel->queue_declare(
            'invoice_queue',    #queue - Queue names may be up to 255 bytes of UTF-8 characters
            false,              #passive - can use this to check whether an exchange exists without modifying the server state
            true,               #durable, make sure that RabbitMQ will never lose our queue if a crash occurs - the queue will survive a broker restart
            false,              #exclusive - used by only one connection and the queue will be deleted when that connection closes
            

Truncated by Planet PHP, read more at the original (another 2293 bytes)

Link
Anthony FerraraA Followup To An Open Letter To PHP-FIG (17.10.2014, 11:00 UTC)
A few days ago, I wrote An Open Letter to PHP-FIG. Largely the feedback on it was positive, but not all. So I feel like I do have a few more things to say.

What follows is a collection of followups to specific points of contention raised about my post. I'm going to ignore the politics and any non-technical discussion here.

Read more »
Link
thePHP.ccJoomla PHPUnit Code Sprint (17.10.2014, 07:00 UTC)
Link
SitePoint PHPHow to use RabbitMQ with PHP (16.10.2014, 16:00 UTC)

AMQP (Advanced Message Queueing Protocol) is a network protocol that can deliver messages from one application endpoint to another application endpoint. It does not matter the platform or language of said applications, as long as they support AMQP.

Essentially, one of the application endpoints sends a message, thus being a Producer, through an AMQP broker. In turn the broker will deliver the message to another application endpoint, called the Consumer.

RabbitMQ is an AMQP broker that has support for several programming languages, such as PHP.

The advantage of having a message broker such as RabbitMQ, and AMQP being a network protocol, is that the producer, the broker, and the consumer can live on different physical/virtual servers on different geographic locations.

Also, since networks are unreliable, and applications might fail to process a message completely, AMQP supports message acknowledgements, either automatically or when an application endpoint decides to send them.

RabbitMQ implements the AMQP 0-9-1 protocol. At a glance, it follows the following model.

Hello world example routing

Glossary

Concept Definition Icon
Producer Application endpoint that sends messages Producer icon
Consumer Application endpoint that receives messages Consumer icon
Connection Handles protocol, errors, authentication, etc… The connection is done using TCP protocol. -
Channel Connections are multiplexed through channels. Even though all channels share the same tcp connection, communication from one channel is completely independent of another. -
Exchange Receives messages from producers and pushes them to queues. Depending on the situation, this can be transparent to the developer. Exchange representation
Queue Buffer that stores messages Queue icon
Message Piece of arbitrary information conforming to the AMQP format that is sent from the producer to a consumer through the broker. The broker cannot modify the information inside the message. -
Acknowledgements Notice sent back from the consumer to tell the server that a message has been received and processed, so the server can delete it from the queue. -

Another advantage of AMQP 0-9-1 is that the application defines the routing logic instead of a broker administrator. This gives the developer a lot of flexibility, without the need to learn a new programming/scripting/markup language.

You can learn more about AMQP and RabbitMQ at the “AMQP 0-9-1 Model Explained” guide. Although not necessary for this tutorial, I encourage you to read it completely.

Continue reading %How to use RabbitMQ with PHP%

Link
labs @ Qandidate.comUsing the Accept Header to version your API (16.10.2014, 14:00 UTC)

I investigated different ways to version a REST API. Most of the sources I found, pretty much all said the same thing. To version any resource on the internet, you should not change the URL. The web isn't versioned, and changing the URL would tell a client there is more than 1 resource. But actually there aren't multiple resources, it's just a different representation of the same resource. Of course there are cases where you should change the URL; for example if you are changing the API in such a way that its functionality alters. In this particular case you could consider changing the URL as you could reason that it is not the same resource anymore.

But another thing, and probably even more important, you should always try to make sure your changes are backwards compatible. That would mean there is a lot of thinking involved before the actual API is built, but it can also save you from a big, very big headache.

∞ labs @ Qandidate.com Permalink

Link
PHP ClassesCompiling PHP into Optimized Machine Code - Lately in PHP podcast episode 52 (16.10.2014, 09:29 UTC)
By Manuel Lemos
The recent release of a new PHP compiler written in PHP by a Google PHP developer, as well other solutions to compile PHP into optimized native machine code, is one of the main topics discussed by Manuel Lemos and Arturs Sosins on the episode 52 of the Lately in PHP podcast.

They also discussed the latest proposals for new features of PHP 7, as well the new MySQL plugin that allows accessing MySQL servers directly with HTTP exchanging data in JSON format.

Now listen to the podcast, or watch the hangout video, or read the transcript to learn about the details of these interesting PHP related discussions.
Link
Qafoo - PHPUtilize Dynamic Dispatch (16.10.2014, 05:00 UTC)
A while ago I replied to the tweet by @ramsey
Traits are a nice way to provide common functionality to unrelated classes without using static methods on a global Util class.
with
Which makes them exactly as evil as static access. Funktionality you dispatch to becomes irreplaceable destroying a fundament of OO: Dynamic dispatch.
I want to use this blog post to illustrate the concept of dynamic dispatch which I use a lot recently to motivate creating clean OO structures in my trainings. In my experience, this helps people to understand why we want to write code in this way. After that I will show why traits are bad in this direction.
Link
PHP: Hypertext PreprocessorPHP 5.5.18 is available (16.10.2014, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 5.5.18. Several bugs were fixed in this release. A regression in OpenSSL introduced in PHP 5.5.17 has also been addressed in this release. PHP 5.5.18 also fixes 4 CVEs in different components. All PHP 5.5 users are encouraged to upgrade to this version. For source downloads of PHP 5.5.18 please visit our downloads page, Windows binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.
Link
PHP: Hypertext PreprocessorPHP 5.4.34 Released (16.10.2014, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 5.4.34. 6 security-related bugs were fixed in this release, including fixes for CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. Also, a fix for OpenSSL which produced regressions was reverted. All PHP 5.4 users are encouraged to upgrade to this version. For source downloads of PHP 5.4.34 please visit our downloads page, Windows binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.
Link
PHP: Hypertext PreprocessorPHP 5.6.2 is available (16.10.2014, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 5.6.2. Four security-related bugs were fixed in this release, including fixes for CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. All PHP 5.6 users are encouraged to upgrade to this version. For source downloads of PHP 5.6.2 please visit our downloads page, Windows binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.
Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP