feat: replace deprecated methods with object-based syntax and add missing API methods #31
Conversation
…sing API methods
- Update all SDK method calls to use new object-based parameter syntax
- Fix parameter names: default -> xdefault, path -> xpath
- Use proper enums: Runtime.Node180, ExecutionMethod.GET, IndexType.Key
- Add IndexType to imports
- Add missing methods:
- Databases: listIndexes
- Storage: getFileDownload, getFilePreview (with graceful fallback)
- Users: getUserPrefs, updateUserPrefs
- Functions: updateFunction, listExecutions, createVariable,
listVariables, getVariable, updateVariable, deleteVariable
WalkthroughThe pull request refactors src/app.js to replace positional parameter usages with single-argument options objects across multiple Appwrite SDK methods covering databases, storage, users, and functions APIs. An IndexType import was added. Several new API paths were introduced, including listIndexes, getFileDownload, getFilePreview, and variable/execution-related endpoints. Deployment polling logic was extended with improved error handling messages, and method calls now use explicit field naming conventions (functionId, deploymentId, bucketId, fileId, etc.). Changes total +330/-112 lines. Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In `@src/app.js`:
- Around line 379-405: getFileDownload currently calls storage.getFileDownload
without error handling which can throw and abort the run; wrap the body of
getFileDownload in a try/catch like getFilePreview does, calling
storage.getFileDownload inside the try and logging success as before, and in the
catch log a warning (e.g., console.log(chalk.yellow(`Skipped: ${err.message}`)))
so failures are handled consistently between getFileDownload and getFilePreview.
- Around line 695-702: The call to functions.createExecution uses the deprecated
parameter name `xpath`; update the argument object to use `path` instead (keep
the same value "/" and other fields unchanged). Locate the createExecution
invocation (the object with functionId, body, async, xpath, method:
ExecutionMethod.GET, headers) and rename the `xpath` property to `path` so it
matches the node-appwrite v21 signature expected by createExecution.
- Around line 523-532: The code is using the deprecated Runtime.Node180 in the
functions.create call (functionId/ name "Node Hello World"); update the runtime
to a supported newer Node version by replacing Runtime.Node180 with
Runtime.Node200 (Node 20 LTS) or Runtime.Node210 (Node 21) depending on your
environment, and ensure your deployment supports that runtime variant before
changing it.
🧹 Nitpick comments (2)
src/app.js (2)
692-709: Unnecessary sleep after synchronous execution.The
async: falseflag meanscreateExecutionshould block until execution completes and return the full result. The 3-second sleep on line 706 is likely redundant. While this appears to be pre-existing behavior, it adds unnecessary latency to the playground run.Suggested cleanup
let response = await functions.createExecution({ functionId, body: "", async: false, xpath: "/", method: ExecutionMethod.GET, headers: {} }); - // sleep for 3 seconds - console.log("Waiting a little to ensure execution is finished ..."); - await new Promise((resolve) => setTimeout(resolve, 3000)); - console.log(response); }
791-804: Variable CRUD runs before function execution — intentional?Variables are created and then fully deleted (lines 797–801) before
executeSync/executeAsync(lines 802–803). If the function code ever readsMY_VAR, it won't be available at execution time. For a pure API demonstration this is fine, but reordering to delete the variable after executions would be a more realistic workflow.Suggested reorder
await createVariable(); await listVariables(); await getVariable(); await updateVariable(); - await deleteVariable(); await executeSync(); await executeAsync(); await listExecutions(); + await deleteVariable(); await deleteFunction();
| const getFileDownload = async () => { | ||
| console.log(chalk.greenBright("Running Get File Download API")); | ||
|
|
||
| const response = await storage.getFileDownload({ | ||
| bucketId, | ||
| fileId | ||
| }); | ||
|
|
||
| console.log(`Downloaded file: ${response.byteLength} bytes`); | ||
| } | ||
|
|
||
| const getFilePreview = async () => { | ||
| console.log(chalk.greenBright("Running Get File Preview API")); | ||
|
|
||
| try { | ||
| const response = await storage.getFilePreview({ | ||
| bucketId, | ||
| fileId, | ||
| width: 200, | ||
| height: 200 | ||
| }); | ||
|
|
||
| console.log(`Preview file: ${response.byteLength} bytes`); | ||
| } catch (err) { | ||
| console.log(chalk.yellow(`Skipped: ${err.message}`)); | ||
| } | ||
| } |
There was a problem hiding this comment.
Inconsistent error handling: getFileDownload lacks the try/catch that getFilePreview has.
getFilePreview gracefully catches and logs errors (e.g., if preview generation isn't supported for the file type), but getFileDownload would throw an unhandled exception on failure and abort the entire playground run. Consider wrapping it in the same try/catch pattern for consistency.
Proposed fix
const getFileDownload = async () => {
console.log(chalk.greenBright("Running Get File Download API"));
+ try {
const response = await storage.getFileDownload({
bucketId,
fileId
});
console.log(`Downloaded file: ${response.byteLength} bytes`);
+ } catch (err) {
+ console.log(chalk.yellow(`Skipped: ${err.message}`));
+ }
}🤖 Prompt for AI Agents
In `@src/app.js` around lines 379 - 405, getFileDownload currently calls
storage.getFileDownload without error handling which can throw and abort the
run; wrap the body of getFileDownload in a try/catch like getFilePreview does,
calling storage.getFileDownload inside the try and logging success as before,
and in the catch log a warning (e.g., console.log(chalk.yellow(`Skipped:
${err.message}`))) so failures are handled consistently between getFileDownload
and getFilePreview.
| const response = await functions.create({ | ||
| functionId: ID.unique(), | ||
| name: "Node Hello World", | ||
| runtime: Runtime.Node180, | ||
| execute: [Role.any()], | ||
| entrypoint: "index.js", | ||
| timeout: 15, | ||
| enabled: true, | ||
| logging: true | ||
| }); |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Appwrite SDK v21 supported Node.js runtimes
💡 Result:
Appwrite Web SDK v21.x (appwrite@21.*) doesn’t declare an engines.node constraint in its package.json, so npm won’t enforce a specific Node version. [1]
In practice, to run it on Node.js without extra polyfills, you should use Node.js 18+, because Node 18 introduced a global fetch/FormData/Request/Response implementation enabled by default, which the Web SDK expects in non-browser environments. [2]
Answer: Node.js 18 or newer (recommended; older versions typically require polyfills). [2]
Sources: [1] [2]
🌐 Web query:
Node.js 18.x end of life EOL date
💡 Result:
Node.js 18.x (Hydrogen) reached end-of-life (EOL) on April 30, 2025—after that date it no longer receives security or bug-fix releases. [1][2]
🌐 Web query:
Appwrite function runtimes Node.js 18 20 21 enum values
💡 Result:
In the Appwrite Node SDK (node-appwrite) Runtime enum, the Node.js runtime entries are:
Runtime.Node180="node-18.0"[1]Runtime.Node200="node-20.0"[1]Runtime.Node210="node-21.0"[1]
These strings match the runtime IDs listed in the Appwrite Functions runtimes docs (e.g., node-18.0, node-20.0, node-21.0). [2]
Sources
[1] node-appwrite lib/enums/runtime.js on UNPKG (Runtime enum) (app.unpkg.com)
[2] Appwrite Docs → Functions → Runtimes (appwrite.io)
Citations:
- 1: https://app.unpkg.com/node-appwrite%4012.0.1/files/lib/enums/runtime.js
- 2: https://appwrite.io/docs/products/functions/runtimes
🌐 Web query:
site:appwrite.io Node180 Node200 Node210 runtime
💡 Result:
In Appwrite Functions, the Node runtimes are named using the pattern node-<major>.<minor>:
- Node180 →
node-18.0 - Node200 →
node-20.0 - Node210 →
node-21.0[1]
Appwrite’s runtimes list includes node-18.0, node-20.0, and node-21.0 (plus others). On Appwrite Cloud, the currently listed Node runtimes are limited (shown as node-16.0 and node-18.0), so node-20.0 / node-21.0 may be self-hosted only depending on your setup. [1]
Source
[1] Appwrite Docs – “Runtimes” https://appwrite.io/docs/products/functions/runtimes
Node 18 runtime is past end-of-life (April 30, 2025); use Node 20 or 21 instead if available.
Runtime.Node180 is valid, but Node.js 18.x reached EOL in April 2025 and should be replaced. Consider using Runtime.Node200 (Node 20 LTS) or Runtime.Node210 (Node 21) if your Appwrite deployment supports them. Note that on Appwrite Cloud, only node-18.0 and earlier are currently listed; Node 20/21 may only be available on self-hosted instances.
🤖 Prompt for AI Agents
In `@src/app.js` around lines 523 - 532, The code is using the deprecated
Runtime.Node180 in the functions.create call (functionId/ name "Node Hello
World"); update the runtime to a supported newer Node version by replacing
Runtime.Node180 with Runtime.Node200 (Node 20 LTS) or Runtime.Node210 (Node 21)
depending on your environment, and ensure your deployment supports that runtime
variant before changing it.
| let response = await functions.createExecution({ | ||
| functionId, | ||
| body: "", | ||
| async: false, | ||
| xpath: "/", | ||
| method: ExecutionMethod.GET, | ||
| headers: {} | ||
| }); |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
node-appwrite v21 createExecution method parameters
💡 Result:
In node-appwrite v21, functions.createExecution() takes a single options object with these parameters:
await functions.createExecution({
functionId: string, // required
body?: string, // default: ""
async?: boolean, // default: false
path?: string, // default: "/"
method?: ExecutionMethod, // default: POST
headers?: Record<string, any>, // default: {}
scheduledAt?: string // ISO 8601 datetime (must be in the future; minute precision)
})Source: Appwrite Server (Node.js) Functions reference (“Create execution”). [1]
Note: Older Appwrite Node SDK docs show a positional-args form (createExecution(functionId, body, async, ...)) for earlier versions. [2]
Sources: [1] (appwrite.io) [2] (appwrite.io)
Citations:
- 1: https://appwrite.io/docs/references/cloud/server-nodejs/functions?utm_source=openai
- 2: https://appwrite.io/docs/references/1.5.x/server-nodejs/functions?utm_source=openai
Change xpath to path parameter.
In node-appwrite v21, the parameter is path (not xpath). The official signature uses path?: string with default value "/". The async parameter is correctly named.
let response = await functions.createExecution({
functionId,
body: "",
async: false,
path: "/",
method: ExecutionMethod.GET,
headers: {}
});
🤖 Prompt for AI Agents
In `@src/app.js` around lines 695 - 702, The call to functions.createExecution
uses the deprecated parameter name `xpath`; update the argument object to use
`path` instead (keep the same value "/" and other fields unchanged). Locate the
createExecution invocation (the object with functionId, body, async, xpath,
method: ExecutionMethod.GET, headers) and rename the `xpath` property to `path`
so it matches the node-appwrite v21 signature expected by createExecution.
1 participant
Changes
Replace deprecated methods with new methods
Add missing methods
Summary
Total SDK methods demonstrated: 44 to 56
Summary by CodeRabbit
Refactor
New Features
Bug Fixes