All posts by Matt Billock

Back to blog home page

AWS Lambda vs. Microsoft Azure Functions

Posted by on Sep 13, 2017

In this article, we compare two function-as-a-service providers: AWS Lambda and Microsoft Azure Functions. We’ll look at the brief history of each, and compare and contrast their features.

Why Work with Multiple FaaS Providers?

One of the crucial components of any application’s reliability plans is what to do when a provider goes down. If AWS is unresponsive, or Google Cloud has a bug, how will your application be affected? Applications that take this into account in their design will often need to rely upon federation of third-party functionality, in order to ensure maximum reliability. When developing Function-as-a-Service apps, the federation options are limited to a small number of providers. As stated, in this post we’ll examine AWS and Azure.

AWS Lambda

AWS Lambda is a Function-as-a-Server serverless code execution platform launched at re:Invent in 2014. Building upon the concepts of containerization, AWS Lambda uses the AWS machine architecture to reduce the scope of containerization, letting you spin up and tear down individual pieces of functionality in your application at will. Functions run on Amazon Machine Instances, which are immutable web server objects that can be instantiated quickly in response to dynamic API requests. By leveraging multiple AWS services and functionality, you can build an entire application without having a true “server-side” set of code to manage.

Microsoft Azure Functions

Microsoft is one of the newer players in the Serverless realm. While they have offered significant Platform-as-a-Service functionality for several years, it wasn’t until March of 2016 that they entered the Serverless App environment with the launch of Microsoft Azure Functions. The addition of these on-demand server-side functions augmented the Azure platform with the ability to run arbitrary code in temporary execution environments.

Supported Platforms and Languages

One of the first items in any evaluation of a serverless provider is what languages are supported. Both AWS Lambda and Microsoft support Node.JS, Python, and C#, for example. However, AWS Lambda provides further support for Python and Java, while Azure Functions provides support for F# and php. Additionally, both run on different execution platforms – AWS Lambda is built of the AMI, which runs on Linux, while Microsoft Azure Functions run in a Windows environment.

Which language you choose is a question of which languages your development team will be productive in, and as such the cross-section of Node.JS, Python, and C# support should meet the needs of the majority web development teams. However, it is important to note that both Amazon and Microsoft are continuing to expand their language support offerings, and this likely won’t cease until all providers are pretty close to language parity. As such, if your chosen vendor doesn’t support your chosen language, then it may not be as drastic of a setback as you’d imagine in a more traditional server-based application. For the purposes of federation of third-party functionality, though, it’s important to pick a language that all platforms in your application’s architecture support, so that you can minimize the work necessary to port the code between different function-as-a-service providers.

Supported Triggers

Both AWS Lambda and Microsoft Azure Functions offer dynamic, configurable triggers that you can use to invoke your functions on their platforms. With AWS, these are sent from other AWS services – you can configure an API trigger using API Gateway, a dynamic trigger on a DynamoDB action, a file-based trigger based on Amazon S3 usage, and so on. With Microsoft Azure Functions, you’re given a similar set of triggers. They allow for access via a web API, as well as invoking the functions based on a schedule. Microsoft also provides triggers from their other services, such as Azure Storage, Azure Event Hubs, and there is even some support for SMS-triggered invocations using Twilio.

There’s no clear winner here, since what is a deal breaker for one application could be a desired trigger feature for another. As such, it’s important to be aware of what options you have available and, when working with federated services, it is doubly important to ensure you can enforce similar patterns of behavior between the disparate platforms. Addressing this problem comes at the design stage, and should be taken into account when building out your application’s architecture.

Other Differences

As with any comparison of offerings between two different companies, there is never going to be complete overlap of functionality and approach. When comparing AWS Lambda to Azure Functions, this is no different. One difference is in the availability of the functions. AWS Lambda spins up a new instance if a function has been inactive for a period of time (usually around 10 minutes). While future calls within that 10-minute inactivity window will use the same instance if they are able, that first call after a long period of inactivity will result in a noticeable delay before the function responds, as AWS needs to spin up a container with the appropriate resources to execute your application. Microsoft Azure Functions, being built on top of Azure Web Jobs, are also subject to this restriction, but due to the underlying architecture this hot/cold divide seems to be less pronounced in the Microsoft ecosystem.

Another difference is in organization. AWS Lambda functions are built as standalone elements, meaning each function is essentially its own independent program. Azure Functions, on the other hand, are grouped together in an application. This allows multiple Azure Functions to share a single set of environment variables, for example, while AWS Lambda functions need to specify their environment variables independently. However, this also affects how application resources are allocated to functions – AWS Lambda provisions memory per-function, while Microsoft Azure provisions memory per application group. Again, there’s no “right” or “wrong” here – just two different approaches to what is essentially the same feature set.


Working in a serverless environment can save your organization effort when compared with a traditional client-server approach, but is not without its own unique reliability quirks. As such, it’s important to have a full understanding of the platform being used to provide your app’s server-side business logic, whether that is a Linux-based platform like AWS Lambda, or a Windows-based suite of services like Microsoft Azure. The beauty of serverless development is that, with minor changes, the code you write for one service should be portable to another with little effort – simply modify some interfaces, handle any input/output transforms, and an AWS Lambda Node.JS function is indistinguishable from a Microsoft Azure Node.JS Function. If your application is dependent upon a specific provider, however, it can pay to tie yourself more deeply into their ecosystem by leveraging service-provided triggers to execute your app’s logic.


Interested in Serverless? Check out Backand. One platform to develop and run complete serverless applications.

Back to blog home page

Serverless Performance Shootout

Posted by on Aug 10, 2017

In this post, I compare the performance of three function-as-a-service providers: AWS Lambda, Google Cloud Functions and Microsoft Azure Functions. I’ll walk through the serverless function providers we examined, the process we used for comparison, and draw some conclusions based on the tests that I ran.

Continue reading

Back to blog home page

How To Call AWS Lambda Functions from Amazon Alexa – Part 2

Posted by on Aug 01, 2017

In Part 1 of this series, we walked through creating a custom Alexa skill that we’ll use to drive Lambda function calls. We also covered the AWS Lambda code that drives this skill, taking a brief look at the Alexa SDK as it is used in one of the Alexa skill blueprints.

In this post, we’ll cover building the intent model for our Lambda function skill, and the UI interaction. Then we’ll use Backand to pull in a list of lambda functions, and implement a vocal UI that can invoke these functions as desired by the user.

Creating Custom Intents

Amazon Alexa is driven based on an intent model. These intents are invoked using specific phrases (which you configure), and then handled with a handler function in the controlling AWS Lambda function for the Alexa skill. To begin creating your own intent, you’ll need to start on the configuration screen for the custom Alexa skill you are building:

From this screen, you can use the provided text box to build out your intent model using the JSON intent schema, but this process can be fragile and, surprisingly, limited in some facets (Dialogs between Alexa and the user, for example, can be challenging to construct in this schema). As an alternative, Amazon offers the Skill Builder tool:

The Skill Builder gives you an easy-to-use GUI on top of the Intent JSON (which is now accessible from the “Code Editor” tab), which makes building intents – and complex intent interactions – more manageable. Simply click on the “Add” button next to “Intents”, and you’ll be able to create your own, custom intents:

From here you can name your intent, then either build a custom intent or repurpose a template that provides common functionality, such as choosing book names or providing details on an actor.

Obtaining a list of Lambda functions

Using the above, we can now create custom intents that are handled by our AWS Lambda handler function. Let’s start by creating an Alexa intent that can fetch a list of functions from a Backand application using the Backand SDK. To begin, we’ll write a new intent in the skill builder – ListFunctions:

This function accepts a simple command – “list lambda functions” – and variations thereof, and is intended to return a human-listenable list of Lambda functions from a Backand application. As such, the next step in our process is obtaining the list of available functions from Backand using the Backand Node.JS SDK. Start by installing the SDK into your Lambda function’s package.json file as follows:

This will make fetching and calling functions easier. Once this is done, we need to import and configure the Backand SDK in the Lambda function’s code. To do so, add these lines near the top of your index.js file in your action:


This configures the Backand SDK to communicate with your Backand application – simply replace BACKAND_APP_NAME and BACKAND_ANONYMOUS_TOKEN with the appropriate values obtained from your Backand application’s dashboard.

Now that we’ve configured the SDK, we’ll add a new handler for the intent we created – ListFunctions:

This handler calls the backand endpoint “1/action/config”, which provides a list of the available actions in your Backand application, and supporting data. We simply take that list of functions, prepend a handy identifier (more on this in the next section), and then use “context.emit” with a “:tell” command to have Alexa provide the list of functions to the user.

Creating a vocal UI for Lambda

You’ll notice that the code for our handler was doing some decoration of the data before returning it to the user. As you work, it is important to keep in mind that the final results output need to be spoken to a user, and as such many of the return values will be more verbose than they would be if they were in a traditional application. You’ll need to make some compromises to accommodate Alexa’s speech patterns, and correct for any ambiguity in pronunciation.

A quick note on language processing


This also poses problems when designing vocal interactions, such as when building a skill that can execute arbitrary functions with arbitrary names. To summarize, Alexa has powerful voice capabilities, but can’t quite get to the level of precision needed to accommodate arbitrary, programming-styled function names. Take, for example, a Lambda function entitled “QARestart5”. Alexa faces several problems when attempting to parse this name:

  • QA can be interpreted as two separate abbreviations (i.e. Q. A.), or as actual words (e.g. “Queue hay”).
  • The number 5 can be presented as either the text “five”, or as the arabic numeral “5”
  • Input received from alexa will try to treat each section of the compound word as a word itself

What this all means is that arbitrary function execution by name – while technically possible – is going to present a challenge. Instead, the above code settled on a different pattern. We assign a unique ID to each function – in this case, just an incrementing integer – and then use that as the discriminator to control invocation of the correct Lambda function.

This approach works for any combination of words that can be easily understood by Alexa. Another example would be combining a color and a city to give each function a random name that has semantic meaning decipherable by Amazon Alexa, such as “Blue Chicago” or “Grey Concord”. Simply choose a domain with sufficient variety to cover your list, develop a repeatable way to generate these descriptors, and you are set to go.

Calling a function by ID

Now that we have the skeleton in place, we simply need to create a new intent – RunFunction – that can invoke any of our arbitrary Lambda functions. To do so, start by creating a new intent in the Amazon Skill Builder, with a slot for Function Number:

The above command creates intent RunFunction, with a slot named “number”. This slot is given a type of AMAZON.NUMBER, and will be turned into an integer representation of the function number spoken by the user. At this point, we simply need to add our new handler:

The above function duplicates some code in the ListFunctions handler, and is due for a refactor, but it should demonstrate the process. We fetch our list of functions from Backand again and, now that we have the list, we simply pick the entry corresponding to the function ID requested by the user. We do some modification of the input data to convert from a one-based system to a zero-based, but aside from that we simply take the number provided to us by the user and use Backand to execute that function.

You can expand this to include setting any parameter values, as well – simply fetch the list of parameters from your function, and design an Alexa dialog for populating those parameters with the correct values. Be careful of working with programming data through this interface, though, as Alexa’s voice recognition – while excellent – still has a long way to go. Once you’ve finalized the interaction, you simply upload the code to your AWS Lambda function handling your Alexa skill, and you’re ready to go!

Expanding functionality

Building an Alexa skill to drive your application’s Lambda functions can greatly increase your devops velocity. Using this technique, you can easily spin up new servers for your application, run simple reports that can return audible feedback, or do any kind of processing that makes sense for voice commands. Simply find a mechanism for classifying your functions with an Alexa-capable identifier, and you’re set to go. We’ve put up a variation of this code on Github – . This uses the techniques here to implement a simple restaurant exploration interface, but can be updated to work with the listing technique with only minor modifications.


With that, you’re ready to accelerate your devops by enabling voice management of your infrastructure. While in many ways a technical demo, this example can be easily expanded into a full suite of devops functionality, giving your engineers yet another way to accomplish their goals as they pertain to running, maintaining, and reporting on your key IT assets. We’d love to hear what you develop using this technique – send us a message with sample code, or questions, or even simply to discuss the underlying concepts – we would love to hear from you!

Back to blog home page

How To Call AWS Lambda Functions from Amazon Alexa – Part 1

Posted by on Jul 19, 2017

By now, most of you are familiar with Alexa, the virtual assistant created by Amazon, and popularized through their line of Echo smart speakers and devices. Alexa gives users the capability to execute actions from a pre-defined set of functionality (called “skills”) using a voice interface. Alexa performs language processing, and converts the spoken words into programmatic action

In this two-part series, we’re going to take a look at leveraging this platform to drive execution of AWS Lambda functions. We’ll cover creating a custom Alexa skill, building intents to drive our skill, and finally modifying those intents to call an item in a list of arbitrary AWS Lambda functions hosted in a Backand application.

Continue reading

Back to blog home page

Incorpoating Backand in a Native Android App

Posted by on Jul 13, 2017

In this article we’ll look at how to connect a native Android application to a Backand back-end using HTTP calls. We’ll cover configuring the connection headers, authenticating with Backand, sending requests, receiving responses and other Backand SDK functionality.

Continue reading

Back to blog home page

Introducing: Lambda Launcher

Posted by on Jul 13, 2017

We’re pleased to announce the release of Lambda Launcher! Lambda Launcher was built by Backand to make it easier and more productive for your organization to use  AWS Lambda functions. We built the Lambda Launcher after experiencing a number of pain points in our usage of AWS Lambda, and wanted to share our knowledge (and the work we’ve done) with the rest of the serverless world.

Lambda Launcher makes using AWS Lambda functions painless, giving you an easy way to share your vital Lambda functionality with the rest of your organization. Sign up for your free Lambda Launcher account today! More details below.

Note to existing Backand users: Lambda Launcher is already built into your Backand account. To get started with it, inside your Backand app, go to Functions & Integrations > Functions > External Functions > select the Lambda Launcher tab.

Why do we need it?

One of the main challenges faced by AWS Lambda developers is how to effectively invoke Lambda functions from within a properly-secured execution context. With the default tools, you’re stuck to either granting every user access to your AWS dashboard, or writing a small web application that individuals looking to run your functions can use as their entry point. Recognizing this, we’ve developed the Lambda Launcher – a free, easy-to-use tool for running Lambda functions.

Own Your Functions

The Lambda Launcher connects to your own AWS account, allowing you to manage the billing while we manage the execution. We use a restricted IAM policy that only needs permissions to read and execute your Lambda functions. When using the Lambda Launcher, you retain full control over both your Lambda Functions and your AWS account as a whole – and you can revoke the Lambda Launcher’s access at any time by simply removing the IAM user.

Easily Import, Run, and Debug

The Lambda Launcher gives you an easy-to-use interface to run your Lambda functions from outside the AWS console. You’re provided with the capacity to save and configure parameters, an easy button to use when triggering your Lambda functions, and a log of the recent function runs performed. This web interface saves you the trouble of having to write your own, and also gives you an alternative to simply adding more users to your AWS account.

Control Function Security

As the Lambda Launcher is built on top of Backand, you also get a full application security suite with the Launcher. You can restrict access to functions by user, managing precisely who has access to your business’ vital Lambda functions. You can use the built-in robust user authentication schema that is built on the OAuth 2 standard, or use custom security actions to tie your function security into the rest of your organization’s access control mechanisms.

We hope you enjoy the Lambda Launcher and would love to hear your feedback! How can we improve it? How do you use it?

Back to blog home page

Why Go Serverless?

Posted by on Jun 14, 2017

Most of the talk about serverless these days focuses on how to integrate with a function-as-a-service provider, how to orchestrate your calls, tools for troubleshooting in a serverless world, and so on. However, not much of it is focused on the most important question behind choosing serverless architectures over a more traditional approach: why?

In this post, we’ll present a few different reasons to choose a serverless architecture over a more traditional client-server approach, or even over a containerized approach such as Docker.

Continue reading

Back to blog home page

The Pros and Cons of AWS Lambda

Posted by on May 31, 2017

AWS Lambda revolutionized the serverless application landscape. Before, serverless implementations were limited to choosing a cloud provider for your application’s back-end functionality. With Lambda, Amazon pioneered a new development paradigm – Function-as-a-Service. In this post, we’ll give a brief overview of AWS Lambda, and then discuss advantages and disadvantages of using the service.

Continue reading

Back to blog home page

From Zero to Serverless With Backand, Part 1

Posted by on May 30, 2017

This post is the first in a series in which we’ll walk through creating a serverless app using AWS Lambda and Backand. This post will cover serverless app architecture, the project we’ll be building, and what Backand has to offer.

Why Serverless?

Traditional web apps give you a lot of flexibility but have high costs. From hosting, to maintenance, to security, maintaining your own server for your application can be expensive and time-consuming. It is also highly technical work that requires an expensive DevOps organization to manage effectively.

Serverless architectures save much of this time-consuming and expensive work.

What is a Serverless App?

While serverless architectures have been around in some form or another for several years, it was the launch of AWS Lambda at re:Invent 2014 that truly kicked off the trend – and the buzzword.

Serverless applications are not truly serverless, but rather outsource the provisioning and hosting of an application’s functionality to a third-party provider. This manifests as a number of different patterns: from dynamically launching Docker containers with your app in an on-demand fashion, to deploying only single functions that have their output combined together by a client-side app that serves more like a service orchestrator than a traditional web application.

The two predominant paradigms in serverless app development are single-provider serverless apps and Function-as-a-Service (FaaS) serverless apps. A single-provider serverless app simply replaces the server in a traditional client-server application with a third-party API. The developer in this application uses administrative tools with the third party to construct their data model, manage their app’s business logic, and secure their application. Much of the traditional server-side logic is moved to the front-end code, or emulated via features like server-side code execution.

Function-as-a-Service serverless apps take this a step farther. Instead of working with a single monolithic backend provider, the app is broken into individual functional areas. These functions are then uploaded to a service like AWS Lambda, and called via triggers – the most common being AWS API Gateway. The provider handles the challenges of making this code always-available, scaling the code in response to demand, and securing the execution and operation environment. While this preserves the server-side component in a more understandable and controllable fashion than a sole-provider serverless app, it requires a lot of error handling and service orchestration code to be implemented on the client side, bloating the client app size.

Serverless Tech Architecture

The summary graphic above highlights the primary differences between the three approaches. It’s important to note that this list of web application architectures is not exhaustive. Translating other architectures to a serverless pattern might require some work to ensure all functionality is covered and will vary in complexity based on the underlying app.

In the rest of this series, we will focus on sole-provider serverless, but it’s important to note that the two serverless patterns are not mutually exclusive. You can use a single-provider architecture with a Function-as-a-Service app, for example, or you can mix-and-match patterns by incorporating other third-party providers to supplement functionality in your application.

So, What are We Building?

In this tutorial, we’ll build a simple ToDo list application. We’ll implement an interface that allows a user to log-in, manage their to-do items, then log out. We’ll take an iterative approach, starting with the most basic code that we can to accomplish the task. In fact, some articles in the series, like this one, won’t require any coding at all. That’s the power of a serverless development platform. We’ll be using Backand to provide the server-side functionality, but the same concepts can be applied to any serverless platform.

What is Backand?

Backand is a powerful serverless development, deployment, and hosting platform. Backand replaces the server and database in a web application, allowing developers to focus on their front-end code. By leaving the headaches of the server to Backand, development teams are free to focus on application functionality without having to be distracted by deployment and configuration tasks.

Backand also allows you to bring a pre-existing SQL database. It uses SQL reflection to analyze the DB structure and dynamically build a REST API around it. Backand also provides several tools that address the shortcomings in Function-as-a-Service serverless applications, such as simple deployment and debugging of AWS Lambda functions. Using these tools, developers can focus on their application’s look, feel, and behavior – leaving the security, scaling, and configuration aside.

Step 1: Creating a Backand Application

The first step of creating a serverless application is to register and create an app. With Backand, it’s as easy as 1-2-3:

1 – Register for a free account at
2 – Create your application by giving it a name, a description, and then hitting the “create” button.
3 – There is no step 3! Your application is ready to go with a basic data model.

As this tutorial will stay somewhat superficial, we won’t need to make any changes to the application we create at first. The default data model for every Backand application consists of two objects: items, and users. We’ll use these to implement a basic to-do list, and modify the schema as we move forward.

Next Steps

Now that we’ve reviewed serverless architectures and created a Backand application, we’re ready to start coding! The next post in this series will cover designing a UI, and connecting the client-side code to Backand to retrieve a list of items. Posts that follow will then cover CRUD functionality, user authentication, and more. By the completion of this series you’ll have both a healthy understanding of serverless development, and a sample application to add to your portfolio. Tune in to our next post for more details or, if you’re impatient, hit the docs at to get started on your own.

Note: This Article was first published on

Back to blog home page

Integrate Your Backand App with SalesforceIQ

Posted by on May 10, 2017

Building and maintaining customer relationships is crucial for driving sales to your platform. However, it can also be a complex process requiring integrating data from multiple sources and, more importantly, ensuring that data is accessible when it is needed. In our last post we examined Integrating with Salesforce CRM. In this article, we’ll look at integrating a Backand application with the popular SalesforceIQ platform, providing you with all of the tools you need to effectively leverage your customer data in your Backand application.

What is SalesforceIQ?

SalesforceIQ is an out-of-the-box CRM solution that quickly gives you access to dynamic information tied into a full CRM solution. With Automatic Data Capture and enterprise-level intelligence under the hood, SalesforceIQ acts like your own personal assistant so you can focus on what matters most: selling. SalesforceIQ, in addition to providing easy integrations with tools like Google and Microsoft Exchange, also gives you the capability to dynamically access and manage your data through a series of robust APIs.

Use Cases for Custom Integrations

SalesforceIQ is a powerful tool, but that power needs to be available to your developers and sales organization if it is going to be useful. While SalesforceIQ offers some mobile functionality, performing deeper integrations with your organization’s data will require some development work to effectively leverage your leads. Below are a few sample use-cases that can be executed while using Backand to drive an integration with SalesforceIQ:

  • You can use real-time communications to push notifications to your sales people via your mobile app
  • You can integrate SalesforceIQ with other internal systems, like HR, Ops, or internal tracking and monitoring
  • You can use SalesforceIQ with a custom database, to increase productivity by easily consolidating all of your relevant customer data into a single location
  • You can integrate SalesforceIQ with customer-facing applications, collecting and updating data from sales leads in real time

Connecting a Backand application to SalesforceIQ

Integrating Backand and SalesforceIQ is as simple as leveraging the full-featured API provided by Salesforce from within your Backand application. While traditionally you’d need to make these calls to the API from a server, you can achieve the same functionality in Backand by using our custom template action. This action provides an easy-to-use code template for making calls to the SalesforceIQ API, letting you update your user tracking data based upon user activity in your Backand app, or even update your Backand app’s UI based on what you know about your user in SalesforceIQ.

Working with the SalesforceIQ API provides you with full capabilities to create, retrieve, and update data on your users, as well as manage their information in SalesforceIQ. Communicating with their API is as simple as translating the cURL commands provided by Salesforce in their documentation into the appropriate $http calls that you can make from JavaScript. Simply provide the required authentication and identification headers, construct the URL, make the call, and handle the response when it arrives, dispatching it either directly to your application via a synchronous function call return, or emitting the data as an event using our Socket-based real-time communications functionality.

The Salesforce Action Template

We have created an action template that will give you jump start with SalesforceIQ. You can either trigger this action from an object’s database transaction event actions or create a new on-demand action that you can call from your app’s client code. The following JavaScript is provided by the template action, which is available as “SalesforceIQ” in the “CRM & ERP” section of action templates.

This code provides you with all of the basic tools you need to get connected to the SalesforceIQ API. It takes in your SalesforceIQ API Key and API Secret, and performs a call to the “/accounts” endpoint to fetch accounts.

Connecting to your SalesforceIQ account

To connect to SalesforceIQ, you’ll first need to register for an account if you haven’t done so. Once you’ve signed up, follow these steps to obtain your API Key and API Secret:

1. Open Settings under the gear icon
2. Open the ‘Integration’ tab under ‘My Account Settings’
3. Under ‘Create New Custom Integration,’ click ‘Custom’
4. Set the name to ‘Backand API,’ and provide a description
5. Copy the ‘API Key’ and ‘API Secret’ from the integration page into the JavaScript Action code
6. Click ‘Save’

When this is completed, you should now be able to access all of your SalesforceIQ accounts from the custom JavaScript action.

Setup client-side code

Once you’ve configured the action to connect to SalesforceIQ, you’ll need to call the action from your client-side code. To do so, use the following JavaScript to construct a GET request and trigger your SalesforceIQ action:

Simply replace ‘your object name’ with the object that contains your SalesforceIQ custom action, and replace ‘your action name’ with the name of the action that you provided while creating the integration.

With these changes, you’re now able to pull in any and all SalesforceIQ accounts available via their API! You can use a similar pattern to construct additional calls to the SalesforceIQ API – simply replace the URL and parameters in the custom SalesforceIQ action with the URL and parameters for the object you want to retrieve.

Adapting for AWS Lambda

For operations that have significant security concerns, or that represent complex business logic centered around an integration with Salesforce, it may benefit you to implement your Salesforce CRM integration as an AWS Lambda function using Backand’s Node.JS AWS Lambda server-side functions. You can even use most of the code we’ve already supplied, we simply need to modify the method we use to send HTTP requests to Salesforce to use a method compatible with Node.JS. Node implements HTTP communications using the ‘http’ module, which will need to be included. Once the module is ready, converting the code above is very straightforward. Take the HTTP request lines, provided below:

And replace these lines with the Node.JS equivalent:

You’ll need to provide a callback function that handles the response data. As the format of this function will depend heavily on your app’s data, we’ve left this blank in this post.


CRM software is only useful if it can be aware of activity on all of your organization’s customer touchpoints. By integrating your Backand app with Salesforce IQ, you can now incorporate your in-house and public web and mobile applications with the Salesforce IQ API, providing you valuable data on customer actions and behavior, while giving you more tools to gauge the success of your outreach efforts. You’re now free to truly customize your sales funnel and marketing efforts to take advantage of actual user behavior within your Backand-powered applications.