Open
Conversation
Contributor
WalkthroughThis PR introduces documentation and blog content for Appwrite Auth's new user impersonation feature. Changes include a new impersonation documentation page explaining setup and client configuration, a blog post announcing the feature with SDK code examples across multiple platforms, a changelog entry, updated REST API documentation with impersonation request headers, navigation updates, and supporting blog post content. Image cache entries are updated to reflect new assets. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 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 Tip You can make CodeRabbit's review stricter and more nitpicky using the `assertive` profile, if that's what you prefer.Change the |
Contributor
Greptile SummaryThis PR introduces documentation and content for the new user impersonation feature in Appwrite Auth, along with an unrelated SEO blog post comparing Lovable and Imagine. The impersonation content spans a new docs page, a blog announcement, a changelog entry, REST API header documentation, and sidebar navigation updates.
Confidence Score: 4/5
Important Files Changed
Last reviewed commit: "Updated blog cover" |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| - X-Appwrite-Impersonate-User-Phone: [PHONE] | ||
| - optional | ||
| - Resolves the effective user for an already authenticated impersonator request by phone number. Only works when the authenticated user has impersonation enabled. | ||
| {% /table %} |
Contributor
There was a problem hiding this comment.
{% /table %} indentation
All {% /table %} closing tags in this file were changed to have 2 leading spaces (e.g., {% /table %}), while the table row items above them have no indentation. This is inconsistent across the file and differs from the original style. While Markdoc parsers are typically lenient about leading whitespace, it would be worth verifying this renders correctly and aligning it with the convention used in the rest of the codebase.
Suggested change
| {% /table %} | |
| {% /table %} |
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!
| - Impersonation must start from a real user session, not an API key by itself. | ||
| - Users with impersonation enabled are automatically granted the `users.read` scope. | ||
| - The target user's permissions are used for the impersonated request. | ||
| - The user model exposes `impersonator` and `impersonatorUserId` so your app can react when impersonation is active. |
Contributor
There was a problem hiding this comment.
The sentence "The user model exposes impersonator and impersonatorUserId so your app can react when impersonation is active" conflates two distinct concepts:
impersonatoris a static user capability boolean — it indicates whether a user can impersonate others. It is always present on the user model, not only when impersonation is active.impersonatorUserIdis only set on a response when impersonation is currently active (i.e., when viewing a user being impersonated).
The current wording implies both fields are only relevant during an active impersonation session, which is inaccurate for impersonator.
Suggested change
| - The user model exposes `impersonator` and `impersonatorUserId` so your app can react when impersonation is active. | |
| - The `impersonator` field on the user model indicates whether a user has impersonation capability enabled. | |
| - The `impersonatorUserId` field is present in the response when impersonation is active, exposing who initiated the impersonation so your app can react accordingly. |
| - [Introducing Imagine: from ideas to real products](/blog/post/introducing-imagine) | ||
| - [Comparing the best vibe coding tools](/blog/post/comparing-vibe-coding-tools) | ||
| - [Appwrite Sites documentation](/docs/products/sites) | ||
| - [Appwrite Storage documentation](/docs/products/storage) No newline at end of file |
Contributor
There was a problem hiding this comment.
This file is missing a trailing newline character. Most editors and linters expect a newline at the end of text files, and the diff marks this with \ No newline at end of file.
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!
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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/best-lovable-alternative-worth-exploring/`+page.markdoc:
- Around line 1-164: This blog post (frontmatter title "Best Lovable alternative
worth exploring in 2026" with layout: post and the {% call_to_action %} block)
is unrelated to the impersonation-focused PR and must be removed from this
change set and submitted in its own PR; revert or remove the +page.markdoc
content from the current branch, create a new branch containing this markdown as
a standalone change with a clear commit message (e.g., "Add blog post: Best
Lovable alternative worth exploring in 2026"), and open a separate PR for that
file so rollout/rollback and review are isolated.
In `@src/routes/docs/products/auth/impersonation/`+page.markdoc:
- Line 42: The sentence "See the Users API reference for update impersonator" is
ungrammatical; update the copy in the +page.markdoc to a clear phrasing such as
"See the Users API reference for updating an impersonator" or "See the Users API
reference for the Update Impersonator endpoint" (locate the exact string "See
the Users API reference for update impersonator" and replace it).
In `@src/routes/docs/products/auth/users/`+page.markdoc:
- Line 8: Replace the sentence "Users API can only be used with an API key with
the [Server SDK](/docs/sdks#server), to manage all users." with a clearer
wording such as "The Users API requires a Server SDK API key and is intended for
server-side user management." Locate the sentence by searching for the exact
original phrase in the docs page and update it in place to improve readability
and concision.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e4edc276-28f3-495d-850a-8777a4c6149e
⛔ Files ignored due to path filters (1)
static/images/blog/announcing-user-impersonation/cover.pngis excluded by!**/*.png
📒 Files selected for processing (9)
.optimize-cache.jsonsrc/routes/blog/post/announcing-user-impersonation/+page.markdocsrc/routes/blog/post/best-lovable-alternative-worth-exploring/+page.markdocsrc/routes/changelog/(entries)/2026-03-14.markdocsrc/routes/docs/apis/rest/+page.markdocsrc/routes/docs/products/auth/+layout.sveltesrc/routes/docs/products/auth/+page.markdocsrc/routes/docs/products/auth/impersonation/+page.markdocsrc/routes/docs/products/auth/users/+page.markdoc
Comment on lines
+1
to
+164
| --- | ||
| layout: post | ||
| title: "Best Lovable alternative worth exploring in 2026" | ||
| description: "Looking for a Lovable alternative? This guide explains where Lovable works well, where teams often outgrow it, and why Imagine is a strong option for full-stack product development." | ||
| date: 2026-03-13 | ||
| cover: /images/blog/introducing-imagine/cover.png | ||
| timeToRead: 7 | ||
| author: eldad-fux | ||
| category: product,init | ||
| featured: false | ||
| draft: false | ||
| callToAction: true | ||
| --- | ||
|
|
||
| If you are evaluating alternatives to Lovable, the right answer depends less on which tool is more popular and more on what you need the product to become. | ||
|
|
||
| Lovable has earned its place in the market by making app creation feel accessible. It helps teams move from idea to interface quickly, which is exactly what many early-stage projects need. For mockups, concept validation, lightweight internal tools, and fast UI exploration, that speed is valuable. | ||
|
|
||
| The question is what happens next. | ||
|
|
||
| Once a project moves beyond early validation, the priorities usually change. Teams start thinking about authentication, data models, storage, permissions, backend logic, deployment, and long-term maintainability. At that point, the best Lovable alternative is usually not the one that generates the nicest first screen. It is the one that reduces the distance between prototype and production. | ||
|
|
||
| That is where [Imagine](https://imagine.dev/) becomes especially compelling. | ||
|
|
||
| # Why teams start looking for a Lovable alternative | ||
|
|
||
| Most teams do not switch because the first tool was bad. They switch because the scope of the project changed. | ||
|
|
||
| A tool that feels perfect during the first week can start to feel limiting once the app needs real product infrastructure behind it. In practice, the search for a Lovable alternative often begins when teams need: | ||
|
|
||
| - A workflow that includes both frontend and backend, not just interface generation | ||
| - Built-in support for auth, database, storage, and hosting | ||
| - A clearer path from prototype to production | ||
| - Less integration work across multiple services | ||
| - More confidence that what they are generating can keep evolving with the product | ||
|
|
||
| This is an important distinction in the current AI app-building landscape. Some tools are optimized for fast visual output. Others are designed to help you ship something operationally real. | ||
|
|
||
| # Where Lovable still makes sense | ||
|
|
||
| Any credible comparison should start by acknowledging where Lovable is strong. | ||
|
|
||
| Lovable is a good fit when the immediate goal is speed. It is particularly useful for founders, designers, solo builders, and non-technical teams who want to turn an idea into something visible without a lot of setup. That low-friction experience matters, especially in the earliest phase of product exploration. | ||
|
|
||
| If your main objective is to test a concept, share a polished mockup, or get early feedback on a user experience direction, Lovable remains a sensible option. | ||
|
|
||
| The tradeoff is that many projects do not stay in that phase for long. Once the product needs persistent data, user accounts, permissions, files, workflows, or deployment discipline, the evaluation criteria shift. | ||
|
|
||
| # The Lovable alternative most worth exploring: Imagine | ||
|
|
||
| [Imagine](https://imagine.dev/) stands out because it is not only focused on generating applications with AI. It is designed around a full-stack workflow from the start. | ||
|
|
||
| The key difference is its built-in Appwrite integration. | ||
|
|
||
| That matters because Appwrite provides the product infrastructure many teams end up needing anyway, including: | ||
|
|
||
| - Authentication | ||
| - Databases | ||
| - Storage | ||
| - Hosting | ||
| - Backend logic | ||
|
|
||
| This changes the role of the AI builder. Instead of producing a front-end shell and leaving the rest to be assembled later, Imagine is positioned to help teams create applications with a backend foundation already in place. | ||
|
|
||
| For teams building something they expect to operate, maintain, and grow, that is a meaningful advantage. | ||
|
|
||
| # Why Imagine is a stronger choice for full-stack product work | ||
|
|
||
| ## 1. It reduces the gap between prototype and production | ||
|
|
||
| One of the most common problems with AI-generated apps is that the initial result looks promising, but the second phase becomes a manual rebuild. Teams often discover that the UI came quickly, but the actual product still needs infrastructure, integrations, and architectural decisions that were never part of the original flow. | ||
|
|
||
| Imagine addresses that problem more directly because it is built with Appwrite as part of the experience. That means the app is not being created in isolation from the systems it will depend on. | ||
|
|
||
| For the reader evaluating tools, this is the real question: are you creating a demo, or are you creating the beginning of a product? Imagine is more compelling when the answer is the latter. | ||
|
|
||
| ## 2. The backend is part of the workflow, not a separate project | ||
|
|
||
| Many teams underestimate how much time is spent after the interface is generated. User management, database structure, file handling, permissions, deployment, and backend logic quickly become the real work. | ||
|
|
||
| When those pieces are treated as separate follow-up tasks, the cost of the "fast start" can show up later as integration overhead and fragmentation. | ||
|
|
||
| Imagine is valuable because it treats backend capabilities as first-class building blocks. For teams that want a more coherent way to build, that can reduce rework and simplify decision-making early. | ||
|
|
||
| ## 3. It helps limit tool sprawl | ||
|
|
||
| A common pattern in modern product development is to assemble a stack from many different services: one for UI generation, one for auth, one for storage, one for data, one for hosting, and additional tooling for workflows or backend behavior. | ||
|
|
||
| That approach can work, but it creates more operational surface area. It introduces more configuration, more handoffs, and more points of failure. | ||
|
|
||
| Imagine is attractive because it consolidates more of that journey into a single product direction. For teams trying to move quickly without accumulating avoidable complexity, that matters. | ||
|
|
||
| ## 4. It is better aligned with real application requirements | ||
|
|
||
| Not every project needs a full-stack foundation on day one. But many products reach that point faster than expected. | ||
|
|
||
| Internal tools need access control. SaaS MVPs need user accounts and persistence. Dashboards need structured data. Client portals need storage and permissions. Customer-facing apps need reliability, hosting, and a path to iteration without constant rework. | ||
|
|
||
| Imagine is better aligned with those use cases than tools whose main strength is producing attractive frontends quickly. It is built for teams that already know the app is meant to do real work. | ||
|
|
||
| ## 5. It is more relevant for teams thinking about long-term delivery | ||
|
|
||
| As AI builders mature, the market is moving past novelty. Teams are no longer asking only whether a tool can generate an app. They are asking whether the generated app fits into a sustainable development workflow. | ||
|
|
||
| That is where Imagine becomes more interesting. Its appeal is not just speed. It is that the generated output sits closer to a real delivery model, where product infrastructure, deployment, and maintainability are considered part of the outcome. | ||
|
|
||
| {% call_to_action title="Build beyond the first prototype" description="Create apps with AI while keeping auth, data, storage, and hosting in the same workflow." point1="Built-in backend" point2="Built by the Appwrite team" point3="Fewer moving parts" point4="Stronger path to production" cta="Try Imagine" url="https://imagine.dev/" /%} | ||
|
|
||
| # When Lovable may still be the better choice | ||
|
|
||
| This comparison is more useful when it is clear that the best tool depends on the job. | ||
|
|
||
| Lovable may still be the better fit when: | ||
|
|
||
| - You are primarily exploring an idea and want immediate visual output | ||
| - The app does not yet need a serious backend | ||
| - You want a polished concept quickly for feedback, pitching, or validation | ||
| - Your priority is interface iteration rather than production architecture | ||
|
|
||
| Those are legitimate priorities. The mistake is assuming every AI builder should be evaluated on the same axis. | ||
|
|
||
| If you are still testing whether the idea deserves investment, speed to concept may matter more than backend depth. If you are already planning for users, data, workflows, and operations, the balance changes. | ||
|
|
||
| # How to evaluate any Lovable alternative | ||
|
|
||
| If you are comparing tools in this category, these questions are usually more useful than a long feature checklist. | ||
|
|
||
| ## What happens after the first version? | ||
|
|
||
| Look beyond the initial output. Can the result evolve into something your team would actually want to maintain, or does the workflow create a likely rebuild later? | ||
|
|
||
| ## Is the backend integrated or deferred? | ||
|
|
||
| If your app needs auth, storage, data, or backend logic, this matters immediately. A tool that includes those capabilities in the building experience can save time and reduce architectural drift. | ||
|
|
||
| ## How many services will you need to add later? | ||
|
|
||
| A fast prototype can become an expensive setup if it depends on too many separate systems to become production-ready. | ||
|
|
||
| ## Does the tool match your stage? | ||
|
|
||
| Some tools are excellent for idea validation. Others are better for building the first real version of a product. Be honest about which phase you are actually in. | ||
|
|
||
| ## Are you optimizing for speed alone or for continuity? | ||
|
|
||
| The fastest path to a screen is not always the fastest path to a shipped product. Continuity matters, especially once a team starts building beyond the demo. | ||
|
|
||
| # Final thoughts | ||
|
|
||
| The best Lovable alternative is not the one that looks most similar to Lovable. It is the one that solves the next set of problems your team is likely to face. | ||
|
|
||
| Lovable remains a strong option for fast UI exploration and early validation. But for teams that want an AI builder connected to a real backend foundation from the start, [Imagine](https://imagine.dev/) stands out in a more meaningful way. | ||
|
|
||
| Its advantage is not only that it helps generate applications. It is that it does so within a workflow shaped around Appwrite's backend capabilities, which makes it more relevant for teams building products with real users, real data, and real operational needs. | ||
|
|
||
| That is why Imagine is one of the most worthwhile Lovable alternatives to explore in 2026, especially for teams thinking beyond the prototype. | ||
|
|
||
| # More resources | ||
|
|
||
| - [Imagine](https://imagine.dev/) | ||
| - [Introducing Imagine: from ideas to real products](/blog/post/introducing-imagine) | ||
| - [Comparing the best vibe coding tools](/blog/post/comparing-vibe-coding-tools) | ||
| - [Appwrite Sites documentation](/docs/products/sites) | ||
| - [Appwrite Storage documentation](/docs/products/storage) No newline at end of file |
Contributor
There was a problem hiding this comment.
Please split this unrelated blog post into a separate PR.
This file is not aligned with the impersonation-focused PR objective and adds unrelated review surface/risk. Keeping it separate will make rollout and rollback safer.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/routes/blog/post/best-lovable-alternative-worth-exploring/`+page.markdoc
around lines 1 - 164, This blog post (frontmatter title "Best Lovable
alternative worth exploring in 2026" with layout: post and the {% call_to_action
%} block) is unrelated to the impersonation-focused PR and must be removed from
this change set and submitted in its own PR; revert or remove the +page.markdoc
content from the current branch, create a new branch containing this markdown as
a standalone change with a clear commit message (e.g., "Add blog post: Best
Lovable alternative worth exploring in 2026"), and open a separate PR for that
file so rollout/rollback and review are isolated.
| When a user is marked as an impersonator, Appwrite also grants them the `users.read` scope. This allows trusted operators to list users in the project, which is especially useful when building internal admin-style tools that let support or QA teams search for a user and choose who to impersonate next. | ||
|
|
||
| {% arrow_link href="/docs/references/cloud/server-nodejs/users#updateImpersonator" %} | ||
| See the Users API reference for update impersonator |
Contributor
There was a problem hiding this comment.
Fix awkward link text phrasing.
The sentence “See the Users API reference for update impersonator” reads ungrammatically and may confuse readers.
✏️ Suggested copy fix
-See the Users API reference for update impersonator
+See the Users API reference to update the impersonator capability📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| See the Users API reference for update impersonator | |
| See the Users API reference to update the impersonator capability |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/routes/docs/products/auth/impersonation/`+page.markdoc at line 42, The
sentence "See the Users API reference for update impersonator" is ungrammatical;
update the copy in the +page.markdoc to a clear phrasing such as "See the Users
API reference for updating an impersonator" or "See the Users API reference for
the Update Impersonator endpoint" (locate the exact string "See the Users API
reference for update impersonator" and replace it).
|
|
||
| Appwrite Users API is used for managing users in server applications. | ||
| Users API can only be used with an API key with the [Server SDK](/docs/sdks#server), to manage all users. | ||
| Users API can only be used with an API key with the [Server SDK](/docs/sdks#server), to manage all users. |
Contributor
There was a problem hiding this comment.
Fix wording for readability on Line 8.
Current phrasing is awkward and can be tightened.
✏️ Proposed text fix
-Users API can only be used with an API key with the [Server SDK](/docs/sdks#server), to manage all users.
+Users API can only be used with an API key and the [Server SDK](/docs/sdks#server) to manage all users.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| Users API can only be used with an API key with the [Server SDK](/docs/sdks#server), to manage all users. | |
| Users API can only be used with an API key and the [Server SDK](/docs/sdks#server) to manage all users. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/routes/docs/products/auth/users/`+page.markdoc at line 8, Replace the
sentence "Users API can only be used with an API key with the [Server
SDK](/docs/sdks#server), to manage all users." with a clearer wording such as
"The Users API requires a Server SDK API key and is intended for server-side
user management." Locate the sentence by searching for the exact original phrase
in the docs page and update it in place to improve readability and concision.
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
1 participant
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.
What does this PR do?
(Provide a description of what this PR does.)
Test Plan
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)
Related PRs and Issues
(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)
Have you read the Contributing Guidelines on issues?
(Write your answer here.)
Summary by CodeRabbit
Release Notes
New Features
Documentation