This topic describes the structural features, instance usage, and FAQ of event handlers in a custom runtime.
Background information
In a custom runtime, Function Compute forwards the common headers, the request body, the POST method, the /invoke path, and the /initialize path to your HTTP server. You can build an input parameter similar to thecontext
parameter in an official runtime based on the information in common headers. You can also build an input parameter similar to the event
parameter in an official runtime based on the request body of the invoked function. 
Function invocation
If the function uses an event handler, the HTTP server needs to only implement the logic that corresponds to the /invoke
path and the POST
method.
Path | Request | Expected response |
---|---|---|
POST /invoke |
| Response body: the return value of the function handler. The return value includes the response code and response header.
You can include the x-fc-status field in response headers to report to Function Compute whether the local function is successfully invoked.
Note We recommend that you specify the StatusCode and x-fc-status fields in the HTTP response. |
Examples
You can use Serverless Devs to migrate your applications to Function Compute with a few clicks. The following example shows how to use Serverless Devs to deploy and invoke a function in an efficient manner. You can modify the sample code based on your business requirements.
PHP
Go
Node.js
Python
Ruby
C++
TypeScript
Powershell
Lua
Dart
Rust
FAQ
- Must the listening port of a custom runtime be the same as that of the HTTP server of the custom runtime?
- What do I do if the FunctionNotStarted error occurs when I invoke a third-party service in a service started in a custom runtime?
- What do I do if a function exits unexpectedly and the "Process exited unexpectedly before completing request" message is reported?
- What do I do if a 404 error occurs when I use a browser or the cURL tool to access a function?