add next outputs blog #2615
add next outputs blog #2615
Conversation
WalkthroughA new blog post page was added at src/routes/blog/post/nextjs-output-modes/+page.markdoc. The file contains front-matter metadata and a long-form article describing Next.js output modes (default vs standalone), including observations about bundling behavior, benchmarked build size and runtime comparisons, guidance on when to choose each mode, and reference links. Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Tip 📝 Customizable high-level summaries are now available in beta!You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.
Example instruction:
Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/routes/blog/post/nextjs-output-modes/+page.markdoc (1)
37-68: Minor phrasing issue in benchmark commentary.Line 68 has awkward wording: "Funnily same build size" should be revised for clarity and natural flow.
Apply this diff to improve readability:
-The result is clear: standalone mode wins as it's consistently shown lower build sizes. Funnily same build size because even though we install heavy dependencies, we aren't actually importing/using them at all in the apps, so these dependencies aren't even getting traced and bundled, which is ideal! Lower build sizes mean faster cold starts on your app. +The result is clear: standalone mode wins with consistently lower build sizes. Interestingly, both standalone builds show the same size because even though we install heavy dependencies, we aren't actually importing them in the apps—so these dependencies don't get traced or bundled, which is ideal! Lower build sizes mean faster cold starts for your app.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
static/images/blog/nextjs-output-modes/cover.pngis excluded by!**/*.png
📒 Files selected for processing (1)
src/routes/blog/post/nextjs-output-modes/+page.markdoc(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-18T21:53:20.881Z
Learnt from: atharvadeosthale
Repo: appwrite/website PR: 2614
File: src/routes/docs/products/sites/one-click-deployment/+page.markdoc:74-122
Timestamp: 2025-11-18T21:53:20.881Z
Learning: Appwrite Sites one-click deployment supports the following framework presets: Analog (analog), Angular (angular), Next.js (nextjs), React (react), Nuxt (nuxt), Vue (vue), SvelteKit (sveltekit), Astro (astro), TanStack Start (tanstack-start), Remix (remix), Lynx (lynx), Flutter (flutter), React Native (react-native), Vite (vite), and Other (other).
Applied to files:
src/routes/blog/post/nextjs-output-modes/+page.markdoc
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: assets
- GitHub Check: build
- GitHub Check: tests
🔇 Additional comments (4)
src/routes/blog/post/nextjs-output-modes/+page.markdoc (4)
13-35: Clear and engaging explanation of Next.js output modes.The introduction and explanations of default vs standalone modes are well-structured and informative. The progression from concept → comparison → observations → recommendations follows good article flow.
70-78: Practical and balanced recommendations.The section appropriately acknowledges trade-offs, providing realistic guidance (try standalone, fall back if issues arise) rather than absolute recommendations. The edge cases mentioned (monorepos, dynamic imports) are reasonable cautions.
1-11: Front matter structure and all assets verified.Cover image asset and both linked blog posts confirmed to exist in the repository. The blog post is ready for publication.
80-85: Linked blog posts verified and ready.Both referenced blog posts exist in the repository with substantive content:
src/routes/blog/post/nextjs-standalone-support-in-appwrite-sites/+page.markdoc(1,871 bytes)src/routes/blog/post/everything-new-in-nextjs16/+page.markdoc(7,143 bytes)The URL paths in the wrap-up section match the directory structure correctly. No action needed.
|
Two things - it's not really a tutorial so does it make sense to update the category? Also, can we use a different word than "funnily" as it throws off the content |
| @@ -0,0 +1,85 @@ | |||
| --- | |||
| layout: post | |||
| title: Next.js output modes — Standalone vs Normal build | |||
There was a problem hiding this comment.
Lets double check what they call the "normal build", worried it might not be accurate term. if we cant find any, "default" might be better.
| Next.js is a very popular React framework. People choose it because it blends in with the server very well, using both client-side and server-side capabilities to provide a better user experience. Next.js is packed with cutting-edge React features like RSC. However, such complexity also brings complexity in deploying your app. | ||
|
|
||
| Appwrite Sites enables you to deploy your Next.js app seamlessly without any hassle of configuration. Appwrite handles all the complexity involved in deploying such complex apps, so that you can focus on the core logic of your app. | ||
|
|
There was a problem hiding this comment.
I just read complex 4 times. I think thats too much
| This results in bigger `.next` folder, but we also have to factor in the fact that `node_modules` are essential for the default mode, and not the standalone mode. | ||
|
|
||
| However, there's a very good reason for this mode not being the default yet. | ||
|
|
There was a problem hiding this comment.
There is also static mode (output: export). And in there a few configurations useful specifically or SPA too (like railing shash,
| It's important to note that if you remove `node_modules`, which usually is the biggest chunk of your app, your app won't run anymore, as your builds also rely on `node_modules` to work properly. So, when counting the size of your app, you should also count in `node_modules` folder as well. | ||
|
|
||
| You might already think, shipping `node_modules` is a very big size hit, and it's true, but not always a bad thing. We will look at why later. | ||
|
|
There was a problem hiding this comment.
Another big part is "magic box" approach - nuxt start does something which you dont really understand. and you can configure some stuff, like port, but you cannot configure others, like custom middleware or global error handling.
You can do those things directly in next.js, but still, some setups, like appwite/website, benefits from ability to inject some scripts into HTTP listener itself.
| When building your app in standalone mode, Next.js traces all the files that are required by your app from your `node_modules`. This means that only the functionality your app uses will be bundled into your Next.js build. In this case, you can exclude `node_modules` when calculating sizes, as the build doesn't rely on `node_modules` as it already bundles all necessary code. | ||
|
|
||
| This results in bigger `.next` folder, but we also have to factor in the fact that `node_modules` are essential for the default mode, and not the standalone mode. |
There was a problem hiding this comment.
From what I remember, you dont need to ship entire .next folder, you only need .nex/standalone.
And there is downside - this doesnt bundle static assets, as they recommend to deploy them on CDN or S3 instead.
So for minimal setup, you need a few extra commands to copy static assets into this standalone directory.
| Standalone mode: +0 KB (0.0% increase) | ||
| ``` | ||
|
|
||
| The result is clear: standalone mode wins as it's consistently shown lower build sizes. Funnily same build size because even though we install heavy dependencies, we aren't actually importing/using them at all in the apps, so these dependencies aren't even getting traced and bundled, which is ideal! Lower build sizes mean faster cold starts on your app. |
There was a problem hiding this comment.
I would avoid term funily
|
|
||
| ``` | ||
| ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ | ||
| 📈 Summary & Comparisons |
There was a problem hiding this comment.
Lets also below memtion benefit of smaller build. Faster cold-starts, less storage cost, faster bundling and distribution...
And I think faster builds too, but let's benchmark that first
There was a problem hiding this comment.
When benchamrking buiilds, let'ß benchmark both cached (with .next from previosu build), and uncached
|
|
||
| ``` | ||
| ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ | ||
| 📈 Summary & Comparisons |
There was a problem hiding this comment.
When benchamrking buiilds, let'ß benchmark both cached (with .next from previosu build), and uncached
Summary by CodeRabbit