As mentioned in my previous blog, I want to zoom in on the technical side of the MageHook extension. MageHook has always been intended as a creative toolset to let developers build their webhooks in a very easy way, without having to worry about the underlying matters. Most of the technical necessities are available out of the box and will be expanded every trimester. New webhook events will be added on a monthly basis. Both free from additional fees.

Quality

Quality code has always been an important factor for everything I’ve written in the past. I’ve gained a lot of passion for code- and extension quality thanks to people like Kristof, founder of Fooman or Jisse, initiator of ExtDN. They are down to earth, realizing not everything can be perfect from the get-go but also manage to keep you on your toes.

MageHook is nothing different. The extension uses a good portion of Magento 2 best practices but also a lot of newly developed features to try new things. I’ve managed to create a good mix of recognizable core elements together with features you maybe need to wrap your head around at first. Besides a lot of code, some important elements, like unit tests for instance, are unfortunately still missing. It’s a well-considered decision I’ve made during the development phase. But not to worry, it’s on top of the roadmap!

Scalability

I’ve started my research before writing the first lines of code and reviewed multiple webhook extensions within the market. They all have some special feature which can be compared to those within the MageHook core. Scalability has been one of the biggest features I’ve missed within all of them. They have static baked in webhook events to which you can link a single endpoint.

I’ve managed to step it up a notch in order to give developers and shop administrators the possibility to attach multiple endpoints onto the same event. On top of it, I’ve introduced the new /etc/webhooks.xml file, which gives developers the power to offer their own webhook events from their own module.

<hook event="example_event"
      title="Example Title"
      purpose="Example Purpose"
      group="Example Group"
      service="Magento\Catalog\Api\Data\ProductInterface"
      converter="Basic\Example\Model\Converter\Product"
      validator="Basic\Example\Event\Options\Validator\Product"
      list="frontend"/>

Features

MageHook brings features for many specialists in the commerce market. Not only shop owners and Developers but also, for example, Marketeers, Solution Integrators, Technical Support Departments, Testers and UX-designers can use webhooks to their advantage. Therefore I’ve started to develop a new Tenders feature. This feature allows companies to inject a locked webhook via an API request. The only thing a system administrator has to do is give them the right integration keys and accept the request manually on arrival. This webhook is pointed towards a single event and endpoint.

As you can imagine, this opens up a lot of options for companies to gain particular information without having to write, implement and maintain a Magento extension which does (almost) the same thing.

Event options

Out of the box, developers can create webhook events thanks to the etc/webhooks.xml.

They can make use of the following options:

RequiredDefault ValueValue Type
EventYesN/AString
TitleYesN/AString
PurposeN/AString
GroupN/AString
Service *N/AString
Converter *N/AString
Consumer *defaultString
RequestasyncString
ListadminhtmlString
ValidatorN/AString

Service Interface

A service Interface can optionally be defined. It acts as a reflection interface for all ‘setters’ and ‘getters’. This can come in handy when you have a large object like an order model. You can always use the getData method to wrench out the order data and send it along with the event dispatching. The downside of this hardcoded road is that you will miss data like Extension Attributes. This will be taken care of when you can use a reflection interface (Service). The outcome of the reflection will be used as the final payload.

Converter Class

This feature came along when I was writing the Service feature. The converter is a defined (custom) class that can help you add or remove data from the payload before it gets sent to the Message Queue.

Customer Class

By default, a default Consumer takes care of all the HTTP requests. Therefore, the default Consumer handles all requests via the Guzzle library. The fun of this feature is that you can write your own custom Consumers which adds, for instance, some default authentication headers.

Another benefit is that I’m able to replace Guzzle (6) easily when needed. It’s not that I’m planning to, because I love and support the library and I have written an additional request logging mechanism thanks to the provided middleware layer.

Backlog

As said, I’m currently working on the Tender feature to allow third parties to implement their own webhooks into your Magento store. Apart from that, I’m busy writing unit tests which I hope to release pretty soon.

The current backlog contains twenty-two issues where some are minor bugs and others are some really awesome features which I will tell more about in future blog posts.

Despite the monthly costs of the extension, I’m looking for ways on how developers can participate. I really believe in open-sourcing code, but also love the entrepreneurship. I have looked at the options and have, among other reasons, chose to market the extension as a paid product.

Technical deep-dive

I’m about to create some video content to show more practical use-cases in which I will explain even more about MageHook. Don’t hesitate to contact me in the meanwhile!

Categories: Technical