In addition to being one of the most significant modules of the MishkaInstaller library, the Hook module gives you the ability to make the library as a whole, as well as the projects that make use of this library, more modular.

It is essential to comprehend that you may treat any action performed independently as an event and register an unlimited number of plugins for that event.

You can do this by considering that action to be done separately. Each plugin has the potential to have its own individual inputs and outputs, and depending on the architecture of the area that you want to use Hook in, you may even be able to change the output and send it to other plugins.

Throughout all of the many parts that have been built for this module, it has been attempted to have a flexible approach to dealing with errors and to provide the programmer with a wide variety of options.

With the additional functions at her disposal, the programmer can actually create a gateway in their projects, where the data flow must pass through several gates, whether it changes or remains unchanged, and a series of operations are performed.

For illustration's sake, let's suppose you want the registration system to allow users to sign up for social networks on Twitter and Google.

When you use this library, it is conceivable that you can quickly display HTML or even operate in the background before registering after registering.

This is a significant improvement over the standard practice, in which you are required to modify the primary codes of your project. Create a separate plugin.

It is interesting to notice that these facilities are quite basic and convenient for the admin user.

If this opportunity is provided, the management can manage its own plugins in different ways if it has a dashboard.

It is crucial to highlight that each plugin is its own GenServer; in addition, it is dynamically supervised, and the information is stored in the database as well as in ETS.

Furthermore, this section is very useful even if the programmer wants to perform many tasks that are not associated with Perform defined functions.

The fact that the programmers have to introduce each plugin to the system based on a specific behavior is one of the exciting aspects of using this section. Additionally, the system has prepared some default behaviors to force the programmers to introduce the plugins in the order specified by the system.

The use of custom behaviors on the part of the programmer and MishkaInstaller itself makes debugging easier; however, this library does not leave the programmer to fend for themselves in this significant matter; rather, a straightforward error storage system is prepared based on the particular activities being performed.

Should prevent any unpredictable behavior at any costs.

build-purpose

Build purpose

Imagine you are going to make an application that will have many plugins built for it in the future. But the fact that many manipulations will be made on your source code makes it difficult to maintain the application. For example, you present a content management system for your users, and now they need to activate a section for registration and SMS; the system allows you to present your desired input/output absolutely plugin oriented to your users and makes it possible for the developers to write their required applications beyond the core source code.

We have used this library in the Mishka content management system.

plugin-management-system-implementation-theory

Plugin management system implementation theory

The library categorizes your whole software design structure into many parts; and has an appropriate dependency that is optional with GenServer; it considers a monitoring branch for each of your plugins, which results in fewer errors and downtime. The considered part:

1. Behaviors and events
2. Recalling or Hook with priority
3. State management and links to the database (PostgreSQL support)

Except from the 1st item, which can be redefined based on the developer's needs in his/her personal systems, the remaining items are almost constant, and a lot of functions will be handed to the developer to manage each plugin.

behaviors-and-events

Behaviors and events

In this section, you can define a series of events for each event, for example: after successful registration or unsuccessful purchase from “the store”, and for each event, put a set of callbacks in one module. After completing this step, when the user wants to create his own plugin, the @behaviour module will call you in its action module. This helps you have a regular and error-free system, and the library uses an almost integrated structure in all of its events.

hook-with-priority

Hook with priority

In Mishka Elixir Plugin Management Library, a series of action or hook functions are given to the developer of the main plugin or software, which helps build plugins outside the system and convert software sections into separate events. Some of the functions of this module include the following:

1. Registering a plugin outside of the system in database and ram state
2. Removing plugin from database and state
3. Restoring plugin
4. Successful pause of plugin
5. Hook plugin
6. Search among the events

And other functions that help both the mother software become an event-driven system and the developer can build the desired plugin or extension for different parts of the software and install it on the system as a separate package. This package can also be published in hex.

state-management-and-links-to-the-database-supporting-postgresql

State management and links to the database supporting PostgreSQL

The Hook module manages a large part of this part, and the developer of the external plugin usually does not need it much. Still, this part creates a state on RAM for each plugin that is activated in a specific event and a dynamic supervisor for it. This allows us in case of an error in each plugin; the other plugins in the different events face no errors, and the system will try to restart with various strategies. It should be noted for more stability and data storage after registering a plugin in the system; This section also maintains a backup copy of the database and strategies for recall in the event in case of an error. But to speed up the calling of each plugin, the website always uses state.

using-the-library

Using the library:

After installing this library, you must first install the required database of this package on your website, for which a mix task has been created, which is enough to load it once in your terminal, in the project path before the start.

mix mishka_installer.db.gen.migration

After implementing the above sections, you must first implement events in your main software and place the call function from the Hook module there to call all the plugins activated in the event you want based on priority. And give the state you want, to these plugins in order, and the output you expect will eventually be generated.

For example, you can see the mentioned description in a function controller in phoenix after a successful registration as the following:

def login(conn, %{"user" => %{"email" => email, "password" => password}} = _params) do
  # If your conditions are passed we call an event and pass it a struct of entries
  # which our developers need to create plugin with this information
  state = %MishkaInstaller.Reference.OnUserAfterLogin{
      conn: conn,
      endpoint: :html,
      ip: user_ip, type: :email,
      user_info: user_info
   }

  hook = MishkaInstaller.Hook.call(event: "on_user_after_login", state: state)

  hook.conn
  |> renew_session()
  |> put_session(:user_id, user_info.id)
  |> put_flash(:info, "You entered to our world, well played.")
  |> redirect(to: "/home")
end

Now the event is ready in the part where you need to allow the developer to make his own plugins for it. And it's time to write a plugin for this section. This is very simple. Consider the following example:

defmodule MishkaUser.SuccessLogin do
 alias MishkaInstaller.Reference.OnUserAfterLogin
 use MishkaInstaller.Hook,
    module: __MODULE__,
    behaviour: OnUserAfterLogin,
    event: :on_user_after_login,
    initial: []

 @spec initial(list()) :: {:ok, OnUserAfterLogin.ref(), list()}
 def initial(args) do
    event = %PluginState{name: "MishkaUser.SuccessLogin", event: Atom.to_string(@ref), priority: 1}
    Hook.register(event: event)
    {:ok, @ref, args}
 end

 @spec call(OnUserAfterLogin.t()) :: {:reply, OnUserAfterLogin.t()}
 def call(%OnUserAfterLogin{} = state) do
    new_state = Your_Code_Or_Function
    {:reply, new_state}
 end
end

As you can see in the above, we used MishkaInstaller.Reference.OnUserAfterLogin in order to activate behavior which has a few callback in it, and you can see here.

There should be two main functions in each plugin, namely initial and also call. In the first function, we introduce our plugin, and in the second function, whenever the action function calls this special event for which the plugin is written, based on priority. This plugin is also called. But what is important is the final output of the call function. This output may be the input of other plugins with higher priorities. The order of the plugins is from small to large, and if several plugins are registered for a number, it is sorted by name in the second parameter. And it should be noted that in any case, if you did not want this state to go to other plugins and the last output is returned in the same plugin, and you can replace {:reply, :halt, new_state} with {:reply, new_state}.

Subsequent plugins with higher priorities are not counted, and the loop ends here. Notice that a GenServer will be made based on each plugin name without a supervisor, which can be used for temporary memory in the case when the __using__ function is used as above, which results in the following option:

use MishkaInstaller.Hook,
    module: __MODULE__,
    behaviour: OnUserAfterLogin,
    event: :on_user_after_login,
    initial: []

The last two step to use the plugin you have to put it in your Application module so that whenever the server is turned off and on, the plugin is run again and if it is not registered, a copy of its support will be provided once in the database.

children = [
  %{id: YOUR_PLUGIN_MODULE, start: {YOUR_PLUGIN_MODULE, :start_link, [[]]}}
]

And add these config in your project like /config/config.exs

config :mishka_installer, :basic,
  repo: YOUR_Repo,
  pubsub: YOUR_PUBSUB or nil,
  html_router: YOUR_WEBSITE_ROUTER_MODULE

module-communication-process-of-mishkainstaller-hook

Module communication process of MishkaInstaller.Hook

1-call-plugins

1. call plugins

                                    +--------------+
                                    |  Application |
                                    +------+-------+
                                           |
                                    +------v------+
                                    |  Supervisor |
                                    +------+------+
                                           |
                                           |
+---------------------------+ +------------v----------------+
|                           | |                             |
| MishkaInstaller.PluginETS | | MishkaInstaller.PluginState |
|                           | |                             |
+---------------+-----------+ +-------------+---------------+
                |                           |
                |                           |
            +---v---------------------------v-----+
            |                                     |
            |      MishkaInstaller.Hook.call      |
            |                                     |
            +-------------------------------------+

2-register-a-plugin

2. Register a plugin

                                    +--------------+
                                    |  Application |
                                    +------+-------+
                                           |
                                    +------v------+
                                    |  Supervisor |
                                    +-------+-----+
                                            |
                                            |
+---------------------------+ +-------------v---------------+
|                           | |                             |
| MishkaInstaller.PluginETS | | MishkaInstaller.PluginState |
|                           | |                             |
+-----------------^---------+ +-------------^---------------+
                  |                         |
                  |                         |
            +-----+-------------------------+-----+
            |                                     |
            |    MishkaInstaller.Hook.register    |
            |                                     |
            +-------------------^-----------------+
                                |
                                |
                  +-------------+----------------+
                  | Developer's plugin GenServer |
                  +-------------^----------------+
                                |
                                |
                  +-------------+----------------+
                  |                              |
                  |Developer's plugin Application|
                  |                              |
                  +------------------------------+