SEO blogs targetting AI #2908
Open
atharvadeosthale wants to merge 1 commit intomainfrom
Open
Conversation
Contributor
Greptile SummaryThis PR adds 15 new SEO-targeted blog posts covering AI development topics (comparisons vs Cloudflare, Convex, Firebase, Neon, Replit, Supabase, Vercel; Lovable-focused posts; and informational pieces on AI backends and vibe coding). All posts use Confidence Score: 4/5Safe to merge once the orphaned cover image is resolved — all 15 blog posts are well-formed with valid frontmatter and matching cover images. The 15 new posts are structurally clean and consistent with existing SEO content patterns. Score is capped at 4 due to the pre-existing P1 finding of the orphaned image (ai-app-builder-vs-backend-platform/cover.png) that has no corresponding blog post. static/images/blog/ai-app-builder-vs-backend-platform/cover.png and its .optimize-cache.json entry — this image has no corresponding blog post and should either have a post added or be removed. Important Files Changed
Reviews (2): Last reviewed commit: "ai seo blogs first batch" | Re-trigger Greptile |
|
|
||
| Picking a backend for an app that an AI coding agent will help build is a decision with a long half-life. The agent spends most of its context budget reasoning about identity, data, files, server-side code, and hosting, so the platform underneath has to give it clear primitives, a stable API, and an MCP surface the model can use directly. Appwrite vs Firebase AI is the comparison teams run when they weigh an open-source, self-hostable backend against Google's AI assistance ecosystem. | ||
|
|
||
| This article looks at Appwrite as a Firebase alternative for AI apps, focused on open-source flexibility, MCP coverage, SDK breadth, Databases with tables and rows, Functions, Sites, and self-hosting, against Firebase's Gemini in Firebase, Firebase MCP server, Gemini CLI extension, and agent skills. |
Contributor
There was a problem hiding this comment.
A section later covers this, talks about variety of SDKs
|
|
||
| | Capability | Appwrite | Firebase | | ||
| | --- | --- | --- | | ||
| | Auth | Email and password, magic URL, email OTP, phone, anonymous, JWT, custom tokens, OAuth2 with roughly 44 providers | Email and password, phone, anonymous, OAuth with Google, Apple, Facebook, Twitter, GitHub, and others; SAML and OIDC through Identity Platform upgrade | |
Contributor
There was a problem hiding this comment.
Suggested change
| | Auth | Email and password, magic URL, email OTP, phone, anonymous, JWT, custom tokens, OAuth2 with roughly 44 providers | Email and password, phone, anonymous, OAuth with Google, Apple, Facebook, Twitter, GitHub, and others; SAML and OIDC through Identity Platform upgrade | | |
| | Auth | Email and password, magic URL, email OTP, phone, anonymous, JWT, custom tokens, OAuth2 with roughly 44 providers | Email and password, phone, anonymous, OAuth with Google, Apple, Facebook, X, GitHub, and others; SAML and OIDC through Identity Platform upgrade | |
|
|
||
| Choose Appwrite if: | ||
|
|
||
| - You want one open-source platform covering Auth, tables, Storage, Functions, Realtime, Messaging, and hosting for your AI-generated frontend, all reachable through an MCP server. |
Contributor
There was a problem hiding this comment.
Tables is lower case
adityaoberai
requested changes
Apr 30, 2026
|
|
||
| Put together, these shifts mean backend platforms are being evaluated against a new checklist: does an agent already understand your product, can it act on it safely, and does it stay current? | ||
|
|
||
| # How the leading platforms are positioning |
Contributor
There was a problem hiding this comment.
Appwrite not being in the section of leading platforms can send the wrong message forward (even though the next section fits us in here)
Contributor
There was a problem hiding this comment.
Let's shift the Appwrite section above this and instead of titling it as "leading platforms", we can say "alternative platforms"
|
|
||
| None of this makes Cloudflare a bad choice for a specific kind of agent. It does mean Cloudflare Agents is an infrastructure layer for stateful compute, not a complete backend for your AI product. | ||
|
|
||
| # How Appwrite positions itself for AI apps and agents |
Contributor
There was a problem hiding this comment.
We should also include our plugins here
| - **Sites** for hosting the frontend of your AI app with source control deploys, custom domains, env vars, and rollbacks. | ||
| - **Realtime** channels that subscribe to row changes, user events, and custom events, which is how you push token updates, tool call results, and agent status to every connected client. | ||
| - **Messaging** for email, SMS, and push, useful for human-in-the-loop approval and async notifications from long-running agents. | ||
| - **Appwrite MCP servers**, both the API MCP (for acting on Appwrite resources) and the Docs MCP (for Appwrite context), so coding agents can build and operate against Appwrite directly. |
Contributor
There was a problem hiding this comment.
Info on plugins and skills also needs to be added
|
|
||
| | Capability | Appwrite | Firebase | | ||
| | --- | --- | --- | | ||
| | Auth | Email and password, magic URL, email OTP, phone, anonymous, JWT, custom tokens, OAuth2 with roughly 44 providers | Email and password, phone, anonymous, OAuth with Google, Apple, Facebook, Twitter, GitHub, and others; SAML and OIDC through Identity Platform upgrade | |
Contributor
There was a problem hiding this comment.
Suggested change
| | Auth | Email and password, magic URL, email OTP, phone, anonymous, JWT, custom tokens, OAuth2 with roughly 44 providers | Email and password, phone, anonymous, OAuth with Google, Apple, Facebook, Twitter, GitHub, and others; SAML and OIDC through Identity Platform upgrade | | |
| | Auth | Email and password, magic URL, email OTP, phone, anonymous, JWT, custom tokens, OAuth2 with roughly 44 providers | Email and password, phone, anonymous, OAuth with Google, Apple, Facebook, X, GitHub, and others; SAML and OIDC through Identity Platform upgrade | |
|
|
||
| Appwrite [Auth](/docs/products/auth) covers email and password, magic URL, email OTP, phone, anonymous sessions, JWTs, custom tokens for existing auth systems, and OAuth2 across roughly 44 providers. Teams, labels, and row-level permissions give AI-generated rules a predictable place to live. | ||
|
|
||
| [Firebase Authentication](https://firebase.google.com/docs/auth) supports email and password, phone, anonymous, and popular federated providers including Google, Apple, Facebook, Twitter, and GitHub, with drop-in UI through FirebaseUI. Multi-factor authentication, SAML, OpenID Connect providers, and multi-tenancy require an upgrade to Firebase Authentication with Identity Platform. That upgrade is a normal path for larger apps; it is also an extra tier an agent has to know about when it generates enterprise login flows. |
Contributor
There was a problem hiding this comment.
Suggested change
| [Firebase Authentication](https://firebase.google.com/docs/auth) supports email and password, phone, anonymous, and popular federated providers including Google, Apple, Facebook, Twitter, and GitHub, with drop-in UI through FirebaseUI. Multi-factor authentication, SAML, OpenID Connect providers, and multi-tenancy require an upgrade to Firebase Authentication with Identity Platform. That upgrade is a normal path for larger apps; it is also an extra tier an agent has to know about when it generates enterprise login flows. | |
| [Firebase Authentication](https://firebase.google.com/docs/auth) supports email and password, phone, anonymous, and popular federated providers including Google, Apple, Facebook, X, and GitHub, with drop-in UI through FirebaseUI. Multi-factor authentication, SAML, OpenID Connect providers, and multi-tenancy require an upgrade to Firebase Authentication with Identity Platform. That upgrade is a normal path for larger apps; it is also an extra tier an agent has to know about when it generates enterprise login flows. |
|
|
||
| Auth is where most vibe-coded apps leak first. The UI looks finished and the signup flow works on the demo account, so the assumption is that the rest will follow. | ||
|
|
||
| - [ ] Decide which identity methods you support (email and password, magic URL, email OTP, OAuth, phone OTP, anonymous) and remove every flow you do not. |
Contributor
There was a problem hiding this comment.
I don't think we need - [ ] style checkboxes in the UI
A simple list will do
|
|
||
| ## 1. Authentication that covers your sign-in flows | ||
|
|
||
| A lovable backend needs more than a demo sign-in screen. Look for: |
Contributor
There was a problem hiding this comment.
Suggested change
| A lovable backend needs more than a demo sign-in screen. Look for: | |
| A Lovable backend needs more than a demo sign-in screen. Look for: |
| In practice, a Lovable team using Appwrite as their backend works like this: build the UI in Lovable, connect the Appwrite docs MCP server inside Lovable's personal connectors so the chat has accurate Appwrite context, and wire the generated frontend to Appwrite through the web SDK. Heavier work such as schema changes, server-side logic, and deploys happen through the Appwrite console, SDKs, CLI, or other AI tools configured with the Appwrite MCP servers. | ||
|
|
||
| # Comparing backend shapes at a glance | ||
|
|
Contributor
There was a problem hiding this comment.
This blog doesn't need a comparison, we just need to talk about how Appwrite solves these problems
| 4. Build the UI in Lovable, pointing it at your Appwrite project. | ||
| 5. Deploy the frontend on Appwrite Sites if you want the full stack in one place. | ||
|
|
||
| The goal is not to replace Lovable's speed. It is to give the generated app a backend it can keep growing into. |
Contributor
There was a problem hiding this comment.
Intentionally removed the More resources section?
|
|
||
| Not every Lovable project needs a broad backend platform. Sometimes the right answer is "replace Supabase with a different single-purpose backend," and sometimes it is "use a different integration inside Lovable." The options below are worth considering. | ||
|
|
||
| ## Lovable Cloud |
Contributor
There was a problem hiding this comment.
Not sure if it makes sense to include this
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.