Lambdas seem to have multiple definitions depending on who you ask... anonymous functions, serverless functions, a snippet of code, etc. The most important takeaway is that it is a way to do business logic in a lightweight manner and return a result using a programming language.
Serverless computing is a concept (and buzzword) where code can be executed by some other service. This allows you to not have to worry about maintaining your own server. From your point of view it may feel like it is serverless, but there is still a server somewhere processing the Lambda code and returning a result. Xano's implementation of Lambdas are processed on their own servers. Since Xano maintains its own servers and you are supplying the code to be processed, one could make the case that Xano's Lambdas are serverless. There is still a bit more nuance to consider, when comparing different serverless solutions to each other, but the main benefit of Xano's implementation is that it is all contained within Xano, which means any Xano customer can get started using it right away.
Yes, Xano is 100% the No Code backend. More importantly, it is a Turing-complete backend, which means it can do anything a programming language can do through variables, conditionals, and loops.
The Lambda feature is a bit taboo, since technically it means that by allowing it to exist, one could argue that Xano has become a Low Code solution. We have thought long and hard on this topic and we strongly believe that the power of Xano increases with this Lambda functionality and we are letting our users decide if they want to use it or not.
For No Code purists, Xano will remain the No Code backend. For Low Code advocates, Xano will have offerings such as Lambda support. Regardless what you choose, Xano will always remain true to its roots and remain a No Code first solution.
Lambdas have the ability to reference all the available data just like normal function stack statements. All special variables are prefixed with a
- Xano variables are accessible through the
$varspecial variable. To access a Xano variable named title, you would reference it as
- Xano inputs are accessible through the
$inputspecial variable. To access a Xano input named score, you would reference it as
- Xano environment variables are accessible through the
$envspecial variable. To access a Xano environment variable named ip, you would reference it as
- The authenticated user details are accessible through the
$authspecial variable. The most common members of this variable include
$auth.extras. If there is no authenticated user, then
$auth.idwill evaluate as 0.
Depending on how you use a Lambda, you may have support to access some additional variables, known as context variables. These follow the same naming convention as special variables by using a
$prefix. The most common context variables will be
$result. The meaning of these variables are best described within the examples of the higher order filters.
Please note that there is a 16MB total transfer limit between the function stack and Lambdas. If the data being passed through a Lambda exceeds this, it will be necessary to reduce the data set size, even by something as simple as clearing out the contents of other variables.
Xano supports Lambdas as a function stack statement, a filter, and as an argument to higher-order functions.
Add a Lambda function to the function stack,
This is the most basic use of Lambda support. It is used within the function stack and has access to all inputs, environment variables, and the current state of variables just like all function stack statements have. The purpose of this version of Lambda is to reference the required data that is accessible to it, perform some type of transformation, and then return a result, which is then stored within the name of the variable specified within this statement.
Lambda functions are inserted in the function stack and can interact with inputs and variables.
Here is an example of a function stack where there is an input named multiplier and a variable named amount. We use the function stack version of our Lambda support to multiply the two together and then return it as a new variable named answer.
return $input.multiplier * $var.amount;
Lambda can also be executed as a filter.
This version of our Lambda support has one major difference between the function stack statement equivalent. The context of the expression prior to the filter is available through a context variable named
$this. This allows you to perform Lambdas in a very light weight manner as well as have the ability to chain multiple Lambdas together through the filter stack.
Using the same example as above we can reproduce this applying a Lambda filter on the amount variable, which then lets us access it through the
Lambda filter using the $this variable to represent the variable where the filter is applied.
return $input.multiplier * $this;
The console.log statement is supported in Xano's Lambda functions. When you use console.log in your Lambda function's code, the output is returned in the Debug Log tab of the debugger.
These logs will only be viewable when using Run & Debug and are not present in the Request History when external requests are made. To navigate around this, you can copy the input from the request history and re-run the statement via Run & Debug, or store the log data in tables for later review.
These types of filters are very powerful because they perform some type of operation (most commonly on an array of values) and use a Lambda as the input of the higher order function. In the array use case the Lambda would be processed on each element of the array and each processing of the Lambda would have access to context variables that are applicable to each filter.
Please note there is a 16MB data transfer limit between Lambdas and the rest of your function stack.