Generating Lambda Functions via Visual, Block-Based Coding: Visual Lambdas

[svenhaiges]

In this blog post, I’ll outline some practical research that we’ve done around Low Code development. More specifically, I’ll be introducing visual coding via a Blockly-based editor for generating and deploying JavaScript-based Lambda functions to a Kyma Kubernetes cluster – we call it Visual Lambdas. While it still needs to be validated if a block-based programming language can be used effectively for specific Customer Experience use cases, the initial results are quite promising.

We’re on a journey and need your input – please get in touch via Twitter or simply leave a comment below.

If you have no clue what No Code/Low Code Development is all about, I’d recommend to initially read my first blog post which defines both No Code and Low Code and as well outlines the first part of our research in which we’ve integrated the very popular Node-RED flow-based / low code development environment with Kyma.

Code or Configuration?

Before we’ll embark on our journey to Visual Coding, I’d like to quickly put Visual Coding on the map to help you understand the bigger picture.

For our research, we’ve initially focused on tools such as Node-RED, Flogo or N8N which generate configuration (shameless plug: we have a Labs Talk podcast episode coming up with exactly this topic). For example, you’d create a flow in Node-RED, which results in a JSON document that describes all nodes and their linkages. Once you’ve activated (“deployed”) the flow, it will be read by the Node-RED runtime which then executes the logic as new requests to exposed endpoints are received.

An alternative to this approach is to not generate configuration, but to generate code. Here, the visual representation of your program is directly translated to code, written in a programming language such as JavaScript. While of course you need a Javascript engine/runtime to run the code, no extra runtime library for the low code framework that was used is required.

As the extra runtime to interpret the low-code configuration (e.g. the Node-RED runtime on top of the Node.js runtime) is not required for the code generation approach, the Docker images that are either pre-created or built dynamically via a CI/CD systems will be smaller. Whether this, of course, is a significant difference and a relevant benefit needs to be seen.

Visual Coding… aka Blockly

If you look into visual coding / visual programming you’ll likely discover the Blockly project very soon. While there are tons of other examples, I am sure that Blockly is the most prominent example for a block-based programming language. Originally developed by Neil Fraser at Google, the open source Blockly project is the basis for many edtech tools out there that are used to teach the basics of coding. The blockly project and it’s concepts, integrated into specific tools, is used for generating code for physical computing devices (see BBC micro:bit), can be used to create 3D printable models (see BlocksCAD3d) or “just simply” generates code for web-based story telling as seen in Scratch.

The classic Blockly demo, screenshot from the Blockly homepage.

In this interview from 2015, Neil explains that there are essentially two barriers that novice coders need to overcome: syntax and logic.

To overcome logic barrier, students need to get used to the concepts of conditional logic, loops, etc. – which for young children might be new concepts but I’d like to make the point that most adults, even non-developers, possess logical thinking skills. It’s a requirement for most jobs by now and what’s left for most adults out there is to associate the idea of “repeating something” with the “loop” block in Blockly. Really not rocket science. Checked.

The syntax barrier, and that’s now the interesting part, can be solved entirely via a visual coding tool: the code generated via Blockly will be syntactically correct. And it is quite remarkable and definitely worth noting, that tools such as Blockly can generate code in many programming languages – you just need to switch the generator functions.

Yet, overcoming both barriers, e.g. the syntax barrier via a tool such as Blockly and the logical barrier by logical thinking and training in visual coding, is no guarantee for a working program, or in our specific research, a working lambda function. I would like to add a third barrier to the existing two, which is a context-specific barrier such as requiring knowledge about HTTP requests and responses when it comes to Lambda functions. Let’s call this barrier the domain knowledge barrier.

Here’s an example:

If you’re using a Blockly-based tool to create 3D shapes for 3D printing, you need to know that an additive 3D printer (that builds a shape bottom up) is very often unable to print at an angle steeper than 45 degrees. Also, while objects in your rendered preview of a 3D shape might show up in different colors to be able to tell them visually apart, it depends on the 3D printer if it is able to print in more than one color or filament. These are just two examples of domain-specific knowledge. Not having a a clue about 3D printing (the domain knowledge) and using a Block-based 3D modelling tool does not guarantee a successful print.

So let’s remember that we need logical thinking and domain knowledge for using a Block-based tool. Let’s enter Visual Lambdas.

Block-Based Programming for Visual Lambdas

Our current research is focused on using a Block-Based programming language such as Blockly for generating Lambda functions.

This is how it looks:

The visual code example above defines a lambda function, which will request and return the weather for three cities. At this point we’re still looking for a good use case in the CX space, some ideas presented below.

It’s quite interesting to look at the generated code, which is this:

var cities, weatherList, j;

const fetch = require("node-fetch");



module.exports = {

    main: async function(event, context) {

        cities = (event.extensions.request.query['city']).split(',');

        weatherList = [];

        for (var j_index in cities) {

            j = cities[j_index];

            weatherList.push((await fetch("http://api.openweathermap.org/data/2.5/weather?q=" + j + "&appid=XXX").then(res => res.json())));

        }

        return weatherList;



    }

}

Even experienced developers would have to look up the exact nesting of the request parameter used for accessing the query parameter city. It’s definitely not rocket science, but very annoying and boring. When it comes to the call to the Weather API, a very simple REST call, they would need to look into the documentation of that API to find out the correct endpoint URL. And before doing that, they would probably need to decide which of the many REST libraries that are available for Node.js to use.

Novice developers or even technical business users would be stuck, close the browser, do something else. Mission failed. Right?

Who’s the target audience of such a tool?

A Visual Coding tool for Visual Lambda creation therefore is potentially beneficial for

• technical business users (business users which got trained specifically for this domain, e.g. Lambda functions)


• and developers (who, while knowing about code syntax, also need to look up specifics like endpoint URLs of services, usage of HTTP libraries, etc)

What can this potentially be used for?

At this point in time, we believe that the aforementioned users could potentially be able to

• either create new functionality or extend the functionality of enterprise software, such as the SAP Commerce Cloud


• and/or be able to modify existing, default behaviour.

The way I personally would like to see visual coding being used within Kyma and in the context of Lambda functions is as a gateway drug. While not being a perfectly legal metaphor, I think visual coding has the potential to be a user’s first and positive interaction with the Kyma Lambda system. It must be easy and playful to use. The goal here is not to be able to do anything – the goal is to get started and have a positive experience that will make you hungry for more. While some users (technical business users) will stay in the field of modifying some extension points of our enterprise software for just a little, some other users (more technical users, developers) will at some point advance to text/code-based programming of Lambda functions.

It’s so much more fun to see this in a video. Here’s the current state and a basic introduction to this Visual Lambda tool:

https://youtu.be/8d7U_VOMdXA

 

Block-Based Visual Coding using Blockly for Lambda Generation and Deployment to a Kyma Kubernetes Cluster

Shortly after I had created the first video, I had another idea for a more complex example, which shows the use of programming concepts such as lists and loops:

https://youtu.be/ZKBVVAw8Kgo

A slightly more complex example, I am pulling the weather for a list of cities and return in in a Lambda function. I am finally also making this a bit more dynamic by usiing a Query Parameter.

Zoom out, please!

We’ve now explored configuration-based low-code development and also code generation for low-code development. While we’re just scratching the surface in both areas, we could imagine to unite both concepts for a larger, more comprehensive low code architecture. This might involve scalable, visually coded lambda functions at the bottom and then a visual orchestration layer for these lambda functions, which allows them to be chained and sequenced (the mechanism for this chaining mist likely being events, we love Kyma for this!). This is work (and thinking) in progress and we’d love to hear your thoughts – tweet or comment below!