Forem: Ebenezer Don

Your Experience Is Your Biggest AI Advantage

Ebenezer Don — Fri, 20 Mar 2026 12:56:44 +0000

AI output looks professional. That's the part people underestimate.

Before these tools existed, the quality of your code reflected your experience. Junior code looked junior: inconsistent naming, missing edge cases, awkward structure. You could tell at a glance who wrote it.

That's harder now. AI-generated code is clean, well-structured, properly commented, and follows conventions. A function written by someone with two years of experience, using AI, looks roughly the same as one written by someone with ten. The surface quality converged.

This is exactly why experience matters more, not less. When everything looks right, the ability to evaluate what's actually right becomes the scarce skill.

The Plausibility Problem

The old failure mode was obvious. Bad code looked bad. Missing error handling showed up as missing code. Bad naming jumped off the screen. You could catch problems in review because they looked like problems.

That's not how it works anymore. AI-generated code is usually clean, well-structured, and follows conventions. Often it's genuinely good. But the surface quality is high regardless of whether the underlying decisions are right. A solid implementation and one with a subtle flaw look the same on the screen. You can't tell from reading whether the query will hold at 10x load, or whether the abstraction fits where the product is heading. The code itself won't tell you.

What tells you is having seen these decisions play out before. You question the error handling approach because you've spent a day hunting a bug that vanished into a catch block. You think about scaling behavior because you've watched similar queries degrade under load. You push back on the abstraction because you've lived with the cost of a similar choice in a different system.

When the surface quality of everyone's code is high, the ability to evaluate what's underneath becomes the thing that separates good work from work that just looks good.

The Questions You Never Think to Ask

The biggest risk with AI is the questions you never think to ask.

Someone early in their career gives the model a task and gets a working solution. They test it. It works. They ship it. What they don't do: ask what happens when the external API goes down. Ask about connection pooling under concurrent load. Ask whether the data model supports the query patterns that will exist in six months. Ask whether the rate limiter behaves correctly during a retry storm.

They don't ask because they don't know to worry about these things. They haven't been the person on call when the API went down. They haven't debugged a connection pool leak that took down a service. They haven't migrated a data model that wasn't designed for the access patterns the product evolved into.

The model won't raise these concerns unprompted. It answers what you ask. Your experience determines what you know to ask, and more importantly, what you know to be nervous about. That feeling when something seems too straightforward, the instinct that says "this looks too simple, what am I missing," that's years of experience surfacing.

The Editing Shift

The nature of the work changed. You used to write first drafts. Now you edit generated ones.

Editing is harder than writing. When you write code, you hold the full context in your head: what you're trying to do, why you chose this approach, what alternatives you considered. When you edit AI-generated code, you have to reconstruct all of that. You're reverse-engineering intent from output, then evaluating whether that intent matches what you actually need.

This requires you to know more, not less. You need to understand the problem well enough to recognize when the solution misses it, know the codebase well enough to spot where generated code conflicts with existing patterns, and understand the system well enough to predict how new components will interact with everything else.

The people who say "AI writes the code, I just review it" are describing a job that requires more expertise than writing it yourself. The review is the hard part. It always was. AI just made it the only part.

The Pipeline Problem

There's a tension in the "experience is your edge" conversation that rarely gets addressed: if AI handles the work that builds experience, where does the next generation of experienced developers come from?

You don't learn what connection pooling means by reading about it. You learn it by running out of connections. You don't learn why idempotency matters by studying the concept. You learn it by processing a payment twice. The feedback loop of building, breaking, and fixing is how judgment forms.

If AI handles more of the building, and the building is where the learning happens, the pipeline that creates experienced developers narrows. Juniors can ship more, faster, with fewer visible mistakes. But visible mistakes are the ones that teach you the most.

This doesn't mean AI is bad for juniors. It means the path to depth might need to be more deliberate now. If the tool handles the easy mistakes, you have to seek out the hard ones. Build things that push you into territory where AI can't carry you. Work on systems complex enough that the output needs real evaluation. The feedback loop still exists, but you might have to put yourself in its path instead of waiting for it to find you.

Using It or Losing It

Experience is an advantage. A real one, not a polite reassurance. But it's conditional on two things.

First, you have to actually use these tools. Judgment applied through AI is dramatically more powerful than judgment applied at the speed of manual work. If you have the depth but refuse the tools, you're competing on throughput against people who have less depth but more leverage. That's a losing position over time.

Second, your experience has to be the right kind. If what you know is how to navigate a specific framework's quirks, or how to set up infrastructure from memory, or the keyboard shortcuts that make you fast, those things are getting cheaper. If what you know is how systems fail, how decisions compound, what "done well" looks like versus "done," and which questions to ask before shipping, that's the kind of experience that tells you when AI output is trustworthy and when it just looks that way.

The tools are getting better. The floor is rising. The bar for "good enough without deep understanding" goes up every year. And the bar for "actually good, built to last, thought through at every level" stays exactly where it's always been: wherever your judgment puts it.

How to host SSR web apps on Appwrite Sites

Ebenezer Don — Tue, 20 May 2025 13:34:40 +0000

When you're building a modern web app, how you serve your content matters. Some pages need to be pre-rendered ahead of time for speed. Others need to be generated dynamically on the server for personalization or real-time data. This process is called Server-Side Rendering (SSR), and Appwrite Sites supports SSR, just like it supports Client-Side Rendering (CSR) and Static Site Generation (SSG).

If you've used platforms like Vercel before, this will feel familiar. You can connect your GitHub repository, choose a branch, and Appwrite will build your app and deploy it to a server.

In this post, we'll show you exactly how to host an SSR-capable web app using Appwrite Sites, from repository connection to framework-specific configurations. Whether you're migrating from Vercel or starting from scratch, this guide will walk you through every step.

What is SSR, and why does it matter?

Server-Side Rendering (SSR) means your web app's pages are rendered on the server at request time. Unlike pre-rendered static pages, SSR allows your app to respond to each request with dynamic content that's fully rendered before it reaches the browser. It's a powerful approach for apps that need authentication, personalization, real-time data, or SEO-friendly dynamic content.

Appwrite Sites supports SSR by allowing you to configure your framework's build settings and output behavior, and by running your app on a server runtime (Node.js) where needed.

Hosting an SSR app on Appwrite Sites

Let's walk through the process step by step.

1. Open the Appwrite Console

Log in to your Appwrite Console. In the left sidebar, you'll see a section labeled Sites. Click on it. This will take you to the Sites dashboard, where you can manage existing sites or deploy a new one.

Click the Create Site button to get started.

At this point, you have two options:

Clone a template , If you're starting fresh, this is a quick way to scaffold a new site.
Connect a repository , If you already have a working app in GitHub, this is what you'll want.

Choose Connect a repository. Appwrite will walk you through selecting a GitHub repository and giving the necessary permissions if you haven't already.

2. Configure your deployment settings

Once your repository is connected, you'll land on the deployment configuration page. Here's what you'll see:

Name: A name for your site, usually taken from your repository.
Branch: The branch you want to use for production (typically main or master).
Root directory: Leave this as ./ unless your app lives in a subfolder.
Silent mode: This prevents Appwrite from adding GitHub comments when changes are pushed.
Framework: Optional, but recommended. Selecting your framework here helps Appwrite apply sensible defaults and display SSR instructions specific to your setup.

Now, scroll down to the Build settings section. This is where you define how your app gets built:

Install command: The default npm install usually works unless your app uses a different package manager or custom setup.
Build command: For most frameworks, this is npm run build.
Output directory: For Next.js, this would typically be ./.next. Different frameworks may use different output paths.

If your app needs environment variables, like API keys, secrets, or runtime flags, you can define them in the Environment variables section. You can also import them from an existing .env file.

When you're done, click Deploy. Appwrite will pull your code, run your build steps, and deploy your site.

Framework-specific SSR tips

While Appwrite Sites supports SSR, not every framework behaves the same out of the box. If your app was previously deployed on Vercel, there's a good chance it was configured with a Vercel-specific adapter, especially if you used Next.js or SvelteKit.

These adapters are tailored for Vercel's environment and won't run properly on Appwrite, which expects Node.js as the runtime. To make SSR work on Appwrite, you'll need to switch to the appropriate Node.js adapter.

Let's go through a few popular frameworks and what to look out for:

Next.js

If you're using Next.js, SSR is supported. In your next.config.js file, make sure you do not set the output field. That's specific to Vercel and can interfere with the way Appwrite handles the build output.

Just let Next.js use its default behavior, and in your site settings, keep the output directory as ./.next.

SvelteKit

SvelteKit sites hosted on Vercel typically use @sveltejs/adapter-vercel. That won't work on Appwrite. To fix this, open your svelte.config.js file and switch to the Node.js adapter:

import adapter from '@sveltejs/adapter-node'

export default {
  kit: {
    adapter: adapter(),
  },
}

Once that's set, rebuild and redeploy your site.

Nuxt

Nuxt works quite seamlessly on Appwrite. In your site settings, make sure the build command is set to:

npm run build

SSR is supported out of the box with no additional adapter configuration needed.

Angular (with SSR)

If you've enabled SSR in your Angular app, make sure your src/server.ts file is using the @angular/ssr/node package. This enables Angular Universal to run properly in a Node.js environment.

Astro

For Astro apps, you'll want to install and configure the Node adapter. In astro.config.mjs, update your adapter:

import node from '@astrojs/node'

export default {
  output: 'server',
  adapter: node(),
}

This tells Astro to render pages server-side using Node.js.

Remix

Remix apps should be configured to use @remix-run/node in the server entry file. Make sure your entry.server.tsx file imports from:

import { createRequestHandler } from '@remix-run/node'

This ensures the server runtime is correctly set for Node environments like Appwrite.

Analog (Angular meta-framework)

Analog supports SSR via Vite. To enable it, set the ssr property to true inside your vite.config.ts file:

export default defineConfig({
  plugins: [
    analog({
      ssr: true,
    }),
  ],
})

This activates server-side rendering in your build pipeline.

How to check or change framework instructions

If you're not sure what to do for your specific framework, you can find help directly in the Appwrite Console.

Just open your deployed site from the Sites dashboard, click on Settings, and scroll down to the Build settings section. When you select a framework from the dropdown, Appwrite will show instructions for SSR configuration, specific to your chosen stack.

That way, you'll know exactly what needs to change, and how.

Final thoughts

Hosting SSR apps with Appwrite Sites gives you a lot of flexibility. You get a Git-powered workflow, server runtime support, and integration with frameworks you already use. But more importantly, you're in control. You're not locked into a proprietary environment, and you can configure the exact build behavior you need.

If you're switching from Vercel, just remember to revisit your framework's adapter and build setup. Most of the time, it's just a matter of switching to a Node.js adapter and updating a couple of config files.

Once you've set that up, Appwrite Sites takes care of the rest, from cloning your repo to deploying server-rendered content.

Try it out, and let us know how it works for your stack.ed to be generated dynamically on the server for personalization or real-time data. This process is called Server-Side Rendering (SSR), and Appwrite Sites supports SSR, just like it supports Client-Side Rendering (CSR) and Static Site Generation (SSG).

If you've used platforms like Vercel before, this will feel familiar. You can connect your GitHub repository, choose a branch, and Appwrite will build your app and deploy it to a server.

What is SSR, and why does it matter?

Appwrite Sites supports SSR by allowing you to configure your framework's build settings and output behavior, and by running your app on a server runtime (Node.js) where needed.

Hosting an SSR app on Appwrite Sites

Let's walk through the process step by step.

1. Open the Appwrite Console

Click the Create Site button to get started.

At this point, you have two options:

Clone a template , If you're starting fresh, this is a quick way to scaffold a new site.
Connect a repository , If you already have a working app in GitHub, this is what you'll want.

Choose Connect a repository. Appwrite will walk you through selecting a GitHub repository and giving the necessary permissions if you haven't already.

2. Configure your deployment settings

Once your repository is connected, you'll land on the deployment configuration page. Here's what you'll see:

Name: A name for your site, usually taken from your repository.
Branch: The branch you want to use for production (typically main or master).
Root directory: Leave this as ./ unless your app lives in a subfolder.
Silent mode: This prevents Appwrite from adding GitHub comments when changes are pushed.
Framework: Optional, but recommended. Selecting your framework here helps Appwrite apply sensible defaults and display SSR instructions specific to your setup.

Now, scroll down to the Build settings section. This is where you define how your app gets built:

Install command: The default npm install usually works unless your app uses a different package manager or custom setup.
Build command: For most frameworks, this is npm run build.
Output directory: For Next.js, this would typically be ./.next. Different frameworks may use different output paths.

If your app needs environment variables, like API keys, secrets, or runtime flags, you can define them in the Environment variables section. You can also import them from an existing .env file.

When you're done, click Deploy. Appwrite will pull your code, run your build steps, and deploy your site.

Framework-specific SSR tips

Let's go through a few popular frameworks and what to look out for:

Next.js

Just let Next.js use its default behavior, and in your site settings, keep the output directory as ./.next.

SvelteKit

SvelteKit sites hosted on Vercel typically use @sveltejs/adapter-vercel. That won't work on Appwrite. To fix this, open your svelte.config.js file and switch to the Node.js adapter:

import adapter from '@sveltejs/adapter-node'

export default {
  kit: {
    adapter: adapter(),
  },
}

Once that's set, rebuild and redeploy your site.

Nuxt

Nuxt works quite seamlessly on Appwrite. In your site settings, make sure the build command is set to:

npm run build

SSR is supported out of the box with no additional adapter configuration needed.

Angular (with SSR)

If you've enabled SSR in your Angular app, make sure your src/server.ts file is using the @angular/ssr/node package. This enables Angular Universal to run properly in a Node.js environment.

Astro

For Astro apps, you'll want to install and configure the Node adapter. In astro.config.mjs, update your adapter:

import node from '@astrojs/node'

export default {
  output: 'server',
  adapter: node(),
}

This tells Astro to render pages server-side using Node.js.

Remix

Remix apps should be configured to use @remix-run/node in the server entry file. Make sure your entry.server.tsx file imports from:

import { createRequestHandler } from '@remix-run/node'

This ensures the server runtime is correctly set for Node environments like Appwrite.

Analog (Angular meta-framework)

Analog supports SSR via Vite. To enable it, set the ssr property to true inside your vite.config.ts file:

export default defineConfig({
  plugins: [
    analog({
      ssr: true,
    }),
  ],
})

This activates server-side rendering in your build pipeline.

How to check or change framework instructions

If you're not sure what to do for your specific framework, you can find help directly in the Appwrite Console.

That way, you'll know exactly what needs to change, and how.

Final thoughts

Once you've set that up, Appwrite Sites takes care of the rest, from cloning your repo to deploying server-rendered content.

Try it out, and let us know how it works for your stack.

Appwrite Sites vs Vercel: Choosing the right web hosting platform

Ebenezer Don — Tue, 20 May 2025 13:33:57 +0000

Deploying modern web applications should be fast, flexible, and reliable. As developers, we've come to expect instant previews, custom domain support, seamless environment configuration, automatic HTTPS, and the ability to deploy everything from static pages to full server-rendered apps.

Vercel has been a default choice for frontend teams building with Next.js. But with the launch of Appwrite Sites, you now have a new, integrated way to deploy web apps, especially when you want your front end to live alongside your backend, database, authentication, and storage.

In this post, we'll take a look at how Appwrite Sites compares to Vercel. We'll explore everything from framework support to deployment workflows, logging, performance, and how each platform fits into a larger developer workflow.

What is Appwrite Sites?

Appwrite Sites is Appwrite's new deployment and hosting platform, designed to support both static (including single-page applications) and server-side rendered (SSR) web applications. It's tightly integrated into the Appwrite ecosystem, so if you're already using Appwrite for authentication, database, storage, or functions, you can now deploy your front end in the same place, with automatic access to shared environment variables and services.

Whether you're building with Vite, Next.js, Nuxt, SvelteKit, Astro, or something simpler like Vanilla JS or even Flutter Web and Lynx, Appwrite Sites provides a unified deployment workflow for both static and dynamic applications.

Integrated, full-stack hosting with Sites

One of the biggest differences between Appwrite Sites and Vercel is how they fit into your application architecture.

Vercel focuses primarily on frontend deployment. It excels at handling static assets and serverless-rendered content, especially from Next.js. It also supports other frontend frameworks like Astro, SvelteKit, Nuxt, and Remix, although it's deeply optimized for Next.js and includes native support for features like ISR (Incremental Static Regeneration) and Edge Middleware.

Appwrite Sites, on the other hand, is part of a complete development platform. You're not just deploying your frontend. You're deploying it in the same environment that already knows about your database collections, users, sessions, cloud functions, storage buckets, and APIs. That means the same platform handles everything from user auth to file uploads to server-side logic, and your frontend can interact with it all without any manual configuration.

This level of integration also means less risk of misconfiguration when connecting your services. Your environment variables, domain rules, CORS policies, and secrets are all managed within one project scope, reducing the friction between your frontend and backend.

Deployment workflows

Both platforms support Git-based workflows, which means you can deploy by connecting a GitHub repo and pushing changes to a selected branch. Each deployment also generates automatic screenshots, giving you a quick visual snapshot of the deployed result.

Deploying on Vercel

You connect your GitHub, GitLab, or Bitbucket repo.
Vercel auto-detects your framework and sets up sensible defaults.
Every push to your production branch triggers a build and deployment.
Pull requests automatically create preview deployments with unique URLs.
Each deployment includes a UI to inspect build logs, preview the deployment and view associated metadata.
You can redeploy any previous commit and view full deployment history.
There's no manual UI deployment support, although, there’s a CLI option.

Deploying on Appwrite Sites

You connect a GitHub repo to your Appwrite project.
Appwrite auto-detects your framework and applies default build, install, and output settings.
You choose a production branch.
Each commit triggers a build and deploy.
You can preview pull requests, commits, and even branches, each with their own URLs.
Manual deployment is supported, with a simple drag-and-drop interface in the Console. This lets you deploy without needing Git or the CLi.
Rollbacks are instant. You can restore a previous deployment with one click.
Deployment output is available as a downloadable folder you can inspect locally.

Manual deployment with Appwrite Sites offers an extra layer of flexibility, especially for small and simple static sites, which makes it easy to get started or quickly publish content without relying on Git or command-line tools.

Framework support

Vercel is best known for its deep Next.js integration, but it also supports other frameworks like Astro, SvelteKit, Nuxt, Angular, and Remix. However, its serverless and edge rendering infrastructure is most optimized for Next.js. Features like API Routes, Middleware, and ISR work out of the box with Next.js and require extra configuration or aren't supported at the same level with other frameworks.

Appwrite Sites offers SSR and static support for a wide range of frameworks, including:

Next.js
Nuxt
SvelteKit
Angular
Astro
Remix
Flutter Web (static)
Lynx
Analog
Vanilla JS and other static site generators

Each framework comes with its own build recommendations, and Appwrite Sites allows you to customize build and install commands, as well as define the output directory for compatibility.

Any static framework works well with Appwrite out of the box. For popular tools like Next.js, Nuxt, and SvelteKit, Appwrite offers presets that auto-configure your build and output settings. If your framework isn’t listed, you can choose “Other” and manually set the commands and output directory.

Most static and SPA setups work seamlessly. The only exception is SSR support for certain metaframeworks like Lit, which aren’t yet supported in SSR mode, but they still work fine as static sites.

If you're using a framework outside of Next.js, Appwrite Sites provides a more consistent experience across the board. This is also an advantage for teams that use different frameworks for different parts of their stack.

Hosting options: Static vs SSR

Appwrite Sites supports both Static/SPA hosting and Server-Side Rendering (SSR), much like Vercel. But there are a few differences in how they operate.

Static hosting

On both platforms, static content is pre-rendered at build time and served via a CDN. This gives you fast cold starts and simple deploys. Appwrite Sites provides build-time environment variables and supports any static framework or tool.

Server-side rendering

With SSR, both platforms render pages on demand.

Vercel runs SSR via serverless functions or edge functions depending on your configuration and framework. Its default serverless runtime supports dynamic SSR, and Next.js projects get special handling for API routes, dynamic rendering modes, and edge cache rules.

Appwrite Sites runs SSR apps in isolated containers, which means:

You get full runtime access to environment variables
Console output from server-side code is captured in logs
The SSR runtime can access Appwrite services directly

That container-based model gives you more flexibility, especially if you're doing server-side API calls, interacting with Appwrite's SDK, or running custom logic during rendering.

Environment variables

Both platforms offer strong environment variable support, with scope control and secrets handling.

Environment variables on Vercel

You define environment variables per environment: Development, Preview, and Production.
You can override variables per branch.
Secrets are encrypted and only available at build or runtime (depending on the variable).
You can manage them from the dashboard or CLI.

Environment variables on Appwrite Sites

You define project-wide and site-specific variables.
Variables can be exposed at build time, runtime, or both.
Appwrite injects built-in environment variables for your site, project, region, version, framework, and more.
You can define secret variables that are hidden after creation and not exposed via Console or API.

These built-in variables make it much easier to integrate your front end with the rest of your Appwrite services. You don't have to manually pass your API endpoint or project ID because it's already available.

Appwrite also provides a dynamic API key automatically, scoped and injected for both the build process and runtime (for SSR). This makes it easier to create or configure collections at build time, or securely perform server-to-server operations during SSR. If you were deploying on Vercel, you’d need to manually generate an Appwrite API key, store it as a secret, and rotate it regularly to maintain security.

Domains, CORS, and routing

Both Vercel and Appwrite Sites allow you to connect custom domains and use automatically generated subdomains for previews.

Vercel provides:

Auto-generated domains per project and deployment.
Custom domain support with DNS configuration.
Wildcard and branch subdomains.
HTTPS with automatic renewal via Let's Encrypt.

Appwrite Sites offers:

Auto-generated domain.
Custom domain support via CNAME records or full nameserver (NS) configuration
Branch and commit-specific URLs.
HTTPS enforcement and TLS certificates out of the box.

When you host both frontend and backend on Appwrite, your domain is trusted automatically. This eliminates the need to manually add frontend origins to your CORS settings because Appwrite already knows your Sites deployment is part of your project. This simplifies development and removes a common pain point: CORS errors.

It’s also important for preview deployments. Vercel assigns preview URLs under a shared namespace (e.g. *.vercel.app). If you try to allow previews with a wildcard like *.vercel.app, you’re not just allowing your previews, you’re allowing every Vercel preview domain to access your backend. That introduces unnecessary risk. Appwrite avoids this entirely. Since previews are scoped to your project, they’re trusted automatically, giving you tighter control without needing to expose your backend to external domains.

Logging and monitoring

Both platforms offer ways to monitor your applications and track issues in production, with some key differences in their approaches.

Vercel provides:

Build logs and deployment history.
Function execution logs (for serverless and edge functions).
Analytics for traffic and performance (on paid plans).

Appwrite Sites includes:

Request logs: status codes, duration, methods, headers, paths.
Console output: SSR logs from console.log() and console.error().
Log retention: 24 hours on the free plan, up to 7 days on Pro.
Optional log disabling: useful for privacy and performance-sensitive SSR routes.

These logs give you immediate visibility into how your app behaves in production and will help with troubleshooting issues when needed.

Performance and timeouts

Vercel uses edge functions and CDN caching for content delivery. Static content is served from edge locations, while serverless functions run in regional data centers. Performance varies by plan tier and deployment type.

Appwrite Sites uses a global CDN for static content, and container-based SSR for dynamic apps. You can configure timeouts (up to 30 seconds per request), and performance depends on your framework and hosting mode. Static hosting delivers near-instant responses through CDN caching, while SSR requires container initialization on cold starts but provides consistent performance afterward.

Security and isolation

Both platforms enforce HTTPS and protect secret environment variables.

Appwrite Sites also ensures:

Container isolation per deployment
TLS enforcement for all domains
Secret environment variables hidden after creation
Preview deployments can be restricted to team members

This is important for deploying apps that handle sensitive data or use server-side logic tied to specific users or accounts.

When to choose Appwrite Sites

If you're already building your backend with Appwrite, or want a single platform for your full-stack app, Appwrite Sites is a natural fit. You get integrated deployments, native access to your backend, and support for a wider range of frameworks with both static and SSR modes.

It's also a good choice if you:

Need SSR for frameworks beyond Next.js
Want to deploy front ends tightly coupled to backend services
Prefer to manage authentication, database, storage, and hosting in one place
Want rollback support, deployment visibility, and runtime logs built-in

Appwrite Sites vs Vercel: feature comparison

Feature	Appwrite Sites	Vercel
Full-stack integration	Yes	No
Static hosting	Yes	Yes
Server-side rendering	Yes (container-based)	Yes (serverless/edge)
Git-based deployment	Yes	Yes
Manual deployment via UI	Yes (drag-and-drop)	No
Preview deployments	Branch, commit, PR	Branch, commit, PR
Rollbacks	Yes	Yes
CORS with Appwrite backend	Automatic (trusted by default)	Manual setup
API key injection	Automatic (build + runtime)	Manual setup + rotation
Environment variables	Build + runtime, auto-injected Appwrite vars	Build + runtime, manual
Wide framework support	Yes	Yes
Templates	Yes (multi-framework)	Yes (mostly Next.js)
Timeout configuration	Yes (up to 30s)	Yes
Logging	Build logs, request logs, SSR console output	Build + function logs
Custom domains	Yes	Yes

Final thoughts

Both Appwrite Sites and Vercel are great platforms for deploying modern web applications. But they're built for slightly different workflows.

Vercel is an excellent frontend-focused host, especially for teams that are all-in on Next.js, or for static sites that don’t need a backend. Appwrite Sites, meanwhile, offers a deeply integrated full-stack environment, where your front end, backend, and services all live in the same project.

If you want to simplify your stack and keep everything in one place, from database to auth to hosting, Appwrite Sites offers a compelling alternative that brings clarity and flexibility to full-stack development.

You can get started today by heading to your Appwrite Console and creating a new Site. Appwrite Sites has templates, GitHub integrations, and framework guides ready to go.

If you have any questions, reach out to the Appwrite community on Discord or use the contact form on the website.

Appwrite Sites vs Netlify: Choosing the right web hosting platform

Ebenezer Don — Tue, 20 May 2025 13:33:25 +0000

Deploying frontend applications has gotten easier over the past decade, but also more complex behind the scenes. Most apps today need more than just HTML, CSS, and a CDN. They need authentication, secure APIs, environment configs, storage access, and sometimes server-side rendering.

Netlify helped kick off a modern approach to hosting, especially for static sites and JAMstack-style architectures. But if you're building an app that also depends on a backend, managing that split becomes a real part of your workflow.

With Appwrite Sites, you get an alternative that treats frontend deployment as part of a full-stack environment. Instead of connecting your frontend to a separate backend via API tokens and CORS rules, Sites lives in the same platform as your database, storage, authentication, and functions.

In this article, we'll break down how Appwrite Sites and Netlify compare, from framework support and SSR, to environment variables, deployment flows, and the developer experience of hosting modern apps.

What is Appwrite Sites?

Appwrite Sites is a deployment and hosting platform within the Appwrite ecosystem. It supports both static sites and server-side rendered applications, with built-in Git integration, preview deployments, custom domain support, and container-based SSR.

Because it's part of the same platform as Appwrite's backend services, like auth, database, storage, and cloud functions, you don't need to stitch together separate providers or manage secrets manually. Your frontend and backend live in the same project, with a shared security model and automatically scoped environment variables.

Sites supports a wide range of frameworks, from Next.js and Nuxt to Astro, SvelteKit, Angular, Remix, and Flutter Web. For static apps, you can deploy via Git or manually upload a .tar.gz. For SSR, Sites runs your app in a container with runtime access to secrets and Appwrite SDKs.

Netlify and the JAMstack model

Netlify pioneered the JAMstack movement, where apps are decoupled into static frontends + serverless functions + external APIs. That model works especially well for sites that are mostly static, with light dynamic behavior: marketing pages, documentation, or e-commerce frontends backed by third-party services.

Netlify offers automatic builds from Git, preview URLs, branch-based environments, edge functions, form handling, and even built-in identity support (though limited in scope). It also includes a CLI and plugin ecosystem for customizing builds.

But while it's flexible, it's not tightly integrated. You still need to bring your own database, authentication, file storage, and backend logic, and manage how your frontend connects to all of it.

If you're building a simple frontend, Netlify is fast and effective. But for applications where frontend and backend logic are deeply connected, managing those boundaries becomes the challenge.

Deployment workflows

Netlify

Netlify uses Git-based deployment as its primary model. You connect your GitHub, GitLab, or Bitbucket repository, and Netlify auto-detects your framework. Every push to a branch triggers a build, with a unique deployment URL.

Branch-based previews are automatically generated
Build settings can be customized via the UI or netlify.toml
Environment variables can be scoped to Production, Preview, and Dev
Rollbacks are supported
There's no drag-and-drop UI deployment option, manual deploys must go through the CLI

Netlify does provide build plugins, custom functions, and API routing, but you'll need to wire those up separately if you're using a custom backend.

Appwrite Sites

Appwrite Sites also supports Git-based deployment with preview environments:

You connect a GitHub repo to your Appwrite project
Framework detection sets defaults for build, install, and output
Pushes to the production branch deploy automatically
Every commit, branch, or pull request generates a unique URL for preview
All builds include downloadable artifacts
Manual deployments are supported via .tar.gz or drag-and-drop in the Appwrite Console

Rollbacks are instant and available through the UI. Because the deployment lives inside your Appwrite project, it inherits access to your backend services automatically, without needing to configure tokens, keys, or external origins.

This is especially helpful for teams working in mixed Git workflows, or solo developers who want a quick manual deploy option without setting up CI.

Framework support

Netlify supports most popular frontend frameworks, including Astro, Eleventy, SvelteKit, Nuxt, Next.js, and Angular. Most are treated as static frameworks unless you configure SSR explicitly using Netlify Functions or Edge Functions.

SSR support is more limited. While you can run serverless functions alongside your frontend, the integration varies depending on your framework. Next.js and Astro get the most complete support.

Appwrite Sites supports a similar set of frameworks, but adds SSR support via containers, which allows full runtime access to environment variables and Appwrite services:

Next.js – SSR and static
Nuxt – SSR and static
SvelteKit – SSR and static
Angular – SSR and static
Astro – SSR and static
Remix – SSR and static
Flutter Web – static only
Vanilla JS, Lynx, Analog, etc. – static

Each framework can be customized with its own build and install commands. If your framework isn't listed, you can use “Other” and specify custom config.

If you're using SSR with anything beyond Next.js or Astro, Appwrite Sites provides broader and more consistent support out of the box.

Hosting options: Static vs SSR

Both platforms support static and server-side rendered hosting, but their architectures differ significantly.

Netlify

Static: Content is pre-rendered and served from a global CDN
SSR: Pages are rendered using serverless or edge functions
Timeouts: Default timeout is 10s, up to 26s for Pro plans
Limitations: Memory and cold starts depend on function tier and region
Environment access: Functions get runtime env vars, but static content does not

Netlify's SSR works well for lightweight APIs and dynamic content, but lacks full access to services unless you add integrations or connect to external providers.

Appwrite Sites

Static: CDN-hosted HTML/CSS/JS, with build-time env vars
SSR: Full server-side rendering in isolated containers
Timeouts: Configurable up to 30s per request
Environment access: Both build-time and runtime variables are supported
Logging: Console output from SSR code is captured in logs

The container-based SSR model means you can use Appwrite's SDK at runtime, securely read secrets, and interact directly with databases, functions, or storage, all from your rendering logic.

If your SSR routes require access to auth tokens, protected storage, or custom logic, Appwrite's model gives you more control than Netlify's function-based execution.

Environment variables and secrets

Netlify uses a three-scope model, Production, Preview, Development, with env vars scoped accordingly. You define them in the dashboard or via the CLI, and they're injected at build or function runtime.

Appwrite Sites provides:

Project-wide variables shared across services
Site-specific variables
Secret variables (hidden after creation)
Built-in Appwrite variables (project ID, endpoint, region, etc.)
Automatic API key injection at build and runtime (for SSR)

You can define variables once in your Appwrite project and access them across deployments, functions, and services, without needing to sync values manually.

For example, instead of creating a token in Netlify and passing it to your frontend, Appwrite Sites automatically injects a scoped API key with access to your project, removing the need to manually rotate secrets or configure CORS.

Custom domains, CORS, and trust boundaries

Both platforms allow custom domains and HTTPS via auto-generated certificates.

Netlify:

Supports custom domains via DNS config
Wildcard subdomains and previews (e.g. .netlify.app)
Requires manual CORS configuration when connecting to external APIs

Appwrite Sites:

Supports custom domains via CNAME or NS records
Auto-generated domains for every branch and commit
Built-in CORS trust if your backend is hosted on Appwrite

Since Appwrite Sites and your backend live in the same project, deployed frontends are automatically recognized and trusted. You don't have to manually list frontend origins or manage preflight responses, Appwrite knows your Sites deployment is part of the same scope.

This eliminates one of the most common pitfalls in multi-platform deployments: CORS misconfigurations.

Logging and observability

Netlify provides basic logging:

Build logs for every deployment
Function logs for serverless execution
Analytics for traffic and latency (paid plans)

Appwrite Sites offers:

Build logs
Request logs (status code, path, duration, headers)
Console output for SSR apps
Log retention (24h on Free, 7d on Pro)
Optional log disabling (for performance-sensitive routes)

Appwrite's SSR logs include server-side console output, which is helpful when debugging SSR failures, auth edge cases, or unexpected rendering issues, without needing to integrate a third-party logging tool.

Security and isolation

Both platforms enforce HTTPS and offer secret management.

Appwrite adds additional safeguards:

Isolated containers for SSR deployments
Secrets not visible after creation
Automatic API key injection scoped to the current site
Project-based access controls
Preview deployment restrictions (e.g. team-only)

Since everything runs inside your Appwrite project, the surface area for misconfigurations is smaller. You're not exposing separate public APIs or managing external API keys, access happens within a single trusted environment.

Appwrite Sites vs Netlify: feature comparison

Feature	Appwrite Sites	Netlify
Static hosting	✅	✅
Server-side rendering	✅ (containers)	✅ (functions)
Git-based deployment	✅	✅
Manual deployment (UI)	✅	❌
Preview deployments	✅ (branch, PR, commit)	✅
Custom domains	✅ (CNAME + NS)	✅
Environment variables	✅ (build + runtime, project-wide)	✅ (scoped by env)
Secrets support	✅ (Option to hide after creation)	✅
Automatic API key injection	✅	❌
Auth, DB, storage integration	✅ (native)	❌ (external required)
SSR console logs	✅	Limited
CORS for Appwrite backend	✅ (auto-trusted)	❌ (manual config)
Timeout configuration	✅ (up to 30s, self-configurable)	✅ (10s default, requires support team on paid plans)

Final thoughts

Netlify is an excellent platform for static frontends and lightweight JAMstack sites. If you're building a marketing page, blog, or frontend that only talks to third-party APIs, it still delivers a clean and fast workflow.

But if your application needs more than that, auth flows, custom APIs, server-side logic, secure data access, etc., Appwrite Sites provides an integrated alternative. Instead of wiring together services across platforms, you keep your frontend and backend in one place, with fewer moving parts and tighter defaults.

Appwrite Sites is built for teams that want their frontends to do more, and for developers who want full control without unnecessary complexity.

How to optimize your Appwrite project for cost and performance

Ebenezer Don — Mon, 23 Sep 2024 09:02:42 +0000

As your Appwrite project scales, performance and resource management become critical, not just to keep your app running smoothly, but also to avoid unexpected usage spikes. While Appwrite is designed to scale effortlessly, it's important to proactively optimize your usage so you don't reach resource limits prematurely. Effective optimization helps reduce costs, improves performance, and enhances user experience without compromising on functionality.

This guide provides a detailed overview of techniques to optimize your Appwrite project, covering API request management, caching strategies, file compression, image optimization, and other methods to ensure your app performs well while staying within your desired resource limits.

1. Reducing API requests: Smart querying and consolidation

Every API request consumes resources, and when requests are made inefficiently, they can consume substantial resources and increase usage costs. Here are strategies to help reduce unnecessary API calls:

Efficient use of `listDocuments` with queries

In Appwrite, fetching multiple documents from a database is made easy with the listDocuments method. This method allows you to retrieve all documents in a collection or apply filters using the Query API. Instead of making multiple requests for each document, you can fetch only the relevant data with a single request.

For example, in a content management system where you need to load blog posts written by a particular author, rather than making individual requests for each document, use Appwrite's listDocuments method with a filter:

const blogPosts = await databases.listDocuments(
  '<DATABASE_ID>',
  '<COLLECTION_ID>',
  [Query.equal('author', 'Michael Scott')],
)

By fetching all the documents you need in one go and applying filters, you reduce the number of requests and improve performance. However, as we'll see in the next section, you should use the listDocuments method carefully to avoid fetching unnecessary data, else you might end up with a large dataset that could slow down your application.

Optimize pagination and filtering

For applications with large datasets (e.g., e-commerce platforms with thousands of products), retrieving all data at once can overwhelm your system. Use Appwrite’s pagination and filtering feature to only fetch what’s immediately needed.

For example, if you’re loading products from a database, instead of fetching all products, fetch them in batches using pagination.

const firstPage = await databases.listDocuments(
  '<DATABASE_ID>',
  '<COLLECTION_ID>',
  [
    Query.equal('author', 'Meredith Palmer'),
    Query.limit(20),
    Query.offset(0),// Fetch the first 20 records
  ],
)

const secondPage = await databases.listDocuments(
  '<DATABASE_ID>',
  '<COLLECTION_ID>',
  [
    Query.equal('author', 'JaneDoe'),
    Query.limit(20),
    Query.offset(20),// Fetch the next 20 records
  ],
)

This strategy will not only conserve bandwidth but will ensure that your queries return faster results, improving your user experience.

For more information on querying documents, the Appwrite Queries documentation provides detailed examples and options.

Utilizing Appwrite’s realtime API for data updates

When building real-time applications (e.g., chat apps or collaborative tools), polling APIs frequently can result in unnecessary usage and increased server load. Appwrite’s Realtime API solves this by allowing you to subscribe to events and receive updates in real time via WebSockets. This ensures that your app remains responsive without the need for constant polling.

For example, you can subscribe to file upload events in real-time:

const unsubscribe = client.subscribe('files', (response) => {
  if (response.events.includes('buckets.*.files.*.create')) {
    console.log('New file uploaded:', response.payload)
  }
})

In addition to handling real-time updates, Appwrite's Realtime API can help decide when further requests are needed. Instead of continuously fetching data to check for updates, you can create a versioning system.

Versioning Document: Create a document with a single column, version, to track updates.
Subscribe to Changes: Use the Realtime API to monitor changes in this document. If the version field updates, it signals that the data has changed and needs re-fetching.

Appwrite’s Realtime API supports multiple channels, such as files, account, and specific collections, ensuring updates from any part of your app. To learn more about the Realtime API, refer to the Appwrite Realtime documentation.

By using Appwrite's real-time feature, you drastically reduce API request overhead, especially for high-traffic apps like live dashboards or messaging platforms, while maintaining instant, event-driven updates.

2. Effective caching: Reducing redundant data fetching

Caching is one of the most important strategies for improving both performance and resource management in your Appwrite project. By caching frequently accessed data, you reduce the number of redundant requests sent to your Appwrite instance.

Client-side caching with localStorage or IndexedDB

For non-sensitive or rarely changing data, client-side caching can significantly reduce server load and improve application responsiveness. Use the browser’s localStorage or IndexedDB to store data that users frequently access, such as user settings, app configurations, or product lists.

For instance, in a to-do list app, user preferences (e.g., preferred task view) can be cached locally so that the app doesn’t need to retrieve this data from Appwrite on every page load.

// Cache user preferences in localStorage
localStorage.setItem('userPreferences', JSON.stringify(preferences))

// Retrieve user preferences from cache
const cachedPreferences = JSON.parse(localStorage.getItem('userPreferences'))

This reduces unnecessary API requests and allows for instant access to cached data, improving performance.

Optimized cache expiry and invalidations

Caching data on the client side is effective, but it must be combined with intelligent cache expiry strategies to avoid serving stale data. Ensure that the cache is invalidated and refreshed when necessary, such as when the data changes or after a certain time period.

// Cache with expiration (using localStorage)
const saveToCache = (key, data) => {
  const item = {
    data,
    expiry: Date.now() + 1000 * 60 * 60, // Cache for 1 hour
  }
  localStorage.setItem(key, JSON.stringify(item))
}

const getFromCache = (key) => {
  const cachedItem = localStorage.getItem(key)
  if (!cachedItem) return null

  const item = JSON.parse(cachedItem)
  if (Date.now() > item.expiry) {
    localStorage.removeItem(key) // Invalidate stale cachereturn null
  }

  return item.data
}

This ensures your users get up-to-date data while reducing the number of requests made to the server.

Server-side caching with Redis

Redis is a widely-used, high-performance in-memory data store that can be an excellent choice for server-side caching in your Appwrite projects. Redis can be deployed alongside your Appwrite backend to cache frequently accessed data, reducing the load on your Appwrite instance and speeding up response times for users.

For example, in an e-commerce application, you could cache product categories, prices, or frequently queried data in Redis. This way, instead of hitting the database for every request, your application can retrieve data directly from Redis, which significantly improves performance for repeated requests. You can learn more about Redis in the Redis documentation.

3. Optimizing file storage: Compression and efficient file delivery

Managing large files can be a significant source of resource consumption. Optimizing file storage and delivery can help keep storage costs down and ensure faster data transfers.

Bucket compression

One of the most important optimizations for file storage is bucket compression. Appwrite allows you to compress files in your buckets using either the gzip or zstd compression algorithms. Enabling compression reduces the file size and conserves storage space, which is particularly useful for large files and media-heavy apps.

Gzip is a widely-used compression algorithm that offers good compression ratios for many types of files.
Zstd (Zstandard) is a modern, high-performance compression algorithm that provides better compression efficiency and decompression speed compared to gzip, making it a great choice for high-performance applications.

To enable compression for a bucket, you can set this up via the Appwrite Console or programmatically using the SDK:

const promise = storage.createBucket('bucketId', 'bucketName', {
  compression: 'zstd',
})

Keep in mind that files larger than 20MB are not compressed, even if compression is enabled. This is done to prevent performance bottlenecks when handling large files. Enabling compression at the bucket level not only helps reduce storage usage but also speeds up file transfers by reducing the amount of data sent over the network.

Optimizing image delivery with the Preview API

Appwrite allows you to serve compressed and optimized versions of your images to reduce bandwidth usage and improve performance. You can use the preview endpoint to adjust image quality, resolution, format, and more, without needing to modify the original file. This is useful for serving responsive images on the web, where you might want to reduce file sizes for faster load times.

// Serve an optimized image preview
const optimizedImage = storage.getFilePreview(
  'bucketId', // The bucket ID where the file is stored
  'fileId',   // The file ID of the uploaded image
  800,        // Resize the width to 800px
  0,          // Keep the original height (aspect ratio preserved)
  'center',   // Crop the image centered if cropping is needed
  80,         // Set image quality to 80%
  0,          // No border
  '',         // No border color
  0,          // No border radius
  1,          // Full opacity
  0,          // No rotation
  '',         // No background color
  'webp',     // Convert the image to WebP format for better compression
)

While this example shows how to serve an optimized image preview, and will greatly improve load times, it will not affect the original file size in your storage. So if you want to save storage space, consider compressing and optimizing files at the time of upload. A good practice for image optimization is to use formats like WebP, which offer better compression than JPEG or PNG.

Optimizing file delivery with CDNs and regional project deployment

For improved file delivery performance, especially in media-heavy applications, you can leverage a domain-level CDN like Cloudflare. A CDN caches files and serves them from locations closer to your users, reducing load times and improving the overall experience without overburdening your Appwrite server.

In addition, deploying your Appwrite project in a region near your user base can further reduce latency. Currently, Appwrite supports the FRA (Frankfurt) region, which is great for users in Europe. We're also expanding to more regions soon, giving you even more options to optimize performance based on your audience's location.

By combining CDNs and regional project deployments, you can enhance file delivery speeds, reduce latency, and ensure a more responsive user experience.

4. Using serverless functions for optimized workflows

Serverless functions in Appwrite are a powerful tool for optimizing resource usage. Instead of handling complex, resource-heavy operations on the client or in your core backend, offload these tasks to serverless functions that can execute asynchronously and on-demand.

Tasks like generating reports, processing data, or transforming files can be offloaded to serverless functions. This approach frees up the client and backend from performing expensive computations and ensures that heavy workloads don’t slow down your core application.

5. Setting up usage limits, alerts, and budget controls

Proactively managing your resource usage in Appwrite is key to avoiding unexpected overages and optimizing costs. Appwrite offers built-in tools for setting up usage alerts and budget controls to help developers manage their consumption.

Budget controls

You can also enable budget alerts to monitor your spending and prevent unexpected charges. For teams managing larger projects or multiple clients, setting budget limits ensures you stay within financial expectations.

To configure budget alerts, start by navigating to the Appwrite Cloud Console, then go to the Organisation section and select Billing. Here, you’ll find options to manage your budget. You can set a budget cap to define a hard limit on your spending, and in the Budget Alerts section, you can enable notifications that trigger when your spending reaches a certain threshold. This ensures you are alerted before exceeding your desired budget.

6. Monitoring and scaling your Appwrite project

Appwrite handles scalability efficiently, particularly in its cloud environment. Appwrite Cloud automatically scales resources as needed, ensuring that your application can handle increased traffic or workloads without requiring manual intervention. This automatic scaling allows you to focus on building your app, while Appwrite dynamically adjusts the resources behind the scenes to maintain optimal performance during traffic spikes.

While this is a significant advantage of using Appwrite Cloud, self-hosted instances also provide flexibility for custom scaling configurations. By monitoring your Appwrite project’s resource usage, you can identify bottlenecks, optimize your app, and scale horizontally as needed.

Automatic scaling in Appwrite

Appwrite's infrastructure is built on top of Docker, which allows for containerized scaling. Each service in Appwrite is containerized, meaning services like databases, storage, or functions can be scaled horizontally as demand increases. This happens automatically in the cloud version of Appwrite, making it easier for developers to handle surges in user traffic without experiencing downtime or performance degradation. For self-hosted Appwrite, scaling is also possible but requires setting up and managing Docker containers manually.

In Appwrite’s cloud environment, you don’t have to worry about manually configuring load balancers or managing server instances to scale your application. Appwrite automatically distributes workloads, ensuring smooth operation regardless of traffic volumes.

Monitoring resource usage

Appwrite provides built-in monitoring to help track API usage, database operations, storage, and other key metrics. This monitoring allows you to identify potential inefficiencies, such as high API request volumes or unnecessary data fetches, before they escalate into larger issues. While Appwrite handles automatic scaling, regular monitoring can help you optimize your application to avoid overuse of resources and prevent unnecessary costs.

You can monitor your Appwrite project's performance via the dashboard, which gives insights into your API request count, database operations, and storage usage. This data helps you manage your plan limits more effectively and optimize your app to avoid unexpected scaling needs.

Horizontal scaling

For self-hosted environments, Appwrite can be scaled horizontally by replicating containers across multiple servers. Stateless containers like those running functions or workers can be easily replicated to distribute workloads. However, for stateful services like databases, manual scaling configurations may be required.

Horizontal scaling ensures that the load is distributed evenly across multiple instances, making your application more resilient during high-traffic periods.

Conclusion

Optimizing your Appwrite project ensures you not only provide a better experience to your users but also prevent unnecessary resource overuse. By applying the techniques discussed in this guide, you can keep your project running smoothly while staying within your plan limits.

These optimizations aren’t just about cost savings—they are about making your app more scalable, efficient, and reliable as it grows. Rather than waiting until you hit plan limits, taking a proactive approach builds trust and ensures your users always experience the best possible performance, even as your app scales.

Forem: Ebenezer Don

Your Experience Is Your Biggest AI Advantage

The Plausibility Problem

The Questions You Never Think to Ask

The Editing Shift

The Pipeline Problem

Using It or Losing It

How to host SSR web apps on Appwrite Sites

What is SSR, and why does it matter?

Hosting an SSR app on Appwrite Sites

1. Open the Appwrite Console

2. Configure your deployment settings

Framework-specific SSR tips

Next.js

SvelteKit

Nuxt

Angular (with SSR)

Astro

Remix

Analog (Angular meta-framework)

How to check or change framework instructions

Final thoughts

What is SSR, and why does it matter?

Hosting an SSR app on Appwrite Sites

1. Open the Appwrite Console

2. Configure your deployment settings

Framework-specific SSR tips

Next.js

SvelteKit

Nuxt

Angular (with SSR)

Astro

Remix

Analog (Angular meta-framework)

How to check or change framework instructions

Final thoughts

Appwrite Sites vs Vercel: Choosing the right web hosting platform

What is Appwrite Sites?

Integrated, full-stack hosting with Sites

Deployment workflows

Deploying on Vercel

Deploying on Appwrite Sites

Framework support

Hosting options: Static vs SSR

Static hosting

Server-side rendering

Environment variables

Environment variables on Vercel

Environment variables on Appwrite Sites

Domains, CORS, and routing

Logging and monitoring

Performance and timeouts

Security and isolation

When to choose Appwrite Sites

Appwrite Sites vs Vercel: feature comparison

Final thoughts

Appwrite Sites vs Netlify: Choosing the right web hosting platform

What is Appwrite Sites?

Netlify and the JAMstack model

Deployment workflows

Netlify

Appwrite Sites

Framework support

Hosting options: Static vs SSR

Netlify

Appwrite Sites

Environment variables and secrets

Custom domains, CORS, and trust boundaries

Logging and observability

Security and isolation

Appwrite Sites vs Netlify: feature comparison

Final thoughts

How to optimize your Appwrite project for cost and performance

1. Reducing API requests: Smart querying and consolidation

Efficient use of listDocuments with queries

Optimize pagination and filtering

Utilizing Appwrite’s realtime API for data updates

2. Effective caching: Reducing redundant data fetching

Client-side caching with localStorage or IndexedDB

Optimized cache expiry and invalidations

Efficient use of `listDocuments` with queries