diff --git a/.optimize-cache.json b/.optimize-cache.json index ef218fa5e1..1f378ae046 100644 --- a/.optimize-cache.json +++ b/.optimize-cache.json @@ -1262,11 +1262,14 @@ "static/images/blog/what-is-cdn/cover.png": "ef77860288e150c6c22f3950a5eae4c88aefefb6db204f10c2a0544e51548703", "static/images/blog/what-is-ciam/cover.png": "45a5261ae1bb8a38777f60a21ea60426c0832e3d58bf3164100548400d388ce1", "static/images/blog/what-is-cicd-a-complete-guide-for-developers/cover.png": "7abddce55b1467188faab83abd58189173bf9aba84de3d9f28fff0be8c6e9276", + "static/images/blog/what-is-crud-explained/cover.png": "d87be0ed92e3635f89e7cee99cc664ef47f272925edd139a36204c685b76e7d6", + "static/images/blog/what-is-database-sharding-a-beginners-guide/cover.png": "96f622830f5aaca980efbf0cc7a7229d2d80d1b27f9bf646f5ccc21edc9f4c85", "static/images/blog/what-is-docker-a-simple-guide-for-developers/cover.png": "acd9c50ad749fcf676dd58b38cc6bbffba913bf5d817c6b725bd2c305088689e", "static/images/blog/what-is-mcp/claude-mcp-chat.png": "26842cfebca3ec2cec89448e1c0d7ddb3f5421cc57acdb8780d48d30a54cad82", "static/images/blog/what-is-mcp/claude-mcp-tools.png": "3a5ae700867b8671b5c9e3af61b094aeb64611168463db66ff440e0d427ac6bc", "static/images/blog/what-is-mcp/cover.png": "dc4537990c91d6f1768c5ab8775e5c52239eb901b15e2e74fce8b5a018855c32", "static/images/blog/what-is-redis-a-complete-guide-for-developers/cover.png": "b7b87a372bbb99421c2ab6df37430da960728b5cf339f1803c432644154c764f", + "static/images/blog/what-is-server-side-rendering-a-beginners-guide/cover.png": "f73f07796f6f766b5e86aadf2e13269665384c2c0e3bc9cb83b3bba0f52fb5cd", "static/images/blog/when-custom-backend-stops-being-worth-it/cover.png": "d03b13c4e8f3294823a7883cdae89ca18a4030b170c51f597bd139c9ca274793", "static/images/blog/why-ai-generated-apps-need-backend/cover.png": "8761878c13c51dd8a720a625606b89b93d9c56651aed636fa1b2bd346bd4fd82", "static/images/blog/why-developers-choose-appwrite-auth/cover.png": "f56c37ebfc25191e113b928ff3cf144563be740159e46d75a427bdafdd11214b", diff --git a/src/routes/blog/post/what-is-crud-explained/+page.markdoc b/src/routes/blog/post/what-is-crud-explained/+page.markdoc new file mode 100644 index 0000000000..197c37db8f --- /dev/null +++ b/src/routes/blog/post/what-is-crud-explained/+page.markdoc @@ -0,0 +1,106 @@ +--- +layout: post +title: What is CRUD? Explained +description: Learn what CRUD means, how create, read, update, and delete map to APIs and databases, and how to build CRUD apps faster with Appwrite. +date: 2026-07-07 +cover: /images/blog/what-is-crud-explained/cover.avif +timeToRead: 5 +author: aditya-oberai +category: architecture +featured: false +unlisted: true +faqs: + - question: What does CRUD stand for? + answer: CRUD stands for Create, Read, Update, and Delete, the four basic operations for managing stored data in an application. + - question: What is CRUD in simple terms? + answer: "CRUD is the set of four things you can do with data: add it (create), view it (read), change it (update), and remove it (delete). Nearly every app does all four." + - question: Is CRUD the same as REST? + answer: "No. CRUD is the four data operations, while REST is a style for building web APIs. REST APIs commonly expose CRUD operations, which is why they're often confused, but they're different concepts." + - question: What is a CRUD app? + answer: A CRUD app is any application whose main job is to create, read, update, and delete records. To-do lists, blogs, and online stores are all CRUD apps at their core. +--- +CRUD stands for Create, Read, Update, and Delete, the four basic operations for managing data in almost any application. Together they cover everything you do with stored data: adding new records, retrieving them, changing them, and removing them. If an app stores information, it's almost certainly doing CRUD. + +Whether you're building a to-do list, a social network, or an enterprise dashboard, the underlying data work comes down to these four actions. This guide explains what CRUD is, what each operation does, how it maps to APIs and databases, and how to build a CRUD app, in plain language. + +# What does CRUD stand for? + +CRUD is an acronym for the four persistent storage operations every data-driven application relies on: + +* **Create:** add a new record. +* **Read:** retrieve one or more existing records. +* **Update:** change an existing record. +* **Delete:** remove a record. + +The term has been around [since the 1980s](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) and remains one of the most useful mental models in software. Almost any feature you can name, posting a comment, editing a profile, deleting a photo, viewing a feed, is a CRUD operation underneath. + +# The four CRUD operations explained + +Each operation maps to a specific action on your data. + +Create adds something new, such as registering a user or writing a blog post. It's the operation that grows your dataset. + +Read retrieves data without changing it, such as loading a profile page or listing search results. Reads are usually the most frequent operation in an app. + +Update modifies an existing record, such as editing a caption or changing a setting. Updates can replace an entire record or just change specific fields. + +Delete removes a record, such as discarding a draft or closing an account. Many apps use a "soft delete" that hides data instead of erasing it, so it can be recovered later. + +# How does CRUD map to HTTP methods and SQL? + +CRUD isn't tied to one technology. Its real power is that the same four ideas show up consistently across databases and web APIs, which makes systems predictable. + +In a REST API, CRUD maps to [HTTP methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods): Create is POST, Read is GET, Update is PUT or PATCH, and Delete is DELETE. + +In a SQL database, CRUD maps to statements: Create is [INSERT](https://www.postgresql.org/docs/current/sql-insert.html), Read is SELECT, Update is UPDATE, and Delete is DELETE. + +So a single "delete a comment" action might travel from a DELETE HTTP request in the browser, through your API, down to a DELETE SQL statement in the database. Recognizing this pattern makes unfamiliar codebases much easier to read. + +# CRUD vs REST: What's the difference? + +CRUD and REST are related but not the same, and mixing them up is common. + +CRUD describes the four operations you perform on data. [REST](https://developer.mozilla.org/en-US/docs/Glossary/REST) is an architectural style for designing web APIs, using resources, URLs, and HTTP methods. REST APIs very often expose CRUD operations, which is why the two get conflated. + +The simplest way to hold them apart: CRUD is what you do to data, and REST is how you might expose those actions over the web. You can do CRUD without REST, for example directly against a database, and a REST API can do more than plain CRUD. + +# Why is CRUD important? + +CRUD matters because it's a shared vocabulary and a reliable structure that shows up everywhere: + +* **A universal pattern.** Once you understand CRUD, you can reason about almost any app's data layer, because they nearly all follow it. +* **Predictable design.** Structuring an API or database around CRUD makes it consistent and easier for other developers to use. +* **Faster development.** Many frameworks and platforms scaffold CRUD automatically, so you get standard data operations without writing them from scratch. +* **A clear foundation.** More advanced features are usually built on top of solid CRUD, so getting it right early pays off. + +# What does a CRUD app look like? + +Almost every app you use is a CRUD app at its core. A to-do list is the clearest example: you create tasks, read your list, update a task when it's done, and delete tasks you no longer need. + +The same holds for bigger products. On a social network, creating is posting, reading is scrolling the feed, updating is editing a post, and deleting is removing it. On an online store, products, orders, and customer records are all created, read, updated, and deleted. Strip away the branding and most software is a well-organized set of CRUD operations with a nice interface on top. + +# How do I build a CRUD app? + +Building CRUD from scratch means setting up a database, writing an API layer with an endpoint for each operation, handling validation and permissions, and connecting a frontend. It's straightforward but repetitive, and every project reinvents much of the same plumbing. + +Alternatively, you can use a backend platform that provides CRUD operations out of the box. Instead of writing your own create, read, update, and delete endpoints, you define your data and call ready-made methods from an SDK. For most teams this removes a large chunk of boilerplate and lets you focus on the parts of your app that are actually unique. + +# 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 + +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. + +## Resources + +* [Appwrite Databases docs](https://appwrite.io/docs/products/databases) +* [Create and manage documents](https://appwrite.io/docs/products/databases/documents) +* [Appwrite quick start guides](https://appwrite.io/docs/quick-starts) +* [Appwrite on GitHub](https://github.com/appwrite/appwrite) +* [Join the Appwrite Discord](https://appwrite.io/discord) \ No newline at end of file diff --git a/src/routes/blog/post/what-is-database-sharding-a-beginners-guide/+page.markdoc b/src/routes/blog/post/what-is-database-sharding-a-beginners-guide/+page.markdoc new file mode 100644 index 0000000000..9f2f39deb4 --- /dev/null +++ b/src/routes/blog/post/what-is-database-sharding-a-beginners-guide/+page.markdoc @@ -0,0 +1,115 @@ +--- +layout: post +title: "What is database sharding? A beginner's guide" +description: Learn what database sharding is, how it works, common strategies, benefits, tradeoffs, and when to use it to scale large applications effectively. +date: 2026-07-07 +cover: /images/blog/what-is-database-sharding-a-beginners-guide/cover.avif +timeToRead: 5 +author: atharva +category: architecture +featured: false +unlisted: true +faqs: + - question: What is a shard key? + answer: A shard key is the piece of data, such as a user ID or region, used to decide which shard a record goes to. A well-chosen key spreads data and traffic evenly across shards. + - question: What is the difference between sharding and partitioning? + answer: Partitioning is dividing a database into smaller parts, which can be on the same server. Sharding is a type of partitioning where those parts are spread across multiple servers. All sharding is partitioning, but not all partitioning is sharding. + - question: What is the difference between sharding and replication? + answer: Sharding splits different data across servers to scale. Replication copies the same data to multiple servers for availability and faster reads. Large systems often use both together. + - question: When should I shard my database? + answer: "Only when a single server can no longer handle your data or traffic, and after you've tried simpler fixes like indexing, caching, and read replicas. For most apps, sharding is never necessary." + - question: What are the main sharding strategies? + answer: The common strategies are range-based, hash-based, directory-based, and geo-based sharding. Hash-based is popular for even distribution, while range and geo strategies suit specific query and location needs. +--- +**Database sharding is the practice of splitting a large database into smaller, faster pieces called shards, each holding part of the data on a separate server.** It lets a database scale horizontally, handling far more data and traffic than a single machine ever could, by spreading the load across many machines. + +When an app grows to the point where one database server can't keep up, sharding is one of the main ways to break through that ceiling. This guide explains what sharding is, how it works, the main strategies, how it differs from partitioning and replication, and when you actually need it, in plain language. + +# How does database sharding work? + +A single database server has hard limits on storage, memory, and how many requests it can handle. Once your data or traffic outgrows those limits, you have two options: buy a bigger server (vertical scaling), which eventually hits a wall and gets expensive, or spread the data across many servers (horizontal scaling). Sharding is how you do the second. + +Sharding splits your data into shards, where each shard is a separate database holding a distinct subset of the rows. For example, users with IDs 1 to 1,000,000 might live on shard A, and the next million on shard B. When a request comes in, the system uses a rule to decide which shard holds the relevant data and routes the query there. + +The result is that no single server holds everything or handles all the traffic. Each shard is smaller, faster, and only responsible for its slice of the data. + +# What is a shard key? + +The shard key is the piece of data used to decide which shard a record belongs to, and it's [the single most important decision](https://www.mongodb.com/docs/manual/core/sharding-choose-a-shard-key/) in a sharded system. + +A good shard key spreads data and traffic evenly across shards and matches how your app queries data, so most requests hit a single shard. A poor choice creates "hot shards" that get far more traffic than the others, which recreates the very bottleneck you were trying to escape. Common shard keys include a user ID, a customer or tenant ID, or a geographic region. Because changing a shard key later is painful, it's worth getting right early. + +# Database sharding strategies explained + +There are several ways to map a shard key to a shard, each with tradeoffs: + +* **Range-based sharding:** rows are split by [ranges of the key](https://www.mongodb.com/docs/manual/core/ranged-sharding/), such as A to M on one shard and N to Z on another. It's simple and good for range queries, but can create uneven load if data isn't evenly distributed. +* **Hash-based sharding:** a [hash function](https://en.wikipedia.org/wiki/Consistent_hashing) is applied to the key to assign a shard, which spreads data very evenly. The downside is that range queries become inefficient because related rows are scattered. +* **Directory-based sharding:** a lookup table maps keys to shards. This is flexible and easy to rebalance, but the lookup table itself becomes a component you must keep fast and available. +* **Geo-based sharding:** data is placed on shards near the users who use it, reducing latency for a global audience. + +Hash-based sharding is a common default for even distribution, while range and geo strategies fit specific query and locality needs. + +# Sharding vs partitioning: What's the difference? + +These terms overlap and are often used loosely, which causes confusion. + +Partitioning is the general idea of dividing a database into smaller parts. Those parts can live on the same server (vertical or [horizontal partitioning](https://www.postgresql.org/docs/current/ddl-partitioning.html)) to keep tables manageable. + +Sharding is a specific type of horizontal partitioning where the parts are spread across multiple servers. So all sharding is partitioning, but not all partitioning is sharding. The defining feature of sharding is that the pieces sit on different machines to enable horizontal scale. + +# Sharding vs replication: What's the difference? + +Sharding and replication both involve multiple database servers, but they solve different problems and are often used together. + +Sharding splits different data across servers, so each shard holds a unique subset. Its goal is scale, spreading data and load so no single server is overwhelmed. + +[Replication](https://dev.mysql.com/doc/refman/8.0/en/replication.html) copies the same data to multiple servers. Its goal is availability and read performance, so if one server fails another has a copy, and reads can be spread across replicas. + +In large systems you typically shard for scale and then replicate each shard for reliability, getting the benefits of both. + +# Benefits of database sharding + +Sharding is worth the effort when you truly need it, because it unlocks things a single server can't offer: + +* **Horizontal scalability.** You can keep adding servers to handle more data and traffic, rather than hitting the ceiling of one machine. +* **Better performance.** Each shard holds less data, so queries run against smaller datasets and return faster. +* **Higher throughput.** Traffic is spread across many servers, so the system handles far more concurrent requests. +* **Improved fault isolation.** A problem on one shard affects only that slice of data, not the entire database. + +# Drawbacks and challenges of database sharding + +Sharding is powerful but genuinely hard, and it introduces problems you don't have with a single database: + +* **Significant complexity.** Your application and infrastructure must know how to route queries and manage many databases instead of one. +* **Cross-shard queries are hard.** Queries that need data from multiple shards, including many joins, become slow and complicated. +* **Rebalancing is painful.** As data grows unevenly, moving data between shards to even things out is a difficult, risky operation. +* **Operational overhead.** Backups, migrations, and monitoring all multiply across shards. + +Because of this, sharding is usually a last resort after simpler options like better indexing, caching, and replication have been exhausted. + +# When should you shard your database? + +You should consider sharding only when a single database server can no longer handle your data volume or traffic, and you've already tried the cheaper fixes: optimizing queries, adding indexes, caching frequent reads, and using read replicas. Sharding makes sense for very large-scale applications with huge datasets or extremely high write throughput. + +For most apps, that day never comes, and adding sharding early buys complexity you don't need. The right time to shard is when you have a concrete scaling problem that simpler measures can't solve, not in anticipation of one. + +# 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 + +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 a scalable, managed data layer with a clean API, so you can focus on your app instead of standing up and operating your own database infrastructure. That means you defer the complexity of scaling decisions like sharding until you genuinely need them, and lean on a managed backend when you do. + +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. + +## Resources + +* [Appwrite Databases docs](https://appwrite.io/docs/products/databases) +* [Query and manage data](https://appwrite.io/docs/products/databases/queries) +* [Appwrite quick start guides](https://appwrite.io/docs/quick-starts) +* [Appwrite on GitHub](https://github.com/appwrite/appwrite) +* [Join the Appwrite Discord](https://appwrite.io/discord) diff --git a/src/routes/blog/post/what-is-server-side-rendering-a-beginners-guide/+page.markdoc b/src/routes/blog/post/what-is-server-side-rendering-a-beginners-guide/+page.markdoc new file mode 100644 index 0000000000..0d4d9596e6 --- /dev/null +++ b/src/routes/blog/post/what-is-server-side-rendering-a-beginners-guide/+page.markdoc @@ -0,0 +1,111 @@ +--- +layout: post +title: "What is server-side rendering? A beginner's guide" +description: Learn what server-side rendering is, how SSR works, how it compares to CSR and SSG, and when to use it for faster, SEO-friendly web applications. +date: 2026-07-07 +cover: /images/blog/what-is-server-side-rendering-a-beginners-guide/cover.avif +timeToRead: 5 +author: atharva +category: architecture +featured: false +unlisted: true +faqs: + - question: What is the difference between SSR and CSR? + answer: SSR builds the page on the server so the first load is fast and SEO-friendly. CSR (client-side rendering) builds the page in the browser, which is smoother once loaded but slower on first load and weaker for SEO. + - question: What is the difference between SSR and SSG? + answer: SSR builds a page on every request, so content is always current. SSG (static site generation) builds all pages once at build time and serves them as static files, which is faster and cheaper but only updates when you rebuild. + - question: Is SSR good for SEO? + answer: Yes. Because search engine crawlers receive fully rendered HTML rather than an empty page that relies on JavaScript, server-rendered content is more reliably indexed. + - question: Which framework is best for SSR? + answer: "There's no single best. Next.js is the most popular choice for React, Nuxt for Vue, SvelteKit for Svelte, and Remix for React. The right one depends on the frontend framework you're already using." +--- +**Server-side rendering (SSR) is when a web page's HTML is fully generated on the server for each request and sent to the browser ready to display, instead of being built in the browser with JavaScript.** This gives users content faster on first load and makes pages easier for search engines to index. + +If you've heard SSR mentioned alongside frameworks like Next.js, or wondered why some apps feel instant while others show a blank screen first, this is the concept behind it. This guide explains what server-side rendering is, how it works, how it compares to other rendering methods, and when you actually need it, in plain language. + +# How does server-side rendering work? + +To understand SSR, it helps to know the alternative. With [client-side rendering](https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Rendering_and_compositing), the server sends a nearly empty HTML file plus a JavaScript bundle. The browser then downloads and runs that JavaScript to build the page. Until it finishes, the user often sees a blank screen or a loading spinner. + +Server-side rendering flips this around: + +1. The browser requests a page. +2. The server runs the application code, fetches any data it needs, and renders the full HTML for that page. +3. The server sends complete, ready-to-display HTML to the browser. +4. The browser shows the content almost immediately, then loads JavaScript to make the page interactive. + +The key difference is where the work happens. SSR does the rendering on the server for every request, so the user sees real content sooner instead of waiting for their device to build the page. + +# Server-side rendering vs client-side rendering: What's the difference? + +This is the core comparison, and each approach has clear tradeoffs. + +Client-side rendering (CSR) builds the page in the browser. It makes for smooth navigation once loaded and reduces server work, but the first load is slower and the initial HTML is nearly empty, which can hurt SEO. + +Server-side rendering (SSR) builds the page on the server. The first load is faster and search engines receive full content, at the cost of more work per request on the server. + +A simple way to choose: reach for CSR for highly interactive apps behind a login, like dashboards, where first-load SEO doesn't matter. Reach for SSR for content that needs to load fast and rank well, like marketing pages, blogs, and storefronts. + +# Server-side rendering vs static site generation + +SSR is often confused with static site generation (SSG), because both send real HTML to the browser. The difference is *when* that HTML is built. + +SSR generates the page on every request, so the content is always current and can be personalized per user. SSG generates all pages once at build time, so they're served as static files that are extremely fast and cheap, but the content is fixed until the next build. + +Use SSG for content that rarely changes, such as documentation or a landing page. Use SSR when content is dynamic or personalized and needs to be fresh on every visit. + +# 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. + +# Benefits of server-side rendering + +SSR is popular because it solves real problems that pure client-side apps struggle with: + +* **Faster first contentful paint.** Users see meaningful content sooner because the browser doesn't have to build the page before showing anything. ([First Contentful Paint](https://web.dev/articles/fcp) is a core web performance metric.) +* **Better SEO.** Search engine crawlers receive fully rendered HTML, so your content is reliably indexed instead of hidden behind JavaScript. +* **Strong performance on weak devices.** The heavy rendering happens on the server, so low-powered phones and older devices aren't doing the work. +* **Accurate link previews.** Social platforms read the server-rendered HTML, so shared links show correct titles and images. + +# Drawbacks of server-side rendering + +SSR isn't free, and it adds complexity you should weigh: + +* **Higher server load.** Rendering on every request uses more server resources than serving static files, which can raise costs at scale. +* **Slower time to first byte.** The server does work before sending anything, so the very first byte can arrive later than with a static page. +* **More complexity.** SSR apps are harder to build, deploy, and debug than purely client-side ones, since code runs in two environments. +* **Caching challenges.** Because pages are dynamic, caching them effectively takes more thought than caching static output. + +# Which frameworks support server-side rendering? + +You rarely implement SSR by hand. Modern frameworks handle the heavy lifting and often let you mix rendering strategies per page. The most common options are [Next.js](https://nextjs.org/docs) for React, [Nuxt](https://nuxt.com/docs) for Vue, [SvelteKit](https://kit.svelte.dev/docs) for Svelte, and Remix for React. Angular offers SSR through Angular Universal. + +Many of these frameworks now support hybrid rendering, letting you choose SSR, SSG, or client-side rendering for each route, so you can match the approach to the content instead of committing your whole app to one method. + +# When should you use server-side rendering? + +SSR is worth it when fast initial load and search visibility matter, such as for content-heavy or public-facing pages: marketing sites, blogs, ecommerce product pages, and news. It's also useful when pages must be personalized per request yet still load quickly. + +It's usually overkill for internal tools, dashboards, and apps behind a login where SEO is irrelevant and users don't mind a brief initial load. In those cases, client-side rendering is simpler and often good enough. As with most architecture choices, match the rendering method to the job rather than defaulting to one everywhere. + +# 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 + +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. + +## Resources + +* [Appwrite server SDKs](https://appwrite.io/docs/sdks) +* [Server-side rendering with Appwrite](https://appwrite.io/docs/products/auth/server-side-rendering) +* [Appwrite quick start guides](https://appwrite.io/docs/quick-starts) +* [Appwrite on GitHub](https://github.com/appwrite/appwrite) +* [Join the Appwrite Discord](https://appwrite.io/discord) \ No newline at end of file diff --git a/static/images/blog/what-is-crud-explained/cover.avif b/static/images/blog/what-is-crud-explained/cover.avif new file mode 100644 index 0000000000..5a79a01427 Binary files /dev/null and b/static/images/blog/what-is-crud-explained/cover.avif differ diff --git a/static/images/blog/what-is-database-sharding-a-beginners-guide/cover.avif b/static/images/blog/what-is-database-sharding-a-beginners-guide/cover.avif new file mode 100644 index 0000000000..42bba1e56c Binary files /dev/null and b/static/images/blog/what-is-database-sharding-a-beginners-guide/cover.avif differ diff --git a/static/images/blog/what-is-server-side-rendering-a-beginners-guide/cover.avif b/static/images/blog/what-is-server-side-rendering-a-beginners-guide/cover.avif new file mode 100644 index 0000000000..f980aa7a42 Binary files /dev/null and b/static/images/blog/what-is-server-side-rendering-a-beginners-guide/cover.avif differ