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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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 three new marketing blog posts (hackathon guide, BaaS explainer, and a Firebase/Supabase/Appwrite comparison) along with their cover images and cache entries. The posts are well-structured, use the correct frontmatter conventions, and reference valid author/category identifiers already in the codebase. Issues found:
Confidence Score: 3/5Safe to merge after addressing the pricing table accuracy issue, which would immediately become incorrect once the Scale plan launches. Two of the three issues are minor (a typo and off-topic copy), but the Appwrite Scale plan being listed as "Not available" in a comparison post is a factual inaccuracy that is directly contradicted by code already in the repo. Publishing this could mislead readers and require a quick follow-up correction the moment the Scale plan goes live. src/routes/blog/post/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/+page.markdoc (pricing table accuracy) and src/routes/blog/post/baas-backend-as-a-service-explained-when-should-you-use-it/+page.markdoc (title typo) Important Files Changed
Reviews (1): Last reviewed commit: "new blogs" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| | --- | --- | --- | --- | | ||
| | 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 | |
There was a problem hiding this comment.
The pricing table marks Appwrite's Team/Scale tier as Not available, but the codebase (src/routes/pricing/+page.svelte and compare-plans.svelte) already defines a scale plan with detailed pricing, gated behind a SHOW_SCALE_PLAN feature flag. Once that flag is enabled and the Scale plan is publicly released, this comparison table will be immediately inaccurate and potentially misleading to readers. Consider replacing Not available with a note such as See appwrite.io/pricing or the actual plan price, so the blog post doesn't become stale the moment the plan launches.
| 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.
Lines 128–130 describe the Appwrite open-source contribution workflow (pull request approvals, contribution guide), which is about contributing to Appwrite — not about using Appwrite to build a hackathon project. This content feels out of place in a post targeting hackathon participants, and could confuse readers who are trying to understand how to use the platform. Consider removing these lines or replacing them with content about how the open-source nature helps hackathon teams (e.g., full access to source code, self-hosting options, no paywalled features).
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
|
|
||
| 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
3 participants
Added three new blogs focused on comparison, BaaS adoption, and hackathon development workflows.
Summary by CodeRabbit