Add missing execution info to Functions doc #2147
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
appwrite.ioProject ID: Note You can use Avatars API to generate QR code for any text or URLs. |
|
The preview deployment failed. 🔴 Last updated at: 2025-07-02 13:18:55 CET |
TorstenDittmann
force-pushed
the
main
branch
5 times, most recently
from
6e3c6b4 to
83e3ebc
Compare
stnguyen90
requested changes
Jul 22, 2025
| * `create-execution [options]` | ||
| * Trigger a function execution. The returned object will return you the current execution status. You can ping the 'Get Execution' endpoint to get updates on the current execution status. Once this endpoint is called, your function execution process will start asynchronously. | ||
| * `create-execution [options]` | ||
| * Trigger a function execution. The returned object will return you the current execution status. You can ping the 'Get Execution' endpoint to get updates on the current execution status. |
There was a problem hiding this comment.
Looks like this needs to be updated too. They should match up. Maybe we should just change it to:
Suggested change
| * Trigger a function execution. The returned object will return you the current execution status. You can ping the 'Get Execution' endpoint to get updates on the current execution status. | |
| * Trigger a function execution. |
Comment on lines
-331
to
+371
| functionId: "<FUNCTION_ID>" | ||
| body: "<BODY>" // optional | ||
| async: false // optional | ||
| path: "<PATH>" // optional | ||
| method: "GET" // optional | ||
| functionId: "<FUNCTION_ID>" | ||
| body: "<BODY>" // optional | ||
| async: false // optional | ||
| path: "<PATH>" // optional | ||
| method: "GET" // optional |
There was a problem hiding this comment.
nice job with the white space cleanup
| @@ -11,6 +11,42 @@ Appwrite Functions can be executed in several ways. | |||
| Executions can be invoked through the Appwrite SDK and visiting its REST endpoint. Functions can also be triggered by events and scheduled executions. | |||
| Here are all the different ways to consume your Appwrite Functions. | |||
|
|
|||
| # Execution modes {% #execution-modes %} | |||
|
|
|||
| Appwrite Functions support two execution modes: **synchronous** and **asynchronous**. Understanding the difference between these modes is important for building efficient applications. | |||
There was a problem hiding this comment.
Let's try to keep docs concise and to the point:
Suggested change
| Appwrite Functions support two execution modes: **synchronous** and **asynchronous**. Understanding the difference between these modes is important for building efficient applications. | |
| Appwrite Functions support two execution modes: **synchronous** and **asynchronous**. |
|
|
||
| Synchronous executions: | ||
| - Return response bodies and headers directly to the client | ||
| - Have a **30-second timeout limit** to prevent long-running requests from blocking Appwrite workers |
There was a problem hiding this comment.
Let's reword this to something like:
Suggested change
| - Have a **30-second timeout limit** to prevent long-running requests from blocking Appwrite workers | |
| - Have a **30-second timeout limit** to discourage slow API calls from apps causing poor user experience |
| - Return response bodies and headers directly to the client | ||
| - Have a **30-second timeout limit** to prevent long-running requests from blocking Appwrite workers | ||
| - Are ideal for real-time operations where you need immediate response data | ||
| - Work best for lightweight operations that complete quickly |
There was a problem hiding this comment.
Ideally, all function executions should be lightweight and complete quickly. That's the suggestion for all serverless functions.
| Asynchronous executions: | ||
| - Have no timeout limitations beyond your function's configured timeout | ||
| - Do **not store** response bodies and headers and cannot be retrieved later | ||
| - Are ideal for long-running tasks, background processing, and event-driven workflows |
There was a problem hiding this comment.
long-running tasks,
I wouldn't say long-running. Definitely if it needs to be more than 30 seconds. I don't want to encourage long running executions.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Updates Functions documentation to include some missing info about executions
Test Plan
/docs/products/functions/executions/docs/products/functions/execute/docs/tooling/command-line/functions#commandsRelated PRs and Issues
DRL-1514