SEO Blogs (CRUD, Database sharading, server-side rendering)#3087
Open
aishwaripahwa12 wants to merge 17 commits into
Open
SEO Blogs (CRUD, Database sharading, server-side rendering)#3087aishwaripahwa12 wants to merge 17 commits into
aishwaripahwa12 wants to merge 17 commits into
Conversation
Appwrite WebsiteProject ID: Website (appwrite/website)Project ID: Tip Messaging handles push notifications, emails, and SMS through one unified API |
Contributor
Greptile SummaryThis PR adds three new SEO-focused blog posts (CRUD, database sharding, and server-side rendering) along with their cover images and corresponding cache entries. All posts are marked
Confidence Score: 4/5Safe to merge after fixing the broken docs link in the CRUD post; the sharding and SSR posts are clean. The CRUD blog post's resources section links to /docs/products/databases/documents, which does not exist as a route in this repository. A reader following that link would hit a 404. The correct current page for the TablesDB API used in the code example is /docs/products/databases/rows. The other two blog posts and the cache updates are clean. src/routes/blog/post/what-is-crud-explained/+page.markdoc — the resource link needs to be updated from /docs/products/databases/documents to /docs/products/databases/rows. Important Files Changed
Reviews (14): Last reviewed commit: "Apply suggestion from @aishwaripahwa12" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
adityaoberai
reviewed
Jul 7, 2026
Comment on lines
+97
to
+108
| # Conclusion | ||
|
|
||
| Database sharding splits a large database into smaller shards spread across multiple servers, letting it scale horizontally to handle more data and traffic than any single machine could. The heart of a sharded system is the shard key, which determines how evenly data and load are distributed, and the strategy you choose, such as hash-based or range-based, shapes how your queries perform. Sharding is distinct from partitioning, which can happen on one server, and from replication, which copies data for availability rather than splitting it for scale. | ||
|
|
||
| The practical takeaway is that sharding is a powerful but complex tool best reserved for real scaling problems. Exhaust indexing, caching, and replication first, and lean on managed infrastructure so you're not carrying the operational weight of many databases by hand. | ||
|
|
||
| # Conclusion | ||
|
|
||
| Database sharding splits a large database into smaller shards spread across multiple servers, letting it scale horizontally to handle more data and traffic than any single machine could. The heart of a sharded system is the shard key, which determines how evenly data and load are distributed, and the strategy you choose, such as hash-based or range-based, shapes how your queries perform. Sharding is distinct from partitioning, which can happen on one server, and from replication, which copies data for availability rather than splitting it for scale. | ||
|
|
||
| The practical takeaway is that sharding is a powerful but complex tool best reserved for real scaling problems. Exhaust indexing, caching, and replication first, and lean on managed infrastructure so you're not carrying the operational weight of many databases by hand. | ||
|
|
Contributor
There was a problem hiding this comment.
Two conclusion sections?
Comment on lines
+101
to
+103
| Appwrite Cloud gives developers a fully managed backend so you can ship fast without provisioning or maintaining any infrastructure. You get storage, auth, databases, functions, and real-time out of the box, with file storage that scales automatically as your app grows. It provides server-side SDKs and SSR-friendly authentication, so you can fetch data and manage sessions securely on the server in frameworks like Next.js, Nuxt, and SvelteKit. With Databases, Storage, and Functions behind a clean API, the backend for your server-rendered app is ready to go. | ||
|
|
||
| Whether you're prototyping your next idea or scaling a production app, Appwrite gives you auth, databases, storage, functions, and real-time in one place, all open-source. [Sign up for Appwrite Cloud](https://cloud.appwrite.io/) or spin up a self-hosted instance in minutes, and give your next build a real backend to grow on. |
Contributor
There was a problem hiding this comment.
We should have more info on how Sites actually supports this, this is too generic
adityaoberai
requested changes
Jul 7, 2026
Comment on lines
+96
to
+98
| Appwrite Cloud gives developers a fully managed backend so you can ship fast without provisioning or maintaining any infrastructure. You get storage, auth, databases, functions, and real-time out of the box, with file storage that scales automatically as your app grows. Its Databases product gives you full CRUD out of the box through a clean API and SDKs for every major platform, so you can create, read, update, and delete records without writing and maintaining your own endpoints. Built-in permissions and queries mean the hard parts are handled for you. | ||
|
|
||
| Whether you're prototyping your next idea or scaling a production app, Appwrite gives you auth, databases, storage, functions, and real-time in one place, all open-source. [Sign up for Appwrite Cloud](https://cloud.appwrite.io/) or spin up a self-hosted instance in minutes, and give your next build a real backend to grow on. |
Contributor
There was a problem hiding this comment.
We should have simple code examples here
adityaoberai
reviewed
Jul 7, 2026
adityaoberai
reviewed
Jul 7, 2026
|
|
||
| Appwrite Cloud gives developers a fully managed backend so you can ship fast without provisioning or maintaining any infrastructure. You get storage, auth, databases, functions, and real-time out of the box, with file storage that scales automatically as your app grows. It provides server-side SDKs and SSR-friendly authentication, so you can fetch data and manage sessions securely on the server in frameworks like Next.js, Nuxt, and SvelteKit. With Databases, Storage, and Functions behind a clean API, the backend for your server-rendered app is ready to go. | ||
|
|
||
| Whether you're prototyping your next idea or scaling a production app, Appwrite gives you auth, databases, storage, functions, and real-time in one place, all open-source. [Sign up for Appwrite Cloud](https://cloud.appwrite.io/) or spin up a self-hosted instance in minutes, and give your next build a real backend to grow on. |
Co-authored-by: Aditya Oberai <adityaoberai1@gmail.com>
Co-authored-by: Aditya Oberai <adityaoberai1@gmail.com>
Comment on lines
+57
to
+61
| # What is hydration in server-side rendering? | ||
|
|
||
| Hydration is the step that makes server-rendered HTML interactive. When SSR sends a fully rendered page, that HTML is static at first, so buttons and other interactive elements don't work yet. | ||
|
|
||
| Once the browser loads the JavaScript, the framework ["hydrates"](https://react.dev/reference/react-dom/client/hydrateRoot) the page by attaching event listeners and application state to the existing HTML, turning the static page into a live, interactive app. Hydration is powerful but has a cost: shipping and running that JavaScript takes time, and heavy hydration can delay when a page becomes usable. Reducing this cost is a major focus of modern frameworks. |
Contributor
There was a problem hiding this comment.
Why is this a separate section and not a part of other existing sections? Does it need to stand out separately?
Comment on lines
+93
to
+107
| # Conclusion | ||
|
|
||
| Server-side rendering generates a page's HTML on the server for each request and sends it ready to display, so users see content faster and search engines can index it reliably. It differs from client-side rendering, which builds the page in the browser, and from static site generation, which builds pages once at build time. The tradeoff for SSR's speed and SEO benefits is more server work and added complexity, with hydration bridging the gap between static HTML and a fully interactive app. | ||
|
|
||
| The practical takeaway is to use SSR where first-load speed and search visibility genuinely matter, lean on a framework to handle it, and pair it with a backend that works cleanly on the server so data fetching stays fast and secure. | ||
|
|
||
| # Start building SSR apps with Appwrite | ||
|
|
||
| As the conclusion above puts it, SSR comes down to two things: a framework to do the rendering, and a backend that works cleanly on the server. Appwrite gives you a home for both. | ||
|
|
||
| [Appwrite Sites](/docs/products/sites) is where your server-rendered app runs. You deploy a framework like Next.js, Nuxt, or SvelteKit directly to Sites, and it executes the framework's server runtime for you, handling the per-request rendering this guide describes without you provisioning or maintaining servers. Because Sites lives in the same platform as the rest of your backend, your app renders right next to its data instead of reaching across the internet on every request. | ||
|
|
||
| That proximity is what makes the data-fetching step fast and secure. Appwrite's [server SDKs](/docs/sdks) and [SSR-friendly authentication](/docs/products/auth/server-side-rendering) let you load data and manage sessions on the server, so the first render already contains real content and no session secrets ever reach the browser. Databases, Storage, and Functions sit behind the same clean API, so everything your server render needs is one call away. | ||
|
|
||
| The result is the full SSR stack in one place: Sites runs the rendering, and Auth, Databases, Storage, and Functions feed it, all open-source and managed for you. [Sign up for Appwrite Cloud](https://cloud.appwrite.io/) or spin up a self-hosted instance in minutes, and give your next server-rendered build a real backend to grow on. |
Contributor
There was a problem hiding this comment.
Why is the Conclusion not the final section?
Comment on lines
+97
to
+109
| # Conclusion | ||
|
|
||
| Database sharding splits a large database into smaller shards spread across multiple servers, letting it scale horizontally to handle more data and traffic than any single machine could. The heart of a sharded system is the shard key, which determines how evenly data and load are distributed, and the strategy you choose, such as hash-based or range-based, shapes how your queries perform. Sharding is distinct from partitioning, which can happen on one server, and from replication, which copies data for availability rather than splitting it for scale. | ||
|
|
||
| The practical takeaway is that sharding is a powerful but complex tool best reserved for real scaling problems. Exhaust indexing, caching, and replication first, and lean on managed infrastructure so you're not carrying the operational weight of many databases by hand. | ||
|
|
||
| # Start building scalable apps with Appwrite | ||
|
|
||
| The recurring theme in this guide is that sharding is a last resort, and that for most apps the day you need it never comes. The catch is that scaling problems tend to arrive right when you have the least time to re-architect your data layer, so the real win is not having to make that call yourself. | ||
|
|
||
| That's the gap a managed backend fills. Appwrite's [Databases](/docs/products/databases) product gives you a scalable data layer behind a clean API, so the infrastructure decisions this article describes, when to partition, when to replicate, when to shard, stay the platform's problem instead of yours. You get indexing and [queries](/docs/products/databases/queries) to handle performance early, the simpler fixes you should reach for first, without provisioning or operating any of it yourself. | ||
|
|
||
| So you follow the advice above by default: build on a managed backend, use the cheap optimizations while they carry you, and defer the genuine complexity of sharding until you have a concrete problem that demands it. Appwrite also bundles auth, storage, functions, real-time, and Sites in the same place, all open-source. [Sign up for Appwrite Cloud](https://cloud.appwrite.io/) or spin up a self-hosted instance in minutes, and give your next build a real backend to grow on. |
Contributor
There was a problem hiding this comment.
Conclusion before the final section?
Comment on lines
+88
to
+96
| # Conclusion | ||
|
|
||
| CRUD stands for Create, Read, Update, and Delete, the four operations at the heart of nearly every application that stores data. The pattern is powerful because it's consistent: the same four ideas map cleanly onto HTTP methods in an API and onto statements in a database, which makes systems predictable and easier to build. CRUD is separate from REST, which is one common way to expose those operations over the web. | ||
|
|
||
| The practical takeaway is that once you can spot CRUD, most software becomes easier to understand and build, and you rarely need to write those four operations by hand when a good backend already provides them. | ||
|
|
||
| # Start building CRUD apps with Appwrite | ||
|
|
||
| Because CRUD is such a universal pattern, [Appwrite](https://appwrite.io/) gives you all four operations out of the box. Instead of standing up a database, writing a separate endpoint for each operation, and wiring permissions by hand, you define your data once and call ready-made methods from the SDK. |
Contributor
There was a problem hiding this comment.
Conclusion before the final section?
Co-authored-by: Aditya Oberai <adityaoberai1@gmail.com>
aishwaripahwa12
commented
Jul 22, 2026
aishwaripahwa12
commented
Jul 22, 2026
aishwaripahwa12
commented
Jul 22, 2026
aishwaripahwa12
commented
Jul 24, 2026
aishwaripahwa12
commented
Jul 24, 2026
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
2 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.
Latest SEO blogs