FaaS V2: Key Differences and Limitations

This document outlines the major changes, improvements, and limitations in the new version of LivePerson's Functions-as-a-Service platform compared to the FaaS V1 version. Understanding these changes is crucial for a smooth migration and development experience.

1. Code Execution and Development

1.1. Function Handler: `async/await` vs. Callbacks

The function signature has been simplified. You no longer need to use callbacks. Instead, you can use async/await and return values directly.

Old Way (V1):

async function lambda(input, callback) {
  // Process request
  callback(null, response);
}

New Way (V2):

async function lambda(input) {
  // Process request
  return response;
}

Benefit: Cleaner code, easier error handling, and native async/await support.

1.2. Modules: ESM (`import/export`) vs. CommonJS (`require`)

The standard FaaS V2 runtime uses ES Modules (ESM) for dependency management. This means you should use import and export statements instead of require.

Old Way (V1):

const { Toolbelt } = require("lp-faas-toolbelt");

New Way (V2):

import { Toolbelt } from "core-functions-toolbelt";

Note: Only ESM-supported dependencies are compatible with the standard FaaS V2 runtime.

1.3. HTTP Requests: Native `fetch` vs. `httpClient`

The lp-faas-toolbelt's httpClient is deprecated. The standard FaaS V2 runtime provides the standard fetch API for making HTTP requests. You can learn more about the fetch API in the mdn web docs.

The LP Client now also uses fetch for the HTTP communication and no longer the HTTP Client.

Old Way (V1):

const httpClient = Toolbelt.HTTPClient();
const result = await httpClient(url, {
    method: "POST"
    json: true
    body: {
        "important-data": 123
    }
});

New Way (V2):

// fetch is globally available
const response = await fetch(url, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Accept: "application/json",
  },
  body: JSON.stringify({ "important-data": 123 }),
});

const result = await response.json();

1.4. Breaking behaviour for users of `json: true` in HTTP Client and LP Client

The previously library that was used for implementing the HTTP Client, which also was used for the LP Client. Performed following things implicit when using json: true:

Automatically used JSON.stingify(…) for the sent body
Automatically set the Content-Type header to application/json
Automatically parsed the received JSON object

Due to the switch to using the native fetch, this means you will now need to explicit do the following things in your HTTP calls or LPClient calls.

Use JSON.stringify(…) to serialize the body of a request
Set the header { 'Content-Type': 'application/json' }
Parse the received body using response.json()

// fetch is globally available
const response = await fetch(url, {
  method: "POST",
  headers: { 'Content-Type': 'application/json' }, // This was previously automatically set 
  body: JSON.stringify({ "important-data": 123 }), // This was previously performed implicitly
});

const result = await response.json(); // This was previously performed implicitly

const response = await lpClient(
  LpServices.MSG_HIST,
  `/messaging_history/api/account/${accountId}/agent-view/status`,
  {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' }, // This was previously automatically set 
    body: JSON.stringify({ skillIds: [skillId] }) // This was previously performed implicitly
  }
);

const result = await response.json(); // This was previously performed implicitly

1.5. Domain Resolution: `csdsClient` for Dynamic Service Discovery

Instead of hardcoding service domains, you should now use the csdsClient from the core-functions-toolbelt to dynamically resolve them. This makes your functions more resilient to changes in the underlying infrastructure.

Old Way (V1):

const url = "https://lo.agentvep.liveperson.net/api/...";

New Way (V2):

const csdsClient = Toolbelt.CsdsClient();
const domain = await csdsClient.get("agentVep");
const url = `https://${domain}/api/...`;

1.6. Deprecated `CRMClient`

The CRMClient from the core-functions-toolbelt is now deprecated. Developers should instead use the pre-installed jsforce library directly to interact with Salesforce. The toolbelt provides a ConnectToSalesforce factory function that returns a vanilla jsforce instance in FaaS V2 which will be removed in the future.

1.7. Debugging Capabilities

Old:
- In-Browser debugger support
- Ability to step through code on the platform
New:
- No built-in debugger
- Focus on local development and testing
- Enhanced logging and monitoring

2. Platform Architecture and Performance

2.1. Scaling Model

Old:
- Request-based scaling (requests per second)
- Fixed scaling thresholds
- Manual scaling configuration
New:
- Dynamic performance optimization
- Automatic resource allocation
- Intelligent scaling based on multiple factors

2.2. Networking

Direct Network Access: The new platform provides direct network access, removing the restrictions of the FaaS V1 Proxy. This offers more flexibility for external integrations and better performance.
IP Ranges: The IP ranges for FaaS V2 will not differ from the published IP range from LivePerson.

Due to the removal of the Proxy there is no longer need for allowlisting accessed resources. Meaning there is also no longer an UI to manage an allowlist.

3. Configuration and Limits

3.1. Secret Management

The new FaaS V2 platform leverages a new Secret Manager, which introduces specific limitations and behaviors:

Size and Quota Limits:
- Secret Payload Size: The maximum size of a secret's payload is 16KB.
- API Rate Limits:
  - Access Requests: 90,000 per minute per account.
  - Read Requests: 600 per minute per account.
  - Write Requests: 600 per minute per account.
Automatic Caching and Data Consistency:
- To improve performance, the SecretClient automatically caches secrets in-memory. By default, secrets are cached for 5 minutes.
- It is crucial to understand that this cache is local to each running instance of your function. In high-load scenarios, the platform's autoscaler may create multiple instances of your function. These instances do not share a cache.
- If one instance updates a secret, other instances will continue to use their old, cached value until their local cache expires. This can lead to data inconsistency across different invocations of your function.
- If your use case requires strict data consistency (i.e., you need to ensure that every invocation of your function immediately receives the most up-to-date secret value), you must bypass the cache by using the { useCache: false } option in your readSecret call.
Naming Conventions:
- User-defined secrets cannot start with the prefix LIVEPERSON_DEFAULT_. This prefix is reserved for system secrets.
Unavailable System Secrets:
- The on-premise system secrets lp-faas-default-app-key and lp-faas-orchestrator-app-key are not migrated to FaaS V2 and are unavailable, even in compatibility mode. Functions relying on these secrets require manual intervention to use a new secret created in FaaS V2.

For more details on handling the transition from OAuth 1.0 to OAuth 2.0 (cut-off date: March 31st, 2026), please see the Migrating to OAuth 2.0 for LivePerson APIs guide.

Automatic Key Provisioning with LpClient

The note above about the lp-faas-default-app-key applies mainly to functions that manually retrieve and use this key. If your function uses the LpClient from the core-functions-toolbelt, the platform will automatically provision and manage a new, more secure authentication key for you. No manual intervention is required in this case.

3.2. Environment Variables

Environment variables are a key part of function configuration. Please be aware of the following limitations:

Reserved Prefixes and Names:
- The prefix X_LIVEPERSON_ is reserved for our platform's internal use.
  - The following variables have been renamed in FaaS V2 and need to be updated accordingly
    
    BRAND_ID is now called X_LIVEPERSON_BRAND_ID
    
    LAMBDA_UUID is now called X_LIVEPERSON_FUNCTION_UUID
    
    CSDS_DOMAIN is now called X_LIVEPERSON_CSDS_DOMAIN
- The prefix X_GOOGLE_ is reserved by our cloud provider.
- The following environment variables are set automatically and cannot be overridden: PORT, FUNCTION_TARGET, FUNCTION_SIGNATURE_TYPE.
Size and Number Limits:
- You can define a maximum of 1000 environment variables.
- The maximum length for an environment variable's value is 32 KB.
Portability:
- To ensure portability across different operating systems (especially when debugging locally), it is recommended to only use letters, numbers, and underscores (_) in your environment variable names.

4. Migration Considerations

When migrating from V1 to V2, you will need to:

Code Updates:
- Update function handlers to use async/await and return values.
- Implement proper error handling with try/catch blocks.
- Check for updated libraries and APIs
- Use the new environment variables
- Add comprehensive logging for debugging purposes.
- Test network connectivity for any external services your function communicates with.
Development Workflow Changes:
- Set up a local development environment for testing.
- Rely on the enhanced logging and monitoring capabilities for debugging, as there is no built-in debugger in the new platform.
Performance Optimization:
- Review the new dynamic scaling behavior.
- Optimize network calls.

5. Event Sources

5.1. Chat Events

In FaaS V2, "Chat events" are no longer available as an event source. This primarily affects the "Chat Post Survey" event.

6. Limitations

6.1. Logging

There are strict limitations on logging:

You can have a maximum of 10 logs per invocation.
The total size of all logs per invocation cannot exceed 16384 characters.

Any logs written beyond this limit will be lost.

6.2. Deployment Versioning

The platform stores only the last five deployments of a function, limiting rollbacks to these most recent versions. However, the V1 compatibility version remains permanently available.

6.3. Email Reporting

The email reporting feature that was available in FaaS V1 is no longer available in FaaS V2. This feature, which you can read about on the V1 Monitoring page, allowed for daily or weekly email reports about function performance.

An interim solution is available until the official integration with the Reporting Center is complete. If you wish to leverage this interim solution, please engage with your TAM (Technical Account Manager) ahead of time. This is particularly important if your migration has not yet occurred.

Faster Better answers through AI

Key Differences