Observers are great.

Little code points that allow the developer to hook in to allowing some custom logic to be performed in line with current program flow.

For example, in Magento 2 you might have something like; 

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Event/etc/events.xsd">
    <event name="sales_order_place_after">
        <observer name="[observer_name]" instance="[Vendor]\[ModuleName]\Observer\[ObserverName]" />
    </event>
</config>

And the observer;

<?php

namespace [Vendor]\[ModuleName]\Observer;

use Magento\Framework\Event\Observer;
use Magento\Framework\Event\ObserverInterface;

class [ObserverName] implements ObserverInterface
{
    public function execute(Observer $observer)
    {
        $order = $observer->getOrder();
        // send order to third party
    }
}

Cool.

We can now manipulate the order, send it somewhere, put it on hold, whatever you wish.

I have used this particular example though to highlight a point often overlooked when using the all to easy observer pattern.

Whatever operation you do in an observer will inevitably increase, to varying degrees, the time it takes to complete the program flow.

How can it not?

It is now doing something else it wasn’t doing before.

How much it affects the speed of the website will depend massively on the code injected.

In the above, the customer has just placed an order and is waiting for the site to respond. Most likely a thank you page confirming their order details.

Often I see questions being asked regarding where best to put code to send the order to a third party system and invariably people suggest the above.

The above is absolutely not the best place to put such code.

It is of course the most convenient and for that reason alone is why it is often the chosen solution.

However, all the time the code is traversing the observer is time the customer is having to wait. They don’t care that the order needs to be sent to a third party system but they do care about the time they are having to wait for a response from your website.

What if the third party service is running slow?

What if it is down?

Well using the above approach will directly affect the customer experience.

Not to mention that the observer is a one time operation. If the order fails to send it cannot be repeated easily.

The same can be said for any bit of code injected. Modifying html output (using view_block_abstract_to_html_before event), changing something after a model is loaded (model_load_after event) are just some other examples that can quite quickly degrade performance.

Clichè alert!

Time is money.

If you don’t believe me, read this article from KissMetrics.

If an e-commerce site is making $100,000 per day, a 1 second page delay could potentially cost you $2.5 million in lost sales every year.”

Interesting!

A possible solution to the above sales order issue is to use a background task (cron) to push orders to the third party. Not only does it take the burden away from the customer but it is also repeatable should it fail.

Or how about they use the api to fetch the orders from you instead of you having to push them?

That would obviously require development from the third party if they did not already have a connector available and that might not be a viable solution.

Speed is king!

  • magento
  • observers

Like this post? Share it :)

Related Posts

← Back