App functions
App functions represent an app's backend. They're built, bundled, and deployed together with your Dynatrace app. The Dynatrace App Toolkit makes developing and deploying app functions easy.
Every TypeScript file in your project's /api directory is automatically deployed as an app function and exposed as an API endpoint.
Currently, you can deploy functions built with JavaScript/TypeScript, which run within the Dynatrace JavaScript runtime. To see the list of supported APIs, visit Web APIs
Use cases
When does it make sense to use app functions? The most important use cases are:
- Accessing third-party APIs over the internet that you want to use within your app
- Heavy data processing that ideally shouldn't take place in the browser
- Data wrangling to make the data easily consumable within the app's web UI
- Requests that need credentials for authentication that you don't want to expose in the app's UI code
Since app functions require some setup effort, only use them for these use cases. For example, you don't need an app function to execute a DQL query. Instead, you can query directly in your app's UI code. Most of the time, accessing external APIs or data is the use case that will apply to you.
Function interface
The Dynatrace JavaScript runtime expects a single default function exported from your function files. This function can contain a single payload parameter, which is the request body of the incoming request.
Each input to your function needs to pass through the function body. You can consume it via the payload parameter in your function.
Here's an example:
export default (payload) => {
return 'Hello World';
};
Logs
Since the app functions run in the Dynatrace JavaScript runtime environment, you can use all the console methods such as console.log, console.info, console.warn, and console.error in your code.
They'll appear in your terminal when you run them locally. However, when you deploy the app, all the logs are stored in Grail. To learn more, have a look at Accessing app function logs.
HTTP status code
Each time you run an app function, it returns a specific response type that includes the HTTP status code. The following table explains each HTTP status code, and the reason behind the code:
| HTTP code | Reason | Definition |
|---|---|---|
| 200 | No Error | Function executed successfully. |
| 400 | Bad request | The app function can't or won't process the request due to perceived client error—for example, malformed request syntax, etc. |
| 404 | The app or the function name wasn't found | The app or function doesn't exist. |
| 409 | The app's backend is being deployed and isn't able to serve requests yet | The app's backend can't serve the request because it's currently being deployed. |
| 500 | Internal server error | The app function encountered something unexpected and couldn't fulfill the request. |
| 540 | JavaScript errors, event loop errors | There is an error in the application code. It can be TypeError, JavaScript error, unhandled exceptions, or event loop error. |
| 541 | Runtime errors (Mem exceeded, Timeout, etc.) | This is an error thrown by the runtime. It can occur because the code exceeds the timeout or memory limit. |
Runtime limitations
The following restrictions currently apply to functions:
- Function execution times out after 120 seconds.
- Functions can't call functions of other apps.
- Functions can't call function executor API.
- Functions are deployed in an environment with 256 MB RAM.
- Functions can't send binary responses.
- Function inputs/outputs can't be larger than 5 MB, respectively.
- There is a limit on concurrent requests you can make to app functions. You'll get back the HTTP 429 Too Many Requests response status code when you reach the limit.
- Calls to external hosts need to be explicitly allowed (see guide).
- You can't use WebSocket API in app functions.