English for Appwrite Developers

Appwrite gives you an authentication system, a document database, file storage, and serverless functions behind one API, and discussing it clearly with a team means being precise about terms that map loosely — but not exactly — onto concepts from Firebase or Supabase. This guide covers the vocabulary you need.

Key Vocabulary

Collection — a group of related documents in Appwrite’s database service, roughly equivalent to a table in a relational database or a collection in MongoDB. “We’re storing user profiles in the profiles collection, with a separate posts collection linked by a userId attribute.”

Attribute — a typed field defined on a collection (string, integer, boolean, relationship) that documents in that collection must conform to. “I added a required status attribute to the orders collection — existing documents without it will fail validation until we backfill.”

Permission (document-level / collection-level) — the access control rules attached to a collection or an individual document, specifying which roles or users can read, write, update, or delete it. “We set document-level permissions so each user can only read and update their own profile document, not the whole collection.”

Appwrite Function — a serverless function, written in any supported runtime, triggered by an event (a document creation, a schedule, an HTTP request) and run in an isolated container. “The welcome-email function triggers on the users.create event and runs independently of the main API, so a slow email provider won’t block signup.”

Query (Appwrite Query builder) — the SDK’s structured filtering syntax (Query.equal, Query.greaterThan, Query.orderDesc) used to build database queries without writing raw query strings. “Instead of filtering client-side, use Query.equal('status', 'active') in the list call — it pushes the filter to the database and avoids pulling unnecessary documents.”

Common Phrases

• “Is this permission set at the collection level or the document level?”
• “Which event triggers this function — a database event, or a scheduled cron?”
• “Are we filtering with a Query builder call, or pulling everything and filtering client-side?”
• “Does this attribute need to be required, or should it default to null?”
• “Which runtime is this function deployed on, and does it have a cold-start concern?”

Example Sentences

Explaining a data model in a design review: “Each document in the posts collection has a required authorId attribute and a relationship attribute pointing back to the profiles collection, so we can query a user’s posts directly.”

Describing a permissions bug: “The document-level permission was still set to the default role, so any authenticated user could read other people’s private documents — we’ve scoped it to the document’s owner now.”

Discussing a function architecture decision: “We moved the image-resizing logic into an Appwrite Function triggered on file upload instead of doing it synchronously in the API route — it keeps the upload response fast.”

Professional Tips

• Distinguish collection-level from document-level permissions explicitly in any security discussion — conflating them is the most common source of Appwrite access-control bugs.
• Name attributes consistently with the client-side types you’ll map them to, and say so in review — a string attribute that’s really meant to hold a date invites parsing bugs downstream.
• When proposing an Appwrite Function, state its trigger explicitly (event, schedule, or HTTP) — “a function that runs on upload” is more useful than “a function that handles images.”
• Prefer describing filters as Query builder calls rather than “the query” — it signals whether filtering happens server-side or client-side, which matters for performance discussions.

Practice Exercise

1. Write one sentence describing a collection and two of its attributes.
2. Explain the difference between collection-level and document-level permissions in your own words.
3. Describe a function and the event that triggers it.