What simply began as a proof of concept during my flight towards Las Vegas (Imagine ’18), ended up as a scalable and extendable set of extensions in order to simplify the usage of webhooks within the Magento 2 platform.
Welcome to our first introduction blog about the purpose, goals and background stories on the MageHook extension for Magento 2 Open Source & Commerce. Later on, I’ll show some technological insights on how you, as a developer, can create your own webhook events within just a matter of minutes.
My name is Willem Poortman, founder and lead developer of MageHook. I started my career as a construction worker. Thanks to one of my hobbies, I was able to make the switch towards a full-stack web engineer a couple of years later. For the love of technology, my passion and experience for (Magento) backend development grew exponentially over the years.
After being an engineer for more than a decade, my focus switched partly towards managing development teams and help businesses get the most out of there Magento platform with the help of technology. Therefore I’m currently active as an Enterprise Architect at a renowned agency.
Personally, I love automation. Letting technology do the heavy lifting and take away the unnecessary noise within a process. In contradiction to Magento 2, possibilities for automation are in my opinion still in its early days. When I look around the market, most enterprises are willing to automate but don’t know where to start. Those starting points can be closer than you think, just by looking at the problem(s) and process(es) from a different angle.
I’ve started developing MageHook as a small hobby project just to provide myself with a simple solution to trigger HTTP requests towards multiple configurable endpoints. As a backend developer, I wanted to get more grip and insights on silent processes running in the background. By default, logging provided reasonable insights. Still, I needed to put in some effort instead of simply getting notified if some process ran successfully or threw an exception.
The architecture of MageHook changed quite a bit since my first proof of concept. Speed has been one of the main focus points over the majority of the development phase. Not only needed webhook events to be dispatched seamlessly, but also developers have to be brought up to speed building their own so-called Hook Event extension within minutes. Among other things, I’ve managed to do so by introducing a new webhooks.xml file including mostly optional parameters.
I knew I was up to something after we’ve implemented MageHook within one of Guapa’s client projects successfully and with real ease. In this case, we’ve used MageHook for exporting order data towards an automation platform. When it would receive any data, it would transform this data into an XML file based on a simple (point and click) mapping mechanism within the automation platform.
Besides from the transformation, it acted as a notification for any new order where it would download a order-PDF file from the Magento store the call came from. This was done by building a custom REST API endpoint on top of the PDF extensions provided by Fooman.
We not only gave the client full control over, for example, the mapping, but also the ability to chain even more events based on this single call. Therefore his automation workflow was on its way!
The other day someone asked me why I would invest so much energy and create this so-called “whooza” in and around just one single extension. Great question! Why would I go all-in on just this one piece of code? For me, the answer was pretty simple. As I mentioned before, I love automation and partly, therefore, learned myself programming. This extension combines those pieces of the puzzle I’m searching for, into one reusable solution. It creates a kickoff for event-driven automation within Magento 2, gives me the tools to get even more grip on what I build and delivers and provides developers all around the world, one unified solution which will be maintained and scaled towards the future. People should just give it a try and judge for themselves. For some it will work great where I hope they create there own ideas on top of MageHook. Others won’t like it and/or have already build their own (custom) solution. Either way, I will continue working on my “Whooza” (eye-wink).
How to start
MageHook is one of those tools which can help you get up and running with your automation workflows. MageHook is both build for merchants as for developers. When we zoom in on this second group, it is not only a micro-framework to build upon, but also a tool to manage your Magento store. Get actively notified about specific events. Like bugs which won’t be recognized by tools like Sentry or Raygun, receive notifications when an unwanted individual tries to repeatedly log in to the admin panel or notify all stakeholders at once when a new release is about to be deployed by one single bin/magento CLI command. Apart from recognition and notifying, you can also use MageHook as your export tool by sending data to for instance your ERP via a platform like Zapier or IFTTT.
As mentioned, the possibilities are endless, you just need to wrap your head around it. Just send me an email if you would like to brainstorm about your automation problems. Maybe I can help!
Don’t call us
Most developers already know the so-called Don’t call us, we call you principle. It not only benefits your bandwidth (eye-wink) but also requires less programming when you make use of webhooks. Webhooks can notify you and send along the required data instead of polling an API over and over without any results until something happened. MageHook is designed to (optionally) send the exact same data as you would receive it from an API. I’ve literally turned the principle around and gave developers an option to reflect an object and turn it into usable JSON-data just by defining a core Magento or custom written Service Interface.
Beside Interface reflection, a developer is also able to create it’s custom data array or provide a Converter class to transform the final payload before it gets stored inside the Message Queue. The final payload will eventually and optionally be wrapped with webhook specific data in order to recognize it on arrival.
What’s to come
I currently have a pretty large backlog that grows on a daily basis when I look at the feature perspective. Currently, I’m ready for distribution and will continue my work on stability. There is still a lot to improve and I hope to receive feedback from both merchants and developers as soon as things get’s rolling. I will give more details on how developers can participate shortly.
I’m also working hard on those so called “Hook Event” extensions to grow the availability of events. It’s finally getting up to speed after putting most effort into the core. The idea is to ship a pretty reasonable package of default (Open Source & Commerce) events together with the core product, which will grow with every update free of charge.
More about pricing models or a technical deep dive will be featured in future blog posts. Don’t hesitate to contact me in the meantime if you have any questions or want to participate by building your own Hook Events.