Exploring the AWS Lambda Template
Gradle
We’ve looked at packaging our BoxLang project to upload to AWS. Once it’s there, it’s compiled down to Java bytecode and we can see our project. Gradle is the build tool which is built into the template and does the “packaging” so let’s look at how that takes place.
The build process takes any files needed for your project and bundles them into a .zip or a .jar. For those of us who don’t have extensive experience which Java, a .jar file is essentially a sophisticated .zip with a few more settings and files which cater specifically to Java. Both serve the purpose of being able to move projects around as a single entity vs individual files.
The settings.gradle file is where you can set the name of your project. This is primarily to determine the filename of the zip and jar files created by the build process. The gradle.properties file is where the project version can be set with the version property. This is also built into the name of the zip and jar files. Neither of these settings directly impact your BoxLang project on AWS Lambda but can help keep things more organized locally.
Lambda.bx
By default, hitting the function’s URI will execute the “run” function in the Lambda.bx file. That function accepts three arguments:
- event: The event struct/map that triggered the Lambda
- context: The AWS Lambda context object that adheres to com.amazonaws.services.lambda.runtime.Context
- response: The response object that will be returned to the caller which always has a standard structure:
- statusCode: The HTTP status code, 200 default
- headers: The HTTP headers map/struct
- body: The response body, or empty. This is for you to add your response data as you see fit.
- cookies: An array of incoming cookies (if any)
- Any other property you add will be returned as well
This response object is simply a BoxLang structure which is serialized before being returned so it can include any keys or data you desire but these keys can help things stay standardized.
At first glance, that would seem to limit the usefulness of the project by only having one entry point. However, the Lambda template does have a level of routing built in. If you’ve ever used Coldbox, Ortus’ HMVC framework, you’ll recognize the following design patterns but, just in case, let’s lay out a few concepts.
Routes, Handlers, Models
Every URI consists of a protocol, a domain, a path and a verb. For example, https://boxlang.ortusbooks.com/getting-started/running-boxlang/aws-lambda breaks down into:
Protocol: https
Domain: boxlang.ortusbooks.com
Path: getting-started/running-boxlang/aws-lambda
Verb: From a browser, the default is GET. Other scenarios include POST, PUT, PATCH, DELETE, OPTIONS and others.
A router parses that URI and determines what file or chunk of code to execute. That code which is then executed is typically called a Handler.
Handlers perform some routine housekeeping that might or might not include the main purpose of the call. This can include authentication and authorization, validating and sanitizing the data being submitted or other actions which need to be performed before the “main event”. After this is completed, the request is passed on to a Model.
Models are typically where the bulk of the work and reusable code exists. This is purposely and expressly separated from the activities in the handler for many reasons. For example, a model might be called internally by other models whose data has already gone through the preliminary processing and does not need it repeated. We’ll start looking at models in Part 3 of this series.
Exploring Simple Routing
The Lambda Template has a certain level of routing built in. To explore this, let’s return to the project we started in part 1.
We want to expand our project to include the paths
- /login
- /profile
- /prachettBooks
- /louis_dreyfus
For each of these endpoints we need to create a corresponding handler in the src/main/bx folder alongside Lambda.bx. The routing process converts the path into PascalCase so these files would be
- /Login.bx
- /Profile.bx
- /Pratchettbooks.bx
- /LouisDreyfus
Each of these would need a method called “run” which accepts the same arguments as the run method in Lambda.bx – event, context, response.
Here is a sample of what Profile.bx might look like:
class {
function run(event, context, response) {
response.body = {
"error": false,
"messages": [" You have a wonderful profile! "],
"data": "====> Incoming event " & event.toString()
}
response.statusCode = 200
}
}
Since this is a somewhat biggish jump from our previous example, open up gradle.properties, bump the patch version ( maybe to 1.0.1? ), open up a terminal to your project folder and type gradle build to regenerate the distribution zip and jar.
Once you’ve done that, go to your function in the Lambda console and upload either the zip or the jar. After it uploads and the function is finished building, try those corresponding URIs and make sure they work. Because the paths are converted to PascalCase, the capitalization on your files makes a difference. In my above example, the file name Pratchettbooks.bx worked but PratchettBooks.bx does not and reverts to calling the default Lambda.bx.
If you missed part one you can see the article here: Breaking the CFML Barrier: Going Serverless on AWS Lambda with BoxLang — by Dan Card
Join the BoxLang Community! ⚡️
Stay connected with the latest updates, BoxLang announcements, Into the Box 2026 news, tutorials, tools, and more.
Subscribe to our newsletter for exclusive updates and early access.
Add Your Comment