diff --git a/.env.example b/.env.example index ccf399ed51..d388fe541c 100644 --- a/.env.example +++ b/.env.example @@ -2,6 +2,7 @@ PUBLIC_APPWRITE_COL_MESSAGES_ID= PUBLIC_APPWRITE_COL_THREADS_ID= PUBLIC_APPWRITE_DB_MAIN_ID= PUBLIC_APPWRITE_FN_TLDR_ID= +PUBLIC_APPWRITE_DASHBOARD= PUBLIC_APPWRITE_ENDPOINT= PUBLIC_APPWRITE_PROJECT_ID= PUBLIC_APPWRITE_PROJECT_INIT_ID= diff --git a/README.md b/README.md index cff29e0354..5895025ccd 100644 --- a/README.md +++ b/README.md @@ -15,7 +15,7 @@ The Appwrite Website has been built with the following frameworks: ## Development -_If this is your first time setting up the repository, please run `pnpm install` inside the repo's directory._ +_If this is your first time setting up the repository, please run `pnpm install` inside the repo's directory and create a `.env` file based on `.env.example`._ To get the repo up and running in your local environment, use the following command: diff --git a/src/routes/docs/+page.svelte b/src/routes/docs/+page.svelte index 85cd851d89..4bdc1e66e3 100644 --- a/src/routes/docs/+page.svelte +++ b/src/routes/docs/+page.svelte @@ -270,6 +270,28 @@

Respond to server events in realtime.

+
  • + + + +

    Network

    +

    + Global infrastructure for serverless compute. +

    +     +
    • diff --git a/src/routes/docs/Sidebar.svelte b/src/routes/docs/Sidebar.svelte index d94295aad3..adcbf800e9 100644 --- a/src/routes/docs/Sidebar.svelte +++ b/src/routes/docs/Sidebar.svelte @@ -25,7 +25,7 @@ icon: 'icon-cog' }, { - label: 'API reference', + label: 'API references', href: '/docs/references', icon: 'icon-document', isParent: true @@ -65,6 +65,13 @@ icon: 'icon-folder', isParent: true }, + { + label: 'Network', + href: '/docs/products/network', + icon: 'icon-share', + isParent: true, + new: true, + }, { label: 'AI', href: '/docs/products/ai', diff --git a/src/routes/docs/advanced/platform/+page.markdoc b/src/routes/docs/advanced/platform/+page.markdoc index a7ad6c097a..7bf2ff71c5 100644 --- a/src/routes/docs/advanced/platform/+page.markdoc +++ b/src/routes/docs/advanced/platform/+page.markdoc @@ -7,7 +7,7 @@ description: Appwrite is a development platform designed to adapt you unique use Appwrite is a development platform designed to adapt your unique use cases. Appwrite provides features that help you maintain, scale, and integrate Appwrite with other platforms. -# Integration +# Integration {% #integration %} Appwrite is designed to integrate with both frontend and backend apps. Learn about advanced integrations and API response codes. @@ -28,7 +28,7 @@ Learn about response codes and errors returned by Appwrite APIs. {% /cards_item %} {% /cards %} -# Access control +# Access control {% #access-control %} Appwrite is secure by default and provides tools for you to manage access control and prevent abuse. @@ -51,7 +51,7 @@ Create and manage API keys use by Server SDKs. {% /cards_item %} {% /cards %} -# Plans +# Plans {% #plans %} Learn which plan best suits your organization and how to manage billing. @@ -73,7 +73,7 @@ Coming soon. {% /cards_item %} {% cards_item href="/docs/advanced/platform/enterprise" title="Enterprise" %} -Coming soon. +Learn about Appwrite Enterprise, for large organizations with advanced needs. {% /cards_item %} {% cards_item href="/docs/advanced/platform/oss" title="Open source" %} @@ -81,7 +81,7 @@ Appwrite provides special plans for open source projects. {% /cards_item %} {% /cards %} -# Configuration +# Configuration {% #configuration %} Configure custom domains and customize communication templates. diff --git a/src/routes/docs/advanced/platform/enterprise/+page.markdoc b/src/routes/docs/advanced/platform/enterprise/+page.markdoc index 0119c6cfb2..1e876c784c 100644 --- a/src/routes/docs/advanced/platform/enterprise/+page.markdoc +++ b/src/routes/docs/advanced/platform/enterprise/+page.markdoc @@ -7,4 +7,4 @@ description: How Appwrite can accelerate enterprise development teams and provid Enterprise development teams face unique challenges and have unique needs. Appwrite can provide tailored solutions for enterprise customers with custom hosting, training, and support needs. -If you're interested to learn about what Appwrite can do for your enterprise development teams, [contact us](https://appwrite.io/contact-us) for more details. \ No newline at end of file +If you're interested to learn about what Appwrite can do for your enterprise development teams, [contact us](https://appwrite.io/contact-us/enterprise) for more details. \ No newline at end of file diff --git a/src/routes/docs/advanced/platform/webhooks/+page.markdoc b/src/routes/docs/advanced/platform/webhooks/+page.markdoc index 75ddd571aa..a133a28a3a 100644 --- a/src/routes/docs/advanced/platform/webhooks/+page.markdoc +++ b/src/routes/docs/advanced/platform/webhooks/+page.markdoc @@ -6,7 +6,7 @@ description: Leverage webhooks in the Appwrite platform for real-time updates. L Webhooks allow you to build or set up integrations which subscribe to certain events on Appwrite. When one of those events is triggered, we'll send an HTTP POST payload to the webhook's configured URL. Webhooks can be used to purge cache from CDN, calculate data or send a Slack notification. You're only limited by your imagination. -# Add your webhook {% #addWebhook %} +# Getting started {% #getting-started %} You can set your webhook by adding it from your Appwrite project dashboard. You can access your webhooks settings from your project dashboard or on the left navigation panel. Click the 'Add Webhook' button and choose your webhook name and the events that should trigger it. You can also set an optional basic HTTP authentication username and password to protect your endpoint from unauthorized access. diff --git a/src/routes/docs/products/network/+layout.svelte b/src/routes/docs/products/network/+layout.svelte new file mode 100644 index 0000000000..524bdf72f6 --- /dev/null +++ b/src/routes/docs/products/network/+layout.svelte @@ -0,0 +1,72 @@ + + + + + + diff --git a/src/routes/docs/products/network/+page.markdoc b/src/routes/docs/products/network/+page.markdoc new file mode 100644 index 0000000000..5f4e35e87d --- /dev/null +++ b/src/routes/docs/products/network/+page.markdoc @@ -0,0 +1,68 @@ +--- +layout: article +title: Network +description: Discover Appwrite's network architecture with global regions, edge nodes, and optimized routing. Explore how it ensures low latency, reliable performance, and scalable infrastructure for modern applications. +--- + +Appwrite's network is designed to deliver low-latency, high-performance experiences for developers and end-users alike. It leverages a robust Content Delivery Network (CDN) with edge locations across multiple regions to ensure fast and reliable data delivery. + +With distributed infrastructure and multiple deployment regions, Appwrite enables developers to build globally scalable applications while maintaining data sovereignty. Its architecture integrates seamlessly with APIs, storage, and databases, optimizing both speed and availability. + +[NETWORK MAP HERE - REGIONS, EDGES AND POPs INCLUDED] + +# Components {% #components %} +The Appwrite Network is composed of multiple components that work together to deliver a seamless experience for developers and end-users. These components include: + +{% cards %} +{% cards_item href="/docs/products/network/regions" title="Regions" %} +Multi-region deployments for geo-redundancy, compliance and low-latency. +{% /cards_item %} +{% cards_item href="/docs/products/network/edges" title="Edges" %} +Edge nodes for fast request processing and reduced round-trip times. +{% /cards_item %} +{% cards_item href="/docs/products/network/cdn" title="CDN" %} +Global infrastructure for optimized routing, enabling faster and more consistent data delivery. +{% /cards_item %} +{% cards_item href="/docs/products/network/endpoints" title="Endpoints" %} +Dedicated endpoints for region-specific, edge, and compute workloads. +{% /cards_item %} +{% /cards %} + +## Region vs Edge {% #region-vs-edge %} + +In Appwrite, Regions are where all your core data and services live. This includes your databases, auth, functions, messaging, and storage. Regions are the source of truth, handling heavy workloads and ensuring your application runs reliably while keeping your data compliant with local regulations. + +Edges are about speed. They process requests closer to your users using smart geo-routing, reducing latency by handling compute tasks at the nearest edge location. Edges are perfect for serving cached content, executing lightweight computations, and optimizing user interactions. + +{% info title="Where to execute?" %} +The Appwrite Network is designed for flexibility. You can choose to run your serverless compute workload in your project's home region by using the `[ID].[REGION].appwrite.run` endpoint, or on the edge using the `[ID].appwrite.network` endpoint. Both your region and edge endpoints can be customized to use your own custom domain. +{% /info %} + +# Architecture {% #architecture %} + +Appwrite's network is designed to provide a balance between centralized compute and distributed delivery: +- Regions: Core infrastructure and data resides in global regions, where all services like databases, auth, functions, messaging, and storage operate. These regions ensure data sovereignty, compliance, and high availability for critical workloads. +- Edges: Distributed edge locations process requests closer to end-users, leveraging smart geo-routing to minimize latency. These edge handle tasks like caching, static content delivery, and lightweight compute to improve performance. +- Private Routing: Data moves between edge nodes and regions through optimized, low-latency connections to ensure fast and reliable communication. + +This setup separates heavy backend processing in regions from latency-sensitive tasks at the edge, enabling efficient handling of global workloads with minimal performance trade-offs. + +# Features {% #features %} + +{% cards %} +{% cards_item href="/docs/products/network/ddos" title="DDoS mitigation" %} +Protects against distributed denial-of-service attacks, ensuring uninterrupted access. +{% /cards_item %} +{% cards_item href="/docs/products/network/tls" title="Transport Layer Security (TLS)" %} +Encrypts data in transit for secure and private communication. +{% /cards_item %} +{% cards_item href="/docs/products/network/tls" title="Web Application Firewall (WAF)" %} +Shields applications from common web vulnerabilities and attacks on the application layer. +{% /cards_item %} +{% cards_item href="/docs/products/network/compression" title="Compression" %} +Reduces data size in transit to improve transfer speed and efficiency. +{% /cards_item %} +{% cards_item href="/docs/products/network/caching" title="Caching" %} +Stores frequently accessed data for faster retrieval and lower latency. +{% /cards_item %} +{% /cards %} \ No newline at end of file diff --git a/src/routes/docs/products/network/caching/+page.markdoc b/src/routes/docs/products/network/caching/+page.markdoc new file mode 100644 index 0000000000..3efd96ef2f --- /dev/null +++ b/src/routes/docs/products/network/caching/+page.markdoc @@ -0,0 +1,61 @@ +--- +layout: article +title: Caching +description: Learn how Appwrite uses smart caching strategies at the region, edge, and CDN levels to optimize performance and protect dynamic APIs, with advanced options for enterprise customers. +--- + +Appwrite employs a multi-layered caching approach to enhance the performance of your applications. By utilizing caching at the **region**, **edge**, and **CDN** levels, Appwrite ensures faster response times, optimized resource usage, and efficient handling of dynamic workloads. + +# Region-level {% #region-level %} + +At the region level, Appwrite provides smart in-memory caching for various resources: + +- **Documents**: Frequently accessed documents are cached in memory and automatically purged when updated, ensuring data consistency without manual intervention. +- **Storage files**: Frequently accessed files are cached in memory to reduce disk reads and improve performance. +- **Image transformations**: Processed images (e.g., resized or converted) are cached in memory for faster repeated requests, reducing processing overhead. + +Region-level caching is tightly integrated with Appwrite's APIs, optimizing performance while preserving data integrity. + +# Edge-level {% #edge-level %} + +At the edge, Appwrite employs smart caching for specific use cases: + +- **Compute builds**: Caches build artifacts for faster deployments and reduced latency during function executions. +- **Cold starts**: Pre-loads frequently accessed resources, reducing latency for new requests and improving application responsiveness. + +Edge-level caching complements region-level caching, ensuring optimal performance for globally distributed applications. + +# Private caching {% #cdn-caching %} +Appwrite's CDN layer includes **private caching**, a caching strategy designed to handle the dynamic and permission-sensitive nature of Appwrite's APIs and resources securely. + +**What is private caching?** + +In the HTTP context, private caching allows responses to be cached but ensures they are only served to the specific user or client that requested them. This is achieved using HTTP headers that control caching behavior. For example: + +- `Cache-Control: private, max-age=3600` + Indicates that the response can be cached, but only in a private cache (e.g., the user's browser). + +- `Cache-Control: no-store` + Ensures that no part of the response is cached, useful for highly sensitive or frequently changing data. + +- `Vary: Authorization` + Signals that the cached response varies based on the `Authorization` header, ensuring permission-specific responses are cached and served appropriately. + +**Why use private caching?** + +Appwrite's APIs often deliver personalized or restricted content based on user roles and permissions. Private caching ensures: + +- **Security**: Sensitive resources are securely cached and only served to the correct user. +- **Permission awareness**: API responses are tailored to each user's permissions, ensuring consistent behavior. +- **Performance**: By caching user-specific responses, private caching reduces backend load while maintaining secure and accurate data delivery. + +This approach prevents the accidental exposure of user-specific or restricted data through shared caches while still enabling performance optimizations where possible. + +# Caching rules {% #custom-caching %} + +Enterprise customers can collaborate with their Appwrite success manager to define custom caching rules tailored to their applications. This includes: +- Setting custom caching durations for specific resources. +- Defining exclusion rules for sensitive or frequently changing data. +- Optimizing cache invalidation strategies for complex workflows. + +For more information on upgrading to the enterprise plan, [contact sales](https://appwrite.io/contact-us/enterprise). \ No newline at end of file diff --git a/src/routes/docs/products/network/cdn/+page.markdoc b/src/routes/docs/products/network/cdn/+page.markdoc new file mode 100644 index 0000000000..de627f4a57 --- /dev/null +++ b/src/routes/docs/products/network/cdn/+page.markdoc @@ -0,0 +1,25 @@ +--- +layout: article +title: Content Delivery Network (CDN) +description: Learn about Appwrite's CDN, designed to optimize content delivery with compression, and edge optimization for improved performance and reduced latency. +--- + +Appwrite's CDN (Content Delivery Network) is a globally distributed system designed to enhance the speed, reliability, and security of your application's content delivery. With points of presence (PoPs) in over 120 cities worldwide, the CDN ensures low latency and consistent performance for users, no matter their location. + +[POPS MAP HERE - NO EDGES OR REGIONS INCLUDED] + +# Key features {% #key-features %} + +- Global coverage: Fast access to content for users across continents through over 120 PoPs worldwide. Available on all projects. +- Reduced latency: By caching static content at edge nodes, the CDN minimizes the distance between the user and the requested data, significantly reducing latency. +- Dynamic content: The CDN supports both static and dynamic content delivery, seamlessly integrating with backend services hosted in Appwrite regions. +- Content optimization: Appwrite's CDN uses advanced compression algorithms to reduce data transfer sizes, further improving delivery times. +- High availability: Distributed edge nodes and redundant routing ensure that content remains accessible even during regional outages or high traffic loads. + +# Design {% #design %} + +- Caching strategy: Configurable cache policies for control over TTL and content invalidation. +- Secure delivery: All content is transmitted over TLS for secure, encrypted connections. +- Integration: The CDN works seamlessly with the Appwrite edges and backend regions, providing a unified experience for developers. + +By combining global caching, smart routing, and content optimization, the Appwrite CDN is built to handle the demands of modern, high-performance applications. \ No newline at end of file diff --git a/src/routes/docs/products/network/compression/+page.markdoc b/src/routes/docs/products/network/compression/+page.markdoc new file mode 100644 index 0000000000..f588bda1d2 --- /dev/null +++ b/src/routes/docs/products/network/compression/+page.markdoc @@ -0,0 +1,110 @@ +--- +layout: article +title: Compression +description: +--- + +Appwrite is leveraging compression algorithms to both boost the performance of your app and to reduce and optimize bandwidth and storage costs for Appwrite developers. This page provides an in-depth explanation of the compression algorithms supported by Appwrite for API responses, image transformations, and storage buckets. + +# API {% #api %} + +Appwrite supports two primary algorithms for text-based responses: **Brotli** and **Gzip**. These algorithms are integral for improving data transfer speeds across the HTTP based APIs, especially when dealing with textual content, which tends to be highly compressible. + +- **Brotli**: Chosen for its superior compression efficiency, especially for smaller files. Brotli performs best in HTTP/2 and HTTP/3 environments, where smaller payloads mean faster transfers and lower bandwidth consumption. Its efficiency also allows for quicker decompression on modern clients. +- **Gzip**: Gzip remains supported for backward compatibility and for clients that do not yet fully support Brotli. Though Gzip has a lower compression ratio compared to Brotli, it is still a reliable fallback for older browsers and HTTP/1.1 connections. +- **Zstd**: Zstd offers very high compression ratios and significantly faster decompression speeds, making it ideal for server-to-server communication and large data transfers. While its browser support is limited compared to Brotli and Gzip, Zstd excels in scenarios where performance and efficiency are critical for backend processes. + +## Conditions {% #conditions %} +Compression in Appwrite is triggered dynamically based on several conditions. This ensures that we only compress data when it is beneficial for performance and that we avoid unnecessary overhead for small payloads or non-textual data. + +1. **MIME types**: Only text-based MIME types are eligible for compression. These include: +- `text/plain` +- `text/css` +- `text/javascript` +- `application/javascript` +- `text/html` +- `application/json` +- `image/svg+xml` +- `application/xml+rss` + +This selection is based on the nature of these content types being easily compressible, resulting in significant size reductions without loss of information. + +2. **Response size**: Compression is applied when the size of the response exceeds **1KB**. This threshold has been selected based on testing to minimize the CPU overhead of compression for small payloads, where the gains in bandwidth reduction are negligible. + +3. **Client-side support**: Clients indicate their support for specific compression algorithms via the `Accept-Encoding` HTTP header. Appwrite prioritizes compression based on the following client-provided values: + - `br`: Indicates support for Brotli compression. + - `zstd`: Indicates support for Zstandard compression. + - `gzip`: Indicates support for Gzip compression. + - `identity`: Indicates that no compression is supported or requested. + +## Prioritizations {% #prioritizations %} +Appwrite prioritizes Brotli over Gzip due to Brotli’s more efficient compression ratio, especially when dealing with text-based content like HTML, CSS, and JSON files. Brotli uses a sliding window dictionary that results in higher compression ratios at slower speeds, but in an HTTP/2 or HTTP/3 environment, the benefits outweigh the costs. Gzip is used as a fallback when Brotli is not supported by the client. + +| Algorithm {% width=120 %} | Ratio {% width=120 %} | Browsers | Notes | +|-----------|-------------------|-----------------------|---------------------------------------------------| +| Brotli | High | All modern browsers | Optimal for small text files; highly efficient. | +| Gzip | Medium | Universal | Broad compatibility with older and modern clients.| +| Zstd | Very High | Limited | High performance with faster decompression speeds, ideal for server-to-server communication. | +| Identity | None | Universal | Used when no compression is applied or supported. | + +## Enabling compression {% #enabling-compression-1 %} +Compression is enabled by default for eligible API responses in Appwrite. You do not need to manually enable it; Appwrite dynamically selects the best algorithm based on the client’s `Accept-Encoding` headers and the MIME type of the response. + +# Image transformations {% #image-transformations %} +Appwrite's API supports the [compression of image files](/docs/products/storage/images) during manipulation and preview generation. The primary reason for compressing images is to minimize file sizes while maintaining visual quality, thus reducing both bandwidth usage and storage costs. + +Appwrite supports both legacy and modern image formats, including: + +- **PNG**, **JPEG**, **GIF**: These are traditional formats supported for compatibility reasons. PNG supports lossless compression, while JPEG and GIF are lossy but optimized for small sizes. +- **WebP**: A modern format developed by Google, offering better compression rates than JPEG, PNG, or GIF while maintaining equivalent quality. +- **AVIF**: The most modern image format supported by Appwrite, which offers even higher compression rates than WebP. AVIF is based on the AV1 video codec and is optimized for high-performance image rendering with minimal bandwidth use. + +## Supported API endpoints {% #supported-api-endpoints %} + +Appwrite applies image compression exclusively through the Image Preview API. This ensures that any dynamic operations, such as generating previews, resizing images, or converting between formats, are optimized for performance and reduced file size. Images uploaded through the Storage API remain in their original format and quality without automatic compression to preserve your source of truth. + +## Prioritization {% #prioritization %} + +Appwrite does not apply any image compression by default. Developers have full control over the output compression by specifying it in the query string when using the Image Preview API. This allows for precise customization to suit various use cases. + +Appwrite supports modern image formats like WebP and AVIF for their exceptional compression rates and compatibility with most browsers. While WebP is often the default choice for conversions, AVIF is recommended when seeking optimal performance and minimal file sizes. + +```javascript +import { Client, Storage } from "appwrite"; + +const client = new Client(); +const storage = new Storage(client); + +client + .setEndpoint('https://.cloud.appwrite.io/v1') // Your API Endpoint + .setProject('') // Your project ID +; + +const result = storage.getFilePreview( + 'photos', // bucket ID + 'sunset.png', // file ID + 1800, // width, will be resized using this value. + 0, // height, ignored when 0 + 'center', // crop center + '90', // slight compression + 5, // border width + 'CDCA30', // border color + 15, // border radius + 1, // full opacity + 0, // no rotation + 'FFFFFF', // background color + 'webp' // output jpg format +); + +console.log(result.href); +``` + +| Algorithm {% width=120 %} | Formats | Ratio {% width=120 %} | Notes | +| --------- | ----------------- | ----------------- | -------------------- | +| WebP | PNG, JPEG, GIF | High | Great balance of compression efficiency and visual quality | +| AVIF | PNG, JPEG, GIF | Best | Highest compression rate for modern use cases | +| JPEG | JPEG | Medium | Legacy support for lossy compression | +| PNG | PNG | Lossless | Necessary for lossless compression requirements | + +## Enabling compression {% #enabling-compression-2 %} +You can enable image compression through the **Image Preview API** by specifying the desired output format in API calls. For example, requesting a WebP or AVIF conversion automatically triggers Appwrite's compression algorithms to optimize the image size. diff --git a/src/routes/docs/products/network/ddos/+page.markdoc b/src/routes/docs/products/network/ddos/+page.markdoc new file mode 100644 index 0000000000..5d9b536626 --- /dev/null +++ b/src/routes/docs/products/network/ddos/+page.markdoc @@ -0,0 +1,33 @@ +--- +layout: article +title: DDoS mitigation +description: Learn how Appwrite protects your applications from Distributed Denial-of-Service (DDoS) attacks with built-in, always-on protection for all Appwrite Cloud plans. +--- + +Distributed Denial-of-Service (DDoS) attacks are one of the most common threats to online applications, aimed at overwhelming servers with malicious traffic to disrupt services. Appwrite provides robust, always-on DDoS protection across all Appwrite Cloud plans to ensure the reliability and security of your applications. + +Appwrite's network is designed to detect and mitigate malicious traffic before it reaches your application. Using a combination of automated filtering and intelligent traffic analysis, our DDoS protection: + +- Identifies and blocks large-scale attack patterns in real-time. +- Ensures legitimate traffic continues to flow uninterrupted. +- Prevents application downtime and minimizes performance impacts. + +# Design {% #design %} + +Appwrite's DDoS protection operates across multiple OSI layers to provide comprehensive coverage: + +- **Network Layer (Layer 3)**: Detects and mitigates large-scale attacks such as ICMP floods and UDP amplification. +- **Transport Layer (Layer 4)**: Protects against attacks like SYN floods and TCP-based exploits by identifying anomalous traffic patterns. +- **Application Layer (Layer 7)**: Blocks high-level attacks, such as HTTP floods, by filtering malicious requests while allowing legitimate user traffic. + +# Benefits {% #benefits %} + +- **Cost control**: Malicious traffic blocked by DDoS protection does not count towards your bandwidth or request usage, saving you from unnecessary charges. +- **Reliability**: Keeps your application online and responsive, even during attempted attacks. +- **Zero configuration**: DDoS protection is fully managed by Appwrite and requires no manual setup or maintenance. Protection is enabled by default on all Cloud plans. + +# Availability {% #availability %} + +DDoS mitigation is automatically enabled by default for all Appwrite Cloud plans, ensuring every application hosted on Appwrite benefits from this safeguard without additional costs. This includes: + +This protection is integrated directly into Appwrite's console, edge and region infrastructure, providing seamless coverage without requiring additional setup from developers. \ No newline at end of file diff --git a/src/routes/docs/products/network/edges/+page.markdoc b/src/routes/docs/products/network/edges/+page.markdoc new file mode 100644 index 0000000000..37408b7bf5 --- /dev/null +++ b/src/routes/docs/products/network/edges/+page.markdoc @@ -0,0 +1,52 @@ +--- +layout: article +title: Edges +description: Learn about Appwrite edges, where lightweight compute tasks like caching, request routing, and content delivery are handled. Understand how edges enhance performance by bringing operations closer to end-users. +--- + +Appwrite edges are strategically distributed locations designed to process requests closer to your users. These edge nodes handle latency-sensitive operations, such as caching, routing, and quick computations, to deliver faster, more efficient interactions while reducing the load on your application's core infrastructure. + +[EDGES MAP HERE - NO REGIONS OR POPs INCLUDED] + +{% info title="We're expanding!" %} +Currently, Appwrite's edge network includes 3 locations. We are actively working to expand the number of edge locations globally. New locations will be strategically prioritized to ensure the best possible global coverage and performance for all users. +{% /info %} + +# List {% #list %} + +Appwrite edges are globally distributed, ensuring low-latency interactions for users around the world. Here's a list of locations with active or upcoming edge support: + +| Location | Code{% width=120 %} | Status {% width=120 %} | +|---------------------|--------|-----------------| +| Frankfurt | FRA | Available | +| New York | NYC | Available | +| Sydney | SYD | Available | +| Singapore | SGP | 2025 | +| San Francisco | SFO | 2025 | +| Bangalore | BLR | 2025 | +| Amsterdam | AMS | 2025 | +| London | LON | 2025 | +| Toronto | TOR | 2025 | + +Edges complement Appwrite regions, working together to provide fast, reliable, and scalable application performance. + +# Routing {% #routing %} + +Appwrite's edges handle geo-aware routing to balance traffic across the network efficiently. When a user makes a request, it is directed to the nearest available edge node based on their geographic location. This ensures optimal performance by minimizing latency and distributing traffic evenly across edge nodes. + +Geo-aware routing helps handle high traffic loads by intelligently directing requests to the best-performing edge, reducing congestion and maintaining consistent response times. By leveraging this approach, Appwrite ensures that your application delivers fast and reliable experiences to users worldwide. + +{% info title="Edge vs Region" %} +Use an edge when compute needs to happen close to your users, like serving static content, doing local computation or data processing. Use a region when compute needs to happen closer to your data, such as frequent access to your Appwrite database or storage. +{% /info %} + +# Design {% #design %} + +Edges are optimized to reduce latency and improve user experience by processing operations closer to the source of requests. Key aspects include: + +- Geo-routing: Smart routing ensures user requests are served by the optimal edge node. +- Caching: Frequently accessed data is cached at edges to reduce round-trips to core regions. +- Lightweight compute: Handles quick, resource-efficient computations for real-time tasks. +- Optimization: The edge network planned locations are strategically designed with fewer, high-capacity edges to maximize cache efficiency and achieve higher cache-hit ratios. + +Edges enhance Appwrite's ability to deliver fast, reliable experiences by optimizing interactions and reducing latency for end-users. Together with regions, they create a robust infrastructure designed for modern, globally distributed applications. \ No newline at end of file diff --git a/src/routes/docs/products/network/endpoints/+page.markdoc b/src/routes/docs/products/network/endpoints/+page.markdoc new file mode 100644 index 0000000000..3f77eeb100 --- /dev/null +++ b/src/routes/docs/products/network/endpoints/+page.markdoc @@ -0,0 +1,55 @@ +--- +layout: article +title: Endpoints +description: Understand the differences between Appwrite's endpoints, including geo-balanced edges, region-specific services, and custom domains for compute processes. +--- + +Appwrite offers multiple endpoints to access its services, each designed to optimize specific aspects of performance, routing, and compute. Understanding these endpoints helps you determine the most efficient way to interact with your Appwrite project. + +# Edge {% #edge %} + +The **`appwrite.network`** domain provides geo-balanced endpoints that route traffic to the nearest edge node based on the user's geographic location. These endpoints are ideal for: + +- **Latency-sensitive operations**: Quickly serving cached content, routing requests, or performing lightweight edge computations. +- **Global traffic distribution**: Automatically balancing traffic across the edge network for consistent performance. + +Example: +- `https://[ID].appwrite.network` + +Use this endpoint when optimizing for low-latency and global availability is critical for your functions. + +# Region {% #region %} + +The **`[REGION].cloud.appwrite.io`** domain directs traffic specifically to the region hosting your Appwrite project's services. This endpoint ensures that requests are processed close to your core data and infrastructure, making it ideal for: + +- **Data-intensive operations**: Frequent access to databases, storage, authentication, and other region-hosted services. +- **Regulatory compliance**: Ensuring data residency requirements are met by targeting specific regions. + +Example: +- `https://fra.cloud.appwrite.io` +- `https://nyc.cloud.appwrite.io` + +Use this endpoint when direct access to region-specific infrastructure is required, this is the endpoint you will use to access your Appwrite API or if you want to execute functions directly from your Appwrite SDK. + +# Compute {% #compute %} + +The **`[ID].[REGION].appwrite.run`** domain is designed for running server-side functions and compute-heavy tasks directly in the region where your services are hosted. It supports custom domains for seamless integration into your workflows. The `appwrite.run` subdomains are auto-generated for each function you create. This endpoint is best suited for: + +- **Compute-Intensive Tasks**: Executing server-side functions, handling APIs, or processing asynchronous jobs. +- **Custom Domain Support**: Enabling custom domains for specific function endpoints. + +Examples: +- `https://fra.appwrite.run` +- `https://[custom-domain]` + +Use this endpoint for scenarios where compute needs to happen close to your data or for deploying APIs under your own domain. + +# Summary {% #summary %} + +| Endpoint | Use Case | +|--------------------------------------|------------------------------------------------------| +| `https://[ID].appwrite.network` | Geo-balanced edges for low-latency operations | +| `https://[REGION].cloud.appwrite.io` | Direct access to region services | +| `https://[ID].[REGION].appwrite.run` | Region-based compute and function execution | + +Knowing how these endpoints work helps you choose the right one for your needs, ensuring better performance and alignment with your application's compliance requirements. \ No newline at end of file diff --git a/src/routes/docs/products/network/regions/+page.markdoc b/src/routes/docs/products/network/regions/+page.markdoc new file mode 100644 index 0000000000..f77ca3ef69 --- /dev/null +++ b/src/routes/docs/products/network/regions/+page.markdoc @@ -0,0 +1,49 @@ +--- +layout: article +title: Regions +description: Learn about Appwrite regions, where core services like databases, auth, functons, sites and storage are hosted. Understand data sovereignty, fault isolation, and scalability for compliant, high-performance deployments +--- + +Appwrite regions are geographic locations where all your application's core infrastructure is deployed. Each region operates as an independent, highly available cluster, managing the storage, processing, and serving of your data and Appwrite services. + +[REGIONS MAP HERE - NO EDGES OR POPs INCLUDED] + +# List {% #list %} + +Appwrite is currently available in the following list of regions: + +| Region {% width=120 %} | Code{% width=120 %} | Endpoint | Status{% width=120 %} | +|---------------------|--------|-----------------------------------------|-----------------| +| Frankfurt | FRA | `https://fra.cloud.appwrite.io/v1` | Available | +| New York | NYC | `https://nyc.cloud.appwrite.io/v1` | Available | +| Sydney | SYD | `https://syd.cloud.appwrite.io/v1` | Available | +| Singapore | SGP | `coming soon` | Q1 2025 | +| San Francisco | SFO | `coming soon` | Q1 2025 | +| Bangalore | BLR | `coming soon` | Q2 2025 | +| Amsterdam | AMS | `coming soon` | Q2 2025 | +| London | LON | `coming soon` | Q2 2025 | +| Toronto | TOR | `coming soon` | Q2 2025 | + +Regions are designed to be entirely independent unless explicitly connected, which provides control over data replication and compliance. We're constantly working to add new regions to our network to provide developers with more options for deploying their applications. + +# Choosing a region {% #choosing-a-region %} + +Selecting a region impacts both your application’s performance and its compliance with local regulations. Regions are isolated from each other, so your data and services remain contained within the selected location. When choosing a region, consider proximity to your primary user base to reduce latency and improve response times. Additionally, ensure the region aligns with legal requirements for data residency and sovereignty specific to your application's domain. + +{% info title="Region vs Edge" %} +Use a region when compute needs to happen close to your data, such as frequent access to your Appwrite database or storage. Use an edge when compute needs to happen closer to your users, like serving static content, performing local computations, or handling data processing at the edge. +{% /info %} + + +# Design {% #design %} + +Regions are isolated environments designed for predictable performance and data security. Key aspects include: + +- Data storage: All data remains within the region and adheres to local data residency laws. +- Fault isolation: Each region is self-contained, so failures in one region do not impact others. +- Scalability: Resources within a region scale dynamically to meet application demands. +- Networking: Regions connect via secure, low-latency private networks. +- High availability: Redundant power, networking, and hardware configurations in data centers. +- Cache efficiency: Fewer, data-dense regions boost hit probability, ensuring popular content is readily available. + +Regions provide the foundation for running scalable, reliable applications with full control over data locality and compliance. \ No newline at end of file diff --git a/src/routes/docs/products/network/tls/+page.markdoc b/src/routes/docs/products/network/tls/+page.markdoc new file mode 100644 index 0000000000..920b0fd671 --- /dev/null +++ b/src/routes/docs/products/network/tls/+page.markdoc @@ -0,0 +1,31 @@ +--- +layout: article +title: Transport Layer Security (TLS) +description: Learn how Appwrite uses TLS to encrypt data in transit, ensuring secure and private communication between clients and servers. +--- + +Transport Layer Security (TLS) is a critical feature of the Appwrite Network, ensuring that all data exchanged between clients and servers is encrypted and secure. By using TLS, Appwrite protects sensitive information from interception, tampering, and unauthorized access during transit. + +TLS operates at the **transport layer** of the OSI model (Layer 4), encrypting all data before it is transmitted over the network. This includes securing HTTP traffic via HTTPS. When a client connects to Appwrite services, a TLS handshake is performed to establish a secure connection. This process ensures: + +- **Encryption**: Data is encrypted to prevent unauthorized access during transmission. +- **Integrity**: Ensures that data cannot be tampered with or altered. +- **Authentication**: Verifies the identity of the server to protect against impersonation or spoofing. + +# Key features {% #key-features %} + +1. **Modern protocols** + Appwrite supports TLS 1.2 and TLS 1.3, offering the latest in encryption standards and performance optimization. + +2. **Automatic certificates** + TLS certificates are automatically managed and renewed, ensuring that your applications always run on secure connections without manual intervention. + +3. **Strong ciphers** + Only strong, industry-standard cipher suites are used to ensure robust encryption. + +4. **End-to-end security** + TLS secures every connection in Appwrite's network, including communication between edge nodes and regions, protecting your data at every step. + +# Getting started {% #getting-started %} + +TLS is enabled by default on all Appwrite endpoints, requiring no additional configuration from developers. Simply use HTTPS when interacting with Appwrite services, and your data will be secured automatically. \ No newline at end of file diff --git a/src/routes/docs/products/network/waf/+page.markdoc b/src/routes/docs/products/network/waf/+page.markdoc new file mode 100644 index 0000000000..36c13c0dd7 --- /dev/null +++ b/src/routes/docs/products/network/waf/+page.markdoc @@ -0,0 +1,114 @@ +--- +layout: article +title: Web application firewall (WAF) +description: Appwrite's Web Application Firewall (WAF) provides enterprise-grade protection against web vulnerabilities like SQL injection, XSS, and DDoS attacks. +--- + +The Web Application Firewall (WAF) is a critical feature of the Appwrite Network, designed to protect applications from common web vulnerabilities and attacks. Available exclusively to enterprise customers, WAF can be configured through your Appwrite success manager to meet the specific security needs of your application. + +{% info title="Availability" %} +The WAF feature is available exclusively to enterprise customers as part of the Appwrite enterprise offering. Setup and configuration are managed through your dedicated Appwrite success manager, who ensures that the WAF aligns with your application's requirements and evolves with emerging security threats. +{% /info %} + +The WAF functions as a protective barrier at the application layer (Layer 7) of the OSI model, where it inspects and filters HTTP/HTTPS traffic in real-time. It is specifically designed to safeguard your application by analyzing request headers, payloads, and query strings to identify malicious patterns or anomalies. The WAF intercepts traffic before it reaches your application, blocking threats such as: + +- SQL injection: Malicious input targeting database queries is identified and neutralized by inspecting payloads and request parameters. +- Cross-site scripting (XSS): WAF detects and blocks scripts attempting to manipulate or steal client-side data through injection into the DOM or other contexts. +- Cross-site request forgery (CSRF): By analyzing session headers and request origins, the WAF ensures only legitimate actions are processed. +- DDoS attacks: Although primarily focused on Layer 7 attacks, the WAF works in tandem with other mitigation systems to handle floods of application-level requests. + +# Design {% #design %} + +1. **Traffic inspection** + The WAF analyzes all incoming HTTP/HTTPS requests in real-time, matching them against a dynamic set of security rules. + +2. **Threat mitigation** + Suspicious requests are blocked before they reach your application, ensuring uninterrupted service and secure user interactions. + +3. **Custom rules** + Enterprise customers can work with their success manager to define custom rules tailored to their specific application requirements. + +# Key features {% #key-features %} + +- Real-time protection: Continuous monitoring and blocking of malicious traffic. +- Customizable rulesets: Configure WAF policies to align with your application's unique architecture. +- Compliance support: Meet security standards and regulatory requirements by safeguarding sensitive data. +- Seamless integration: Fully integrated into the Appwrite network, ensuring optimal performance and low-latency security enforcement. + +# Getting started {% #getting-started %} + +If you're an enterprise customer, reach out to your success manager to enable WAF for your applications. They'll guide you through the setup process, help configure custom rules, and ensure your application is fully protected. + +For more information on upgrading to the enterprise plan, [contact sales](https://appwrite.io/contact-us/enterprise). + +## Configuration {% #configuration %} + +Appwrite's WAF is designed to adapt to the specific needs of your applications. Tailored rules and actions can be implemented to address evolving security threats and traffic patterns effectively. + +### Rules {% #rules %} + +The WAF supports the creation of fine-grained rules using logical expressions. These rules define how incoming traffic is inspected and handled. + +1. **Expression-based rules** + Use logical expressions to create granular filters for incoming requests. These expressions operate on HTTP request fields, headers, cookies, and metadata. + + Examples of configurable expressions: + - **URL matching**: Block or allow traffic based on URL patterns (e.g., `/v1/functions/*`). + - **Request method**: Filter traffic based on HTTP methods (e.g., `GET`, `POST`, `PUT`). + - **Header inspection**: Inspect headers like `User-Agent`, `Authorization`, or `X-Forwarded-For`. + - **Cookie validation**: Check for specific cookies or validate their values to identify bot or malicious traffic. + - **Rate limiting**: Match requests based on IP or session-level rate thresholds. + - **Geolocation rules**: Allow or block traffic based on the geographic location of the user. + +2. **Regular expressions (Regex)** + Use regex patterns for more advanced filtering, such as matching complex URL structures, payloads, or specific query parameters. + +3. **IP Filtering** + Define rules to block, allow, or challenge traffic from specific IP ranges or CIDR blocks. + +### Actions {% #actions %} + +Based on the defined rules, the WAF can perform various actions to handle traffic appropriately. + +1. **Allow** + Allows the request to pass through to the backend without modification. + +2. **Block** + Rejects the request entirely, responding with an appropriate HTTP status code (e.g., `403 Forbidden`). + +3. **Challenge** + Issues a challenge (e.g., CAPTCHA) to validate whether the request originates from a legitimate user. + +4. **Redirect** + Redirects the request to a specified URL. Useful for handling deprecated endpoints or re-routing unauthorized traffic. + +5. **Log** + Records the request in detailed logs for further analysis without altering the request flow. + +6. **Rate limiting** + Throttles traffic from specific IPs or sessions that exceed defined thresholds, reducing the risk of abuse or overload. + +7. **Modify request** + Dynamically alters request components, such as headers, query parameters, or cookies. + +### Examples {% #examples %} + +#### Blocking malicious bots +- **Expression**: Match requests with suspicious `User-Agent` strings or invalid headers. +- **Action**: Block or issue a CAPTCHA challenge to confirm legitimate traffic. + +#### Preventing SQL injection +- **Expression**: Match payloads or query strings containing SQL keywords like `SELECT`, `DROP`, or `--`. +- **Action**: Block the request and log it for analysis. + +#### Rate limiting by endpoint +- **Expression**: Limit requests to sensitive endpoints (e.g., `/login`) to prevent abuse. +- **Action**: Throttle or temporarily block repeated requests from the same IP. + +#### Geo-based blocking +- **Expression**: Match requests originating from specific regions or countries. +- **Action**: Block or redirect users to a region-specific notice page. + +#### Header enforcement +- **Expression**: Check for required headers (e.g., `Authorization`) on API requests. +- **Action**: Block requests missing critical headers. \ No newline at end of file diff --git a/src/routes/pricing/compare-plans.svelte b/src/routes/pricing/compare-plans.svelte index fc267317a0..3af112a66a 100644 --- a/src/routes/pricing/compare-plans.svelte +++ b/src/routes/pricing/compare-plans.svelte @@ -8,6 +8,7 @@ import { writable } from 'svelte/store'; import { fly } from 'svelte/transition'; import { classNames } from '$lib/utils/classnames'; + import Tooltip from '$lib/components/Tooltip.svelte'; type Table = { title: string; @@ -82,14 +83,14 @@ enterprise: 'Never' }, { - title: 'Organization Members', + title: 'Organization members', free: '1', pro: '1', scale: 'Unlimited', enterprise: 'Unlimited' }, { - title: 'Additional Organization members', + title: 'Additional members', free: '-', pro: '$15 per member', scale: '$0', @@ -220,7 +221,7 @@ { title: 'Dedicated databases', free: '-', - pro: 'Coming Soon', + pro: 'Coming soon', scale: 'Coming soon', enterprise: 'Coming soon' } @@ -272,8 +273,8 @@ { title: 'Additional executions', free: '-', - pro: '$2 per 1 Million', - scale: '$2 per 1 Million', + pro: '$2 per 1m', + scale: '$2 per 1m', enterprise: 'Custom' }, { @@ -297,7 +298,7 @@ enterprise: 'Custom' }, { - title: 'Additional concurrent connections', + title: 'Additional connections', free: '-', pro: '$5 per 1,000', scale: '$5 per 1,000', @@ -312,6 +313,68 @@ } ] }, + { + title: 'Network', + rows: [ + { + title: 'Edge compute', + free: true, + pro: true, + scale: true, + enterprise: true + }, + { + title: 'DDoS mitigation', + free: true, + pro: true, + scale: true, + enterprise: true + }, + { + title: 'Content delivery network', + free: true, + pro: true, + scale: true, + enterprise: true + }, + { + title: 'Content compression', + info: 'Support for brotli, zstd and gzip for text compression and webp for image compression', + free: true, + pro: true, + scale: true, + enterprise: true + }, + { + title: 'TLS encryption', + free: true, + pro: true, + scale: true, + enterprise: true + }, + { + title: 'Logs', + free: '-', + pro: '-', + scale: 'Coming soon', + enterprise: 'Coming soon' + }, + { + title: 'Firewall', + free: '-', + pro: '-', + scale: '-', + enterprise: 'Custom rules' + }, + { + title: 'WAF', + free: '-', + pro: '-', + scale: '-', + enterprise: 'Custom rules' + }, + ] + }, { title: 'Security', rows: [ @@ -347,22 +410,15 @@ title: 'Custom organization roles', free: '-', pro: '-', - scale: 'Coming Soon', - enterprise: 'Coming Soon' - }, - { - title: 'Network logs', - free: '-', - pro: '-', - scale: 'Coming Soon', - enterprise: 'Coming Soon' + scale: 'Coming soon', + enterprise: 'Coming soon' }, { title: 'Activity logs', free: '-', pro: '-', - scale: 'Coming Soon', - enterprise: 'Coming Soon' + scale: 'Coming soon', + enterprise: 'Coming soon' } ] }, @@ -583,7 +639,7 @@
    {row.title} - + {/if}
    {#each cols as col, index}