Conversation
Greptile SummaryThis PR adds two new SEO-focused blog posts to the Appwrite website, both authored by
Confidence Score: 5/5This 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 ( No files require special attention. Important Files Changed
Reviews (3): Last reviewed commit: "Apply suggestion from @adityaoberai" | Re-trigger Greptile |
src/routes/blog/post/backend-platform-longevity-what-to-look-for-beyond-features/+page.markdoc
Outdated
Show resolved
Hide resolved
src/routes/blog/post/backend-platform-longevity-what-to-look-for-beyond-features/+page.markdoc
Outdated
Show resolved
Hide resolved
...s/blog/post/how-to-evaluate-open-source-maturity-before-using-it-in-production/+page.markdoc
Outdated
Show resolved
Hide resolved
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. |
There was a problem hiding this comment.
"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. |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
| - [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. |
There was a problem hiding this comment.
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
| - **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. |
There was a problem hiding this comment.
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). |
There was a problem hiding this comment.
No Sites mention?
This is a frequent issue and should be looked out for in advance
| # Evaluating Appwrite for your production stack | ||
|
|
||
| Running through the evaluation framework above with Appwrite: |
2 SEO Blogs