Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThe PR adds three new Markdoc blog posts with full frontmatter and article content: "Appwrite for Hackathons — Build Fast, Ship Faster", "BaaS — Backend-as-a-Service Explained: When Should You Use It?", and "Supabase vs Firebase vs Appwrite — Choosing the Right Backend in 2026." Each post includes metadata (layout, title, description, date, cover image, reading time, author, category, featured) and multi-section content covering features, use cases, comparisons, and resources. The .optimize-cache.json file is updated with SHA-256 entries for the three new cover images. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@src/routes/blog/post/baas-backend-as-a-service-explained-when-should-you-use-it/`+page.markdoc:
- Line 3: The title string currently uses an incorrect capitalization ("BaaS
(backend as a service) explained: When should you use It?"); update that title
in the page's frontmatter to use lowercase "it" ("BaaS (backend as a service)
explained: When should you use it?") so the file's title value matches correct
title casing.
In
`@src/routes/blog/post/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/`+page.markdoc:
- Around line 194-205: The pricing claims for the Firebase, Supabase, and
Appwrite sections and the comparison table lack source attribution and a
timestamp; add inline source links (or footnotes) for each provider's plan
details and append a clear "Prices and limits as of <date>" note (e.g., "as of
March 30, 2026") near the top or bottom of the pricing subsection. Update the
"Firebase", "Supabase", and "Appwrite" paragraphs and the table caption to
include those links/footnotes and the "as of" date so readers can verify and the
content stays time-stamped.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 43cc1d4c-5a4b-44a0-92d2-97cca97b2c8d
⛔ Files ignored due to path filters (3)
static/images/blog/appwrite-for-hackathons-build-fast-ship-faster/cover.pngis excluded by!**/*.pngstatic/images/blog/baas-backend-as-a-service-explained-when-should-you-use-it/cover.pngis excluded by!**/*.pngstatic/images/blog/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/cover.pngis excluded by!**/*.png
📒 Files selected for processing (4)
.optimize-cache.jsonsrc/routes/blog/post/appwrite-for-hackathons-build-fast-ship-faster/+page.markdocsrc/routes/blog/post/baas-backend-as-a-service-explained-when-should-you-use-it/+page.markdocsrc/routes/blog/post/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/+page.markdoc
| **Firebase** operates on a two-tier model: the **Spark (no-cost) plan** for getting started with no payment method required, and the **Blaze (pay-as-you-go) plan** which comes with $300 in free credit. The catch is that Blaze pricing scales across reads, writes, storage, bandwidth, and Cloud Functions invocations separately, making costs genuinely difficult to forecast as usage grows. Teams that hit scale without careful monitoring have been caught off guard by Firebase bills. | ||
|
|
||
| **Supabase** positions itself around predictable, flat-rate tiers. The **Free plan** ($0/month) supports 50K monthly active users, 500MB database storage, and 5GB egress, suitable for side projects and prototypes. The **Pro plan** starts at **$25/month**, covering 100K MAUs, 8GB disk, and 250GB egress with clear overage rates. For teams needing SOC2, HIPAA, SSO, and 14-day backups, the **Team plan** starts at **$599/month**. Enterprise pricing is custom. | ||
|
|
||
| **Appwrite** mirrors Supabase's entry pricing with a **Free plan** ($0/month) offering 75K MAUs, 5GB bandwidth, 2GB storage, and 750K function executions. The **Pro plan** starts at **$25/month** and significantly increases limits, covering 200K MAUs, 2TB bandwidth, 150GB storage, and 3.5M executions, along with organization roles and daily backups. **Enterprise** is custom, adding SOC-2, HIPAA, SSO, and bring-your-own-cloud options. | ||
|
|
||
| | Plan | Firebase | Supabase | Appwrite | | ||
| | --- | --- | --- | --- | | ||
| | Free | $0 (Spark) | $0 | $0 | | ||
| | Pro / Paid | Pay-as-you-go | From $25/mo | From $25/mo | | ||
| | Team / Scale | Usage-based | $599/mo | Not available | | ||
| | Enterprise | Custom | Custom | Custom | |
There was a problem hiding this comment.
Add source links or an “as of” note for pricing claims.
These plan limits/prices are volatile; without source attribution or an explicit “as of March 30, 2026” note, this section can become stale quickly.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@src/routes/blog/post/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/`+page.markdoc
around lines 194 - 205, The pricing claims for the Firebase, Supabase, and
Appwrite sections and the comparison table lack source attribution and a
timestamp; add inline source links (or footnotes) for each provider's plan
details and append a clear "Prices and limits as of <date>" note (e.g., "as of
March 30, 2026") near the top or bottom of the pricing subsection. Update the
"Firebase", "Supabase", and "Appwrite" paragraphs and the table caption to
include those links/footnotes and the "as of" date so readers can verify and the
content stays time-stamped.
Greptile SummaryThis PR adds two new blog posts — one on using Appwrite for hackathons and one explaining Backend-as-a-Service — along with their cover images and cache entries. Both posts have correct frontmatter and valid author references. All remaining findings are P2. Confidence Score: 5/5Safe to merge; only minor style and formatting issues remain. Both blog posts are well-formed with valid frontmatter, existing author references, and no logic or security issues. The two P2 findings (absolute internal URLs and double spaces) are cosmetic and do not block merge. No files require special attention.
|
| Filename | Overview |
|---|---|
| src/routes/blog/post/appwrite-for-hackathons-build-fast-ship-faster/+page.markdoc | New blog post on using Appwrite for hackathons; well-structured with proper frontmatter, but contains double spaces on line 99. |
| src/routes/blog/post/baas-backend-as-a-service-explained-when-should-you-use-it/+page.markdoc | New BaaS explainer blog post with valid frontmatter and content; Resources section uses absolute internal URLs instead of the relative-path convention used elsewhere. |
| .optimize-cache.json | Cache mapping entries added for the two new blog cover images; no issues. |
Reviews (8): Last reviewed commit: "Update +page.markdoc" | Re-trigger Greptile
.../blog/post/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/+page.markdoc
Outdated
Show resolved
Hide resolved
src/routes/blog/post/appwrite-for-hackathons-build-fast-ship-faster/+page.markdoc
Outdated
Show resolved
Hide resolved
|
|
||
| Appwrite encourages community contributions through pull requests, which must be approved by a core developer to ensure code quality and project integrity. | ||
|
|
||
| To help new contributors, Appwrite provides a comprehensive contribution guide that explains how to get started and contribute effectively. |
There was a problem hiding this comment.
Which guide are we talking about?
|
|
||
| 1. Create an Appwrite project | ||
| 2. Add authentication for user accounts | ||
| 3. Create database collections for application data |
There was a problem hiding this comment.
We use tables, not collections
src/routes/blog/post/appwrite-for-hackathons-build-fast-ship-faster/+page.markdoc
Show resolved
Hide resolved
|
|
||
| With Appwrite, you can go from idea to working prototype in minutes. Just sign up, set up your project in the console, and start building, no complex configuration or backend expertise required. | ||
|
|
||
| # Why Hackathon Teams Choose Appwrite |
There was a problem hiding this comment.
There's some weird ordering here
Was this written with Surfer?
Also, case in headings needs to be fixed
src/routes/blog/post/baas-backend-as-a-service-explained-when-should-you-use-it/+page.markdoc
Show resolved
Hide resolved
| # When BaaS might not be the right fit | ||
|
|
||
| BaaS is powerful, but it's not the right answer for every use case. Teams with the following requirements may need more control than a standard BaaS platform offers: | ||
|
|
||
| - **Complex compliance requirements:** industries with strict data residency or regulatory constraints (healthcare, fintech) may need custom infrastructure | ||
| - **Specialized database performance:** high-scale systems with complex query optimization needs | ||
| - **Deeply custom architectures:** applications with unique microservices patterns that don't map to BaaS conventions | ||
| - **Extreme scale:** workloads that require fine-tuned infrastructure management at the infrastructure level | ||
|
|
||
| That said, this line has shifted significantly. Modern BaaS platforms, particularly open-source ones, now support self-hosted deployments, giving teams full infrastructure control while still benefiting from pre-built backend features. |
There was a problem hiding this comment.
This may hurt our case
| # Common misconceptions about BaaS | ||
|
|
||
| **"BaaS is only for prototypes."** | ||
| Not anymore. Many production applications, including ones handling millions of users, run on BaaS platforms. Modern tools support scalable architectures, fine-grained permissions, and complex integrations. | ||
|
|
||
| **"You lose control of your backend."** | ||
| This was a fair criticism of early BaaS tools. Modern platforms provide serverless functions, custom logic, and extensive configuration options, and open-source platforms let you own the infrastructure entirely. | ||
|
|
||
| **"BaaS means vendor lock-in."** | ||
| It depends on the platform. Closed, proprietary BaaS solutions can create lock-in. But open-source BaaS platforms give teams the freedom to self-host, migrate, or extend the backend as needed. |
There was a problem hiding this comment.
This feels wrongly ordered, should be before right/wrong fit sections
src/routes/blog/post/baas-backend-as-a-service-explained-when-should-you-use-it/+page.markdoc
Show resolved
Hide resolved
There was a problem hiding this comment.
Can you separate this into a different PR?
I may need to spend more time on this and it can block the other 3
src/routes/blog/post/appwrite-for-hackathons-build-fast-ship-faster/+page.markdoc
Outdated
Show resolved
Hide resolved
| # Getting started with Appwrite | ||
|
|
||
| Appwrite is built to help developers get their projects off the ground fast, whether you're building for a hackathon, a university project, or launching a new app for the world. Getting started with the platform is simple and designed to minimize setup time so you can focus on building. | ||
|
|
||
| To begin, you can choose between two flexible options: self-hosting Appwrite on your own infrastructure using Docker, or signing up for Appwrite Cloud for a fully managed experience. Both options give you access to the same powerful suite of backend services, including authentication, databases, storage, and serverless functions. | ||
|
|
||
| Once you've installed Appwrite or created your cloud account, you'll use the Appwrite console—a user-friendly dashboard that lets you create and manage projects, configure authentication, set up databases, and connect your frontend using Appwrite's SDKs. The console is your central hub for building, scaling, and managing your app's backend with just a few clicks. | ||
|
|
||
| Appwrite's comprehensive documentation and tutorials make it easy for developers of any experience level to get started. If you need help or want to learn from others, the Appwrite community is active and ready to support you with resources, code examples, and answers to your questions. | ||
|
|
||
| With Appwrite, you can go from idea to working prototype in minutes. Just sign up, set up your project in the console, and start building, no complex configuration or backend expertise required. |
There was a problem hiding this comment.
Let's add our AI quickstarts and guides somewhere here too
|
|
||
| To begin, you can choose between two flexible options: self-hosting Appwrite on your own infrastructure using Docker, or signing up for Appwrite Cloud for a fully managed experience. Both options give you access to the same powerful suite of backend services, including authentication, databases, storage, and serverless functions. | ||
|
|
||
| Once you've installed Appwrite or created your cloud account, you'll use the Appwrite console—a user-friendly dashboard that lets you create and manage projects, configure authentication, set up databases, and connect your frontend using Appwrite's SDKs. The console is your central hub for building, scaling, and managing your app's backend with just a few clicks. |
There was a problem hiding this comment.
We don't need to explain the console
src/routes/blog/post/appwrite-for-hackathons-build-fast-ship-faster/+page.markdoc
Outdated
Show resolved
Hide resolved
src/routes/blog/post/appwrite-for-hackathons-build-fast-ship-faster/+page.markdoc
Outdated
Show resolved
Hide resolved
|
|
||
| Modern app development moves fast, and nothing slows a team down more than rebuilding the same backend infrastructure over and over again. | ||
|
|
||
| Authentication systems. Databases. File storage. Real-time APIs. Permissions. These aren't differentiators. They're table stakes. Yet teams spend weeks, sometimes months, getting them right before writing a single line of product code. |
There was a problem hiding this comment.
"table stakes" is not something people will understand by default
| - **Complex compliance requirements:** industries with strict data residency or regulatory constraints (healthcare, fintech) may need custom infrastructure, though self-hosted BaaS deployments can satisfy many of these requirements without building from scratch | ||
| - **Specialized database performance:** high-scale systems with complex query optimization needs | ||
| - **Deeply custom architectures:** applications with unique microservices patterns that don't map to BaaS conventions | ||
| - **Extreme scale:** workloads that require fine-tuned infrastructure management at the infrastructure level |
There was a problem hiding this comment.
"fine-tuned infrastructure management at the infrastructure level"
Not the best framing, let's improve it
| - Authentication with support for 30+ login methods | ||
| - Databases with real-time subscriptions and fine-grained permissions | ||
| - Cloud storage with file transformation support | ||
| - Serverless functions in any language |
| - Databases with real-time subscriptions and fine-grained permissions | ||
| - Cloud storage with file transformation support | ||
| - Serverless functions in any language | ||
| - Real-time APIs |
There was a problem hiding this comment.
just one API, covering events across all services
src/routes/blog/post/baas-backend-as-a-service-explained-when-should-you-use-it/+page.markdoc
Show resolved
Hide resolved
Co-authored-by: Aditya Oberai <adityaoberai1@gmail.com>
Co-authored-by: Aditya Oberai <adityaoberai1@gmail.com>
Co-authored-by: Aditya Oberai <adityaoberai1@gmail.com>
src/routes/blog/post/baas-backend-as-a-service-explained-when-should-you-use-it/+page.markdoc
Outdated
Show resolved
Hide resolved
|
|
||
| Realtime features such as live updates, collaborative editing, messaging, and notifications can significantly improve a hackathon demo. | ||
|
|
||
| Appwrite provides realtime APIs that allow applications to respond instantly to database changes and system events. Appwrite supports multiple APIs, such as REST, WebSocket, and GraphQL, to interact with realtime resources. Applications can communicate updates instantly to users using Appwrite's realtime APIs. Teams can interact with Appwrite's realtime APIs to build collaborative and interactive features. |
There was a problem hiding this comment.
Not exactly
We have only one Realtime API, supported through WebSockets
https://appwrite.io/docs/apis/realtime
src/routes/blog/post/appwrite-for-hackathons-build-fast-ship-faster/+page.markdoc
Outdated
Show resolved
Hide resolved
Co-authored-by: Aditya Oberai <adityaoberai1@gmail.com>
Added three new blogs focused on comparison, BaaS adoption, and hackathon development workflows.
Summary by CodeRabbit