Add new blogs

src/routes/blog/post/agency-backend-standardization/+page.markdoc

@@ -0,0 +1,85 @@
+---
+layout: post
+title: "How agencies standardize backend stacks across clients"
+description: Why development agencies benefit from standardizing their backend stack and how to choose a platform flexible enough to serve diverse client needs.
+date: 2024-05-03
+cover: /images/blog/agency-backend-standardization/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+Running a development agency means context-switching constantly. One client needs an e-commerce platform, another needs a healthcare app, a third wants an internal operations tool. Each project has different requirements, but if each one also uses a different backend stack, you've built yourself an operational nightmare.
+
+The most efficient agencies solve this by standardizing. Not by forcing every project into the same shape, but by choosing a backend platform flexible enough to serve diverse client needs while being familiar enough that every developer on the team can hit the ground running.
+
+## The hidden cost of backend fragmentation
+
+When each client project uses a different backend technology, the costs compound quickly:
+
+- **Onboarding overhead.** A new developer joining the agency has to learn the stack for each active project before they can contribute. If Project A uses Firebase, Project B uses Supabase, and Project C uses a custom Rails API, that's three different mental models to maintain.
+- **Debugging across unfamiliar systems.** When something breaks in production on a project where the original developer has moved on, the team inherits a system they don't know well.
+- **No knowledge reuse.** Solutions built for one client (authentication flows, file upload handling, role-based access patterns) can't easily be reused across clients if the underlying platforms differ.
+- **Inconsistent security posture.** Different platforms have different security defaults. Standardizing means your security practices travel with your stack.
+- **Longer estimation and scoping.** When a developer scopes a new project on a familiar platform, they can estimate accurately. Unfamiliar platforms introduce risk that's hard to price.
+
+## What agencies actually need from a backend platform
+
+Agencies have a distinct set of requirements compared to product companies:
+
+- **Multi-tenancy or project isolation.** Client data must be isolated. Each project needs its own databases, storage, and access policies.
+- **Fast project setup.** Agencies bill by the hour. Spinning up a new backend environment in minutes rather than days is a real business advantage.
+- **Breadth of features.** Authentication, databases, file storage, serverless functions, and messaging in one platform means fewer vendors to manage per project.
+- **Self-hosting or data ownership options.** Enterprise and regulated clients sometimes require that their data not leave their controlled environment.
+- **Reasonable pricing at varying scale.** Agency clients range from early-stage startups to mid-market businesses. The backend platform needs to be economical at small scale and not punitive at medium scale.
+- **Good documentation and community.** Developers solve problems faster when the platform has thorough documentation and an active community.
+
+## How standardization works in practice
+
+Agencies that have standardized their backend stack typically follow a pattern:
+
+**1. Choose a platform that can grow with client projects.** The backend that works for a small client's MVP needs to also work when that client's user base grows by 10x. Platforms that charge per API call or per database record quickly become expensive at scale.
+
+**2. Build internal templates and starter kits.** Once you've standardized on a platform, build your own starting points: authentication flows, admin panel scaffolding, standard database schemas for common use cases. These internal tools pay off across every subsequent project.
+
+**3. Train the team once, benefit continuously.** Invest in getting the whole team proficient on the chosen platform. The return on that training investment compounds with every project you ship.
+
+**4. Use the platform's organizational features.** Most backend platforms offer organizations, teams, or workspaces for managing multiple projects. Use them consistently so there's a clear structure that any team member can navigate.
+
+**5. Document your patterns, not just the platform.** Your team's specific conventions (how you name collections, how you structure permissions, how you handle file uploads) should be documented alongside the platform documentation.
+
+## Evaluating a backend platform for agency use
+
+When choosing a platform to standardize on, test it against a realistic agency project:
+
+- How long does it take to spin up a new project from scratch?
+- Can you replicate a project structure for a new client without starting from zero?
+- How does it handle multiple environments (development, staging, production)?
+- Is there a CLI or API for automating project setup?
+- How are credentials and secrets managed across multiple projects?
+- Can clients get access to their own data without accessing your team's account?
+
+## Appwrite for agency teams
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Appwrite is particularly well-suited to agency workflows:
+
+- **Project isolation**: Appwrite's project-based structure gives each client their own authentication system, database, storage, and functions within a clean, isolated boundary, while remaining manageable from a single Appwrite installation or organization.
+- **Fast project setup**: The [Appwrite CLI](https://appwrite.io/docs/tooling/command-line/installation) supports scripted project creation and configuration, making it straightforward to automate new client environment setup from a template.
+- **Full-stack coverage**: Authentication, databases, storage, functions, real-time, and messaging in one platform means fewer third-party integrations to manage per project and a consistent mental model across all client work.
+- **Self-hosting for regulated clients**: Agencies working with enterprise or compliance-sensitive clients can deploy Appwrite within those clients' own cloud accounts, satisfying data residency requirements without switching to a different backend stack.
+- **Client access controls**: Appwrite's team and membership system lets you give client stakeholders read or admin access to their own project without exposing your team's other client environments.
+
+## Start standardizing your agency's backend stack
+
+Standardization is one of the highest-leverage decisions an agency can make. The right backend platform becomes a multiplier on every developer's productivity across every client engagement.
+
+[Appwrite](https://appwrite.io) is particularly well-suited for agency use. Its project-based structure isolates each client's data, authentication, storage, and functions within a clean boundary. The [Appwrite CLI](https://appwrite.io/docs/tooling/command-line/installation) supports scripted project setup, making it straightforward to automate the creation of new client environments. Appwrite's self-hosting option means agencies working with enterprise or regulated clients can deploy within those clients' own cloud accounts when required. With authentication, databases, storage, functions, and messaging all in one platform, there's very little that a typical agency project requires that Appwrite doesn't cover.
+
+- [Appwrite Teams documentation](https://appwrite.io/docs/products/auth/teams)
+- [Appwrite CLI docs](https://appwrite.io/docs/tooling/command-line/installation)
+- [Appwrite Sites documentation](https://appwrite.io/docs/products/sites)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)

src/routes/blog/post/appwrite-vs-vercel-vs-netlify/+page.markdoc

@@ -0,0 +1,139 @@
+---
+layout: post
+title: "Appwrite vs Vercel vs Netlify: where does your stack live?"
+description: What Vercel and Netlify actually provide versus Appwrite's full-stack platform, and how to decide between consolidating your stack or mixing services.
+date: 2024-06-14
+cover: /images/blog/appwrite-vs-vercel-vs-netlify/cover.png
+timeToRead: 7
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+If you ask a developer what Vercel and Netlify do, you'll get a clear answer: they host frontend applications. Fast deployments, CDN-delivered static assets, serverless functions for edge logic. They're excellent at what they do. But they're not full-stack platforms, and treating them as the foundation of your entire stack creates architectural gaps that show up later as bugs, security incidents, or features that are much harder to build than they should have been.
+
+The key question is not which hosting platform is better. It is what each layer of your stack is actually responsible for, and whether your current setup covers the complete surface area of your application's needs.
+
+## What Vercel and Netlify are (and aren't)
+
+Vercel and Netlify are frontend deployment and hosting platforms. Their primary value is in the delivery layer:
+
+- Automatic deployments from Git
+- Global CDN distribution for static assets
+- Preview environments for every pull request
+- Serverless functions (Edge Functions, API Routes, Netlify Functions) for server-side logic
+- Build pipeline integrations for popular frontend frameworks (Next.js, Gatsby, Astro, etc.)
+
+What they are **not** is a complete backend. Specifically, they don't provide out of the box:
+
+- **A persistent database.** Serverless functions on Vercel or Netlify don't have a built-in database. You bring your own: Postgres on PlanetScale or Neon, a NoSQL database on MongoDB Atlas, or another service.
+- **User authentication.** There is no built-in user management, session handling, or OAuth integration. You bring your own: Auth0, Clerk, NextAuth, or another service.
+- **File storage.** No built-in file upload or storage system. Developers typically reach for AWS S3, Cloudflare R2, or similar.
+- **Real-time.** No native WebSocket or real-time subscription primitives.
+- **Server-side business logic with persistent state.** Serverless functions are stateless and short-lived by design.
+
+The result is that building a full application on Vercel or Netlify means stitching together multiple third-party services (one for auth, one for database, one for storage, one for email), each with its own API, SDK, billing, and maintenance burden.
+
+## What Appwrite is
+
+Appwrite is a full-stack platform. [Appwrite Sites](https://appwrite.io/docs/products/sites) handles frontend hosting and deployment, while the rest of the platform covers the complete backend: authentication, databases, file storage, serverless functions, messaging, and real-time.
+
+### Frontend hosting with Appwrite Sites
+
+Appwrite Sites handles frontend deployment with the features you'd expect from a modern hosting platform:
+
+- **Git-based deployments.** Connect a repository, select a branch, and Appwrite automatically builds and deploys on every push.
+- **Global distribution.** Sites are served across the Appwrite Network's edge locations, reducing latency worldwide.
+- **Branch and commit URLs.** Every branch and commit gets its own URL, so you can preview and share changes before activating them.
+- **Custom domains.** Attach your own domain via CNAME, ALIAS/ANAME, or nameserver delegation. TLS certificates are provisioned and managed automatically.
+- **DDoS protection and WAF.** Security infrastructure is included by default.
+- **Framework support.** Starter kits for Next.js, Nuxt, SvelteKit, Astro, Vue, TanStack Start, and more.
+- **CLI and manual deploy.** Beyond Git, you can deploy via the Appwrite CLI or by uploading a `.tar.gz` build artifact directly.
+
+### Backend services
+
+Appwrite's backend covers everything a production application needs without reaching for separate services:
+
+- **Authentication.** Email/password, OAuth2 (Google, GitHub, Apple, and 30+ other providers), phone/SMS, anonymous sessions, multi-factor authentication, and team-based access control.
+- **Databases.** A document-oriented database with collections, indexes, real-time subscriptions, and a query system with support for filtering, ordering, and pagination.
+- **File storage.** Managed file uploads with bucket-level and document-level permissions, file type restrictions, size limits, and antivirus scanning.
+- **Serverless functions.** Server-side logic with support for multiple runtimes (Node.js, Python, PHP, Ruby, Dart, Swift, Kotlin, Go, and more), triggered by HTTP requests, events, or schedules.
+- **Messaging.** Push notifications, email, and SMS messaging with support for topics and subscriber management.
+- **Real-time.** WebSocket-based subscriptions that let clients listen for changes to documents, collections, files, or any Appwrite resource.
+
+Appwrite is fully open source and can be self-hosted on any Docker-compatible infrastructure.
+
+## How Appwrite fits into your architecture
+
+Depending on your situation, there are two ways to use Appwrite.
+
+### Appwrite as your entire stack
+
+Your frontend deploys to Appwrite Sites; your backend (auth, database, storage, functions) runs in the same Appwrite project. One platform, one dashboard, one billing relationship. Your frontend and backend share the same environment variables and can be managed from a single console with no cross-platform configuration to maintain.
+
+```js
+// In a Next.js app deployed to Appwrite Sites
+import { Client, Account, Databases } from 'appwrite';
+
+const client = new Client()
+    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
+    .setProject('<PROJECT_ID>');
+
+const account = new Account(client);
+const databases = new Databases(client);
+
+const user = await account.get();
+const posts = await databases.listDocuments('<DATABASE_ID>', '<COLLECTION_ID>');
+```
+
+### Appwrite backend with Vercel or Netlify for frontend
+
+If your frontend is already on Vercel or Netlify, or your use case benefits from their specific ecosystem (Next.js optimizations on Vercel, for example), Appwrite works cleanly as the backend layer alongside either platform.
+
+- **Vercel or Netlify** handles frontend hosting, CDN delivery, and deployment automation
+- **Appwrite** handles user authentication, data storage, file management, and backend functions
+
+Your Next.js application deployed on Vercel calls Appwrite APIs for user login, data fetching, and file uploads. Vercel does what it's good at (shipping static assets and edge functions fast); Appwrite does what it's good at (managing persistent state, users, and files securely).
+
+```js
+// In a Next.js API route deployed to Vercel
+import { Client, Account } from 'node-appwrite';
+
+const client = new Client()
+    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
+    .setProject('<PROJECT_ID>')
+    .setSession(sessionToken);
+
+const account = new Account(client);
+const user = await account.get();
+```
+
+Both architectures are well-supported. The choice comes down to whether you want full platform consolidation or prefer to keep a specific hosting setup you're already invested in.
+
+## The backend gap problem
+
+Regardless of where your frontend lives, the more important architectural question is: what handles your backend?
+
+The risk of treating Vercel or Netlify as your complete backend (beyond their serverless function layer) is what might be called the backend gap: the growing list of things your application needs that none of your current services provide.
+
+Common manifestations:
+
+- A user can't reset their password because there's no built-in session or email integration
+- Uploaded files are accessible to any user because there's no per-user access control
+- Real-time features require polling because there's no subscription system
+- The admin needs to see all user accounts but there's no user management interface
+- An enterprise customer asks about audit logging and there's no answer
+
+Each of these is solvable, but each requires adding another service, learning another API, and maintaining another integration. Appwrite was designed to cover all of these from the start, alongside the frontend hosting layer.
+
+## Choose your stack based on backend coverage, not just frontend delivery
+
+Vercel and Netlify are excellent at frontend delivery. They're not replacements for a backend. The teams that build most efficiently are those that understand what each layer of their stack is responsible for and pick tools that cover the complete surface area of their application's needs.
+
+[Appwrite](https://appwrite.io) covers the full stack: frontend hosting with [Appwrite Sites](https://appwrite.io/docs/products/sites) and a complete backend in a single platform. If you prefer a separate hosting setup, Appwrite fills the backend layer cleanly alongside Vercel, Netlify, Cloudflare Pages, or anything else. Try [Appwrite Cloud](https://cloud.appwrite.io) for free or self-host using the [installation guide](https://appwrite.io/docs/advanced/self-hosting).
+
+- [Appwrite Sites documentation](https://appwrite.io/docs/products/sites)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Appwrite Databases docs](https://appwrite.io/docs/products/databases)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)