Skip to content

Commit 7628305

Browse files
committed
chat: add aws lambda before publish rule documentation
1 parent fae3551 commit 7628305

File tree

1 file changed

+101
-0
lines changed

1 file changed

+101
-0
lines changed
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
---
2+
title: AWS Lambda
3+
meta_description: "Detect and remove unwanted content in a Chat Room using AWS Lambda."
4+
product: chat
5+
languages:
6+
- javascript
7+
- react
8+
- swift
9+
- kotlin
10+
---
11+
12+
The AWS Lambda rule is a powerful way to bring your own moderation solution to Ably Chat. It allows you to run custom moderation logic or integrate with your preferred moderation provider by configuring an AWS Lambda function that will be invoked before messages are published to a chat room.
13+
14+
This rule is particularly useful when you want to:
15+
* Integrate with a custom moderation service
16+
* Implement your own moderation logic
17+
* Use a moderation provider that isn't directly supported by Ably
18+
19+
h2(#fields). Rule fields
20+
21+
- AWS Region := The region where your Lambda function is deployed.
22+
- Function Name := The name of your AWS Lambda function.
23+
- AWS Authentication Scheme := The authentication method to use. Either @AWS Credentials@ or @ARN of an assumable role@. See the "Ably AWS authentication documentation":https://ably.com/docs/integrations/webhooks/lambda#aws-authentication.
24+
- Retry Timeout := Maximum duration (in milliseconds) that an attempt to invoke the rule may take (including any retries).
25+
- Max Retries := Maximum number of retries after the first attempt at invoking the rule.
26+
- Failed Action := The action to take in the event that a rule fails to invoke. Options are reject the request or publish anyway.
27+
- Room Filter (Optional) := A regular expression to match to specific chat rooms.
28+
29+
h2(#lambda_setup). Lambda Function Setup
30+
31+
To use the AWS Lambda rule, you need to create a Lambda function that adheres to the following API contract:
32+
33+
h3(#request). Request Format
34+
35+
<pre><code class="json">{
36+
"source": "string",
37+
"appId": "string",
38+
"roomId": "string",
39+
"site": "string",
40+
"ruleId": "string",
41+
"message": {
42+
"roomId": "string",
43+
"clientId": "string",
44+
"text": "string",
45+
"metadata": {
46+
"key": "any"
47+
},
48+
"headers": {
49+
"key": "string"
50+
}
51+
}
52+
}</code></pre>
53+
54+
h3(#response). Response Format
55+
56+
Your Lambda function must return a response in the following format:
57+
58+
<pre><code class="json">{
59+
"action": "accept|reject",
60+
"message": {
61+
"text": "string",
62+
"metadata": {
63+
"key": "any"
64+
},
65+
"headers": {
66+
"key": "string"
67+
}
68+
},
69+
"rejectionReason": {
70+
"key": "any"
71+
}
72+
}</code></pre>
73+
74+
* @action@: Must be either @accept@ or @reject@
75+
* @message@: Optional. If provided with @action: "accept"@, it allows you to modify the message before it's published. You can modify the @text@, @metadata@, and @headers@ fields.
76+
* @rejectionReason@: Optional. If provided with @action: "reject"@, it can contain any information about why the message was rejected. This information may be sent back to clients.
77+
78+
h2(#rejections). Handling rejections
79+
80+
Since the invocation of the Lambda function is synchronous relative to the publish operation, any rejection by the moderation function will result in the publish attempt being refused immediately. The rejection will use error code @42213@.
81+
82+
h2(#best_practices). Best Practices
83+
84+
When implementing your Lambda function, consider the following:
85+
86+
* Keep your function execution time as low as possible to minimize latency
87+
* Implement proper error handling and logging
88+
* Consider implementing rate limiting if you're using a third-party moderation service
89+
* Use appropriate IAM roles and permissions for your Lambda function
90+
* Consider implementing caching for frequently occurring content
91+
92+
h3(#error_handling). Error Handling
93+
94+
The Lambda function can return two types of errors:
95+
96+
* Retriable errors: HTTP status codes 429 (Too Many Requests) and 500-599 (Server Errors)
97+
* Non-retriable errors: All other HTTP status codes
98+
99+
When a retriable error occurs, Ably will retry the invocation according to the configured retry settings. For non-retriable errors, the publish attempt will be refused immediately with the error.
100+
101+
For more information on AWS Lambda integration with Ably, please refer to the "Ably AWS Lambda documentation":https://ably.com/docs/integrations/webhooks/lambda.

0 commit comments

Comments
 (0)