In one of our previous blogs we explained how to use workflows and actions. A natural follow up question becomes how to create a custom action.
By creating custom Hyperlambda actions you can effectively turn your cloudlet into a "domain specific No-Code programming language", allowing you to use software development orchestration, to dynamically compose workflows from your own custom actions. To use an analogy, imagine if you could create your own LEGO bricks.
If actions are LEGO bricks, and workflows are LEGO buildings, then custom actions is the ability to create your own custom LEGO bricks
The code
In the above video I create a custom action. Before you create the following action, you'll need to install the "Chinook" plugin. This plugin creates a new database for you, and populates it with some example data. In addition the plugin contains some SQL snippets you can consume and play with.
Below you can find the code for my custom action. Create a Hyperlambda file with the path of "/etc/workflows/actions/chinook-albums-count.hl" and put the following content into it.
/*
* Returns artists and count of records per artist, sorted by artist having the most albums.
*/
.arguments
filter
type:string
mandatory:bool:true
.icon:home
data.connect:chinook
data.select:@"
select ar.Name, count(*) as count
from Album al, Artist ar where al.ArtistId = ar.ArtistId
and ar.Name like @filter
group by al.ArtistId
order by count desc
limit 25"
@filter:x:@.arguments/*/filter
return:x:-/*
When you have saved the above file, you can refresh your browser, which will ensure Hyper IDE reloads your workflow actions, at which point Hyper IDE should resemble the following.
Notice, there is nothing preventing you from creating your own custom actions by using existing actions, to such "layer" your architecture into as many layers as you wish.
Consuming your Custom Action in your own Workflow
To consume your newly created action, create any Hyperlambda file, click the "chinook-albums-count" action from your toolbox, and Hyper IDE will ask you for input arguments to your action.
At this point you can already shimmer the power of "meta programming". Meta programming is the ability for the computer to automatically determine structure from your code. For this particular example, it is able to determine that your action takes one input argument, being its [filter] argument. Since my endpoint also have an input argument with the same name, it by default suggest for me to use this argument as its input to my custom action.
This allows me to simply click the action in my toolbox, for then to click the enter key, and I have added an action to my workflow that just so happens to count albums released by artists, while filtering on artist names, and sorting artists such that those with the most albums ends up being returned first. Below is the code Hyper IDE automatically created for me after clicking the above OK button.
// Returns album counts per artist
.arguments
filter:string
// Returns artists and count of records per artist, sorted by artist having the most albums.
execute:magic.workflows.actions.execute
name:chinook-albums-count
filename:/etc/workflows/actions/chinook-albums-count.hl
arguments
filter:x:@.arguments/*/filter
// Returns the result of your last action.
return-nodes:x:@execute/*
Notice, I added the input arguments in addition to the last [return-nodes] statement to provide you with all code required to execute your endpoint. These parts were not automatically added by me selecting my action from my toolbox. Watch the above video to understand this process.
Software development Synergies
This software development process allows experienced software developers to create actions as building blocks, intended for others to consume, creating a "Low-Code and No-Code software development synergy between No-Coders and Experienced Software Developers."
The end result being that the software developer doesn't really create software intended for being consumed by the end customers as much as he or she is creating building blocks intended for management and product development to being consumed by "no-coders".
The software developer is no longer creating software, but rather creates libraries and reusable components (actions)
This allows the software developer to focus on "the hard problems", while managers and project coordinators are focusing on "the customer domain problem". Some like to refer to this as "composables", and I like that word, because it removes the software "creator" from the burdon of having to think about "the how" parts, allowing him or her to exclusively think about "the what parts".
In one of our previous articles we explained how this drastically lowers the bar required to create complex applications. However, by still allowing for custom actions, the ability to create rich and complex domain specific actions results in that arguably nothing is lost in this process. You can still apply any amount of complexity required for the problem at hand, your end result simply doesn't end up being the end solution, but rather a "composable" somebody else can use to implement a solution.
The project manager is in such a world an "orchestrator", and is responsible for creating the end result - While the software developer is an "individual player", and only responsible for creating building blocks the product manager is using in his "orchestration"
In traditional software development the above separation doesn't really exist, because the software developer is responsible for creating the end result. In a dynamic workflow-based software development project, the software developer can focus on what he is good at, while the PM or product owner can focus on what he or she is good at.
Then every time the person responsible for creating the end product (not the software developer) can ask the software developer for a new custom action every time he or she needs a complex task solved, requiring knowledge about "the how" parts. Once the software developer have created this building block, the "orchestrators" responsible for creating the end result, can reuse this same building block in multiple projects.
Combined with Magic's plugins, and its ease of creating such plugins, this allows for a componentized software development experience completely unmatched in the industry. I go partially through the process of creating such plugins in the SQL Studio article - However in later articles I will dive deeper into this aspect of Magic. Until then you can find the complete documentation for Magic below.
Top comments (0)