While looking at the code of this library, I came to the conclusion that even though there are libraries providing what looks like very similar functionality at first glance, they are not the same thing.
In this post, I would like to clear up any misconceptions.
I would also like to apologize in advance for any lack of information regarding the webhook_hotplug.mo file and its role in the library.
Philosophy: Unix Principle vs. All-in-One
Let’s start with the liminal library, which is a technological “combine harvester” combining many functionalities. I won’t go into detail explaining it because the repository’s README has already done that.
My project, on the other hand, is based more on the Unix philosophy: “Do one thing and do it well.”
My goal was to create a solution for a 2-canister application (frontend + backend) that allows them to expose an API gateway via the backend canister — for example, for devices from the ESP32 family and others where libraries like ic-py cannot be implemented.
Simplicity of Implementation
The entire library was designed to be simple and not require writing huge amounts of additional code for implementation.
The main.mo example from the project demonstrates how simple the implementation is:
Motoko
public func greet(name : Text, value : [Webhook.Webhook]) : async Text {
set_webhook(value, name);
return "drop";
};
The Role of webhook_hotplug.mo
Looking at webhook_hotplug.mo, the library also takes care of generating ready-to-use functions and an array for the webhook.
Unfortunately, this may imply individual implications in specific cases due to compiling the same functions twice. Because of this, webhook_hotplug.mo is used as an optional component of the library, intended to be applied only when there are no contraindications to do so.
