Skip to content

SEO Blogs#2866

Open
aishwaripahwa12 wants to merge 6 commits intomainfrom
aishwari/seoblogs3
Open

SEO Blogs#2866
aishwaripahwa12 wants to merge 6 commits intomainfrom
aishwari/seoblogs3

Conversation

@aishwaripahwa12
Copy link
Copy Markdown
Contributor

2 SEO Blogs

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Apr 7, 2026

Greptile Summary

This PR adds two new SEO-focused blog posts to the Appwrite website, both authored by aishwari and dated 2026-04-07.

  • backend-platform-longevity-what-to-look-for-beyond-features: A practical guide on evaluating backend platforms for long-term viability, covering release cadence, governance, security posture, data portability, and self-hosting options. Concludes with Appwrite evaluated against each criterion.
  • how-to-evaluate-open-source-maturity-before-using-it-in-production: A checklist-style post covering OSS maturity signals (maintenance cadence, bus factor, license type, security posture, real-world adoption), also concluding with Appwrite scored against each criterion.
  • Both posts are marked unlisted: true, keeping them hidden from the public blog listing until ready for publication.
  • All previously flagged issues — the mismatched meta description on the longevity post and the two broken internal blog links — have been resolved in this revision.
  • All internal doc links (/docs/products/auth, /docs/products/databases, /docs/advanced/self-hosting, /docs/advanced/security, etc.) and external links resolve correctly.
  • Cover images are included under static/images/blog/ and registered in .optimize-cache.json.
  • The author: aishwari field is valid — the author page exists at src/routes/blog/author/aishwari/+page.markdoc.

Confidence Score: 5/5

This PR is safe to merge — it adds two well-structured, self-contained blog posts with no broken links, a valid author, and correct metadata.

All P0/P1 issues flagged in prior review rounds (mismatched meta description, two broken internal blog links) have been fully resolved. Both posts have a valid author (aishwari), correct cover images registered in the cache, valid internal doc links, and are marked unlisted: true to prevent premature public exposure. No remaining issues block merge.

No files require special attention.

Important Files Changed

Filename Overview
src/routes/blog/post/backend-platform-longevity-what-to-look-for-beyond-features/+page.markdoc New blog post on backend platform longevity; meta description, author, cover image, and all internal/external links are valid. Previously flagged broken link and mismatched description have been resolved.
src/routes/blog/post/how-to-evaluate-open-source-maturity-before-using-it-in-production/+page.markdoc New blog post on evaluating OSS maturity before production; all internal and external links are valid, content is accurate, and previously flagged broken link has been removed.
.optimize-cache.json Cache hash entries added for the two new cover images.
static/images/blog/backend-platform-longevity-what-to-look-for-beyond-features/cover.png New cover image for the backend platform longevity blog post.
static/images/blog/how-to-evaluate-open-source-maturity-before-using-it-in-production/cover.png New cover image for the open-source maturity evaluation blog post.

Reviews (3): Last reviewed commit: "Apply suggestion from @adityaoberai" | Re-trigger Greptile

aishwaripahwa12 and others added 4 commits April 7, 2026 12:35
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

Most backend platform comparisons focus on features: which authentication methods are supported, how the database query API works, whether there's a serverless functions layer. These are the wrong questions to lead with.

Features are table stakes. What actually determines whether a backend dependency was a good decision three years from now is whether the platform is still maintained, still trustworthy, and still something you can get off if you need to. Evaluating for longevity requires a different set of questions.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"table stakes" is not a term a lot of people will understand xD


# The real cost of a platform that doesn't last

When a backend platform is deprecated, acquired and sunset, or abandoned by its maintainers, the teams built on it absorb the full migration cost. That cost is rarely just "update your imports." It means migrating data out of proprietary formats, rewriting authentication flows, rebuilding API integrations, and doing all of it while your production application continues to serve users.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need slightly better context setting for that first sentence

Maybe even a little simplification

- [Appwrite self-hosting documentation](/docs/advanced/self-hosting)
- [Appwrite security overview](/docs/advanced/security)
- [Appwrite Databases documentation](/docs/products/databases)
- [Appwrite Authentication documentation](/docs/products/auth)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [Appwrite Authentication documentation](/docs/products/auth)
- [Appwrite Auth documentation](/docs/products/auth)


# Assess the bus factor

**Bus factor** refers to how many contributors would need to be hit by a bus before the project stalls. A project maintained by a single person is fundamentally higher risk than one with a team of active contributors, even if the solo maintainer is prolific.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd mention how this has been mentioned in the context of the software industry in the past

Then talk about the concerns of a low bus factor for any team and then correlate with OSS

Otherwise this can be a little too harsh xD

Comment on lines +60 to +63
- **MIT / Apache 2.0 / BSD**: Permissive licenses with few restrictions. You can use, modify, and distribute without open-sourcing your own code. Apache 2.0 adds an explicit patent grant.
- **GPL / LGPL / AGPL**: Copyleft licenses. GPL requires that derivative works also be GPL-licensed. AGPL extends this to software accessed over a network, which has significant implications for SaaS products.
- **Business Source License (BSL / BUSL)**: Source-available with a time delay. The code is not truly open source; commercial use is typically restricted for several years after each release. HashiCorp and Directus use this model.
- **Custom source-available licenses**: Some projects use proprietary licenses that look open source but restrict commercial use, competitive products, or modification. Read the actual text.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's verify whether this is accurate a mention a small disclaimer that each license has nuances beyond this summary and that people should verify their contents themselves


# How Appwrite scores against these criteria

[Appwrite](https://github.com/appwrite/appwrite) is an open-source backend platform for web, mobile, and AI apps. It provides [authentication](/docs/products/auth), [databases](/docs/products/databases), [file storage](/docs/products/storage), [serverless functions](/docs/products/functions), real-time subscriptions, and messaging in a single deployable unit. It can be [self-hosted](/docs/advanced/self-hosting) on any Docker-compatible infrastructure or used via [Appwrite Cloud](https://cloud.appwrite.io).
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No Sites mention?

This is a frequent issue and should be looked out for in advance

Comment on lines +112 to +114
# Evaluating Appwrite for your production stack

Running through the evaluation framework above with Appwrite:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Incomplete ending

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants