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 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, we encourage you to use them only 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.
Every input to your function needs to be passed via 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.
While running locally, they'll appear in your terminal. However, when you deploy the app, all the logs are stored in Grail. To learn more, visit Accessing app function logs.
HTTP status code
Each time you run an app function, it returns a specific type of response that includes the HTTP status code. The following table explains each HTTP status code and the reason behind the code.
| HTTP code | Reason |
|---|---|
| 200 | No Error |
| 400 | Bad request |
| 404 | The app or the function name wasn't found |
| 409 | The app's backend is being deployed and isn't able to serve requests yet |
| 500 | Internal server error |
| 540 | JavaScript errors, event loop errors |
| 541 | Runtime errors (Mem exceeded, Timeout, etc.) |
Let's understand each HTTP code:
200: Function executed successfully.400: 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 function doesn't exist.409: The app's backend can't serve the request because it's currently being deployed.500: The app function encountered something unexpected and couldn't fulfill the request.540: There is an error in the application code. It can be TypeError, JavaScript error, unhandled exceptions, or event loop error.541: This is an error thrown by the runtime. It can occur because the code exceeds the timeout or memory limit.
Runtime limitations
Currently, the following restrictions 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.