feat(blog): 更新博客文章，分享全栈开发者的技术选型反思与经验
This commit is contained in:
joyzhao
@@ -1,78 +1,76 @@
|
|||||||
---
|
# All This Tinkering... For What? Engineering Reflections from a Full-Stack Developer
|
||||||
layout: "@/layouts/BlogPostLayout.astro"
|
|
||||||
title: "Stop Being Held Hostage by 'Best Practices': Confessions of a Full-Stack Developer's Tech Stack Struggles"
|
|
||||||
description: "A full-stack developer's honest reflection on getting trapped by chasing 'best practices' while building a simple 30-endpoint project. This article explores the cognitive load of heavy frameworks, the Monorepo trap, and proposes a practical two-tier tech stack selection strategy."
|
|
||||||
date: "2026-01-08"
|
|
||||||
image: "https://images.unsplash.com/photo-1518770660439-4636190af475?q=80&w=1470&auto=format&fit=crop"
|
|
||||||
tags: ["Tech Stack", "Full-Stack Development", "Framework Selection", "Best Practices", "Developer Experience"]
|
|
||||||
tagId: ["tech-stack", "fullstack", "framework", "best-practices", "developer-experience"]
|
|
||||||
category: "Technology"
|
|
||||||
categoryId: "technology"
|
|
||||||
readTime: "6 min read"
|
|
||||||
---
|
|
||||||
|
|
||||||
> **Foreword:**
|
> *A log of the soul-crushing details I encountered during a recent project setup. This is a summary of my own internal tug-of-war—lessons learned the hard way through endless trial and error. It might not be the "correct" way, but every word was paid for in lost time.*
|
||||||
> I am a developer who transitioned from Frontend to Node.js Full-Stack. This article is simply a summary of my recent experiences and reflections while developing a project. Given my limited knowledge and perspective, the views expressed here may not be universally "correct" or represent industry standards. This is just a personal debrief after stepping into countless pitfalls, shared in the hope of exchanging ideas with the community and providing a reference for those facing similar dilemmas. If there are any inaccuracies, please feel free to correct me in the comments.
|
|
||||||
|
|
||||||
Recently, I set out to build a small bookmark-style tool with only about 30 endpoints. I thought it would take two weeks; instead, I spent over a month just "wrestling" with the tech stack.
|
I recently set out to build a simple bookmarking tool. It only needed about 30 endpoints, yet I spent nearly a month agonizing over the tech stack. I felt like I was wandering through a dark forest, sprinting toward every glimmer of light only to find a new pitfall waiting for me.
|
||||||
|
|
||||||
I felt like a hunter lost in a technical fog: wherever I saw a light (a new tool or an "expert" opinion), I rushed toward it, only to find a deeper pit hidden behind every glow.
|
### Step 1: Chasing the "Mainstream" and Feeling the Friction
|
||||||
|
|
||||||
## 1. Chasing Trends is the Start of Internal Friction
|
It started because I wanted to build a side project. In my day job, I use Vue; it’s second nature to me. But everywhere I looked online, the consensus was: **"Next.js + React + shadcn-ui"** is the gold standard. Great ecosystem, endless components, future-proof.
|
||||||
|
|
||||||
I started by following the crowd and chose **Next.js + NestJS + shadcn-ui**. I thought, "Since everyone says this is the 'Full-Stack Gold Standard,' I can't go wrong." The reality, however, gave me a swift wake-up call.
|
I told myself: *Don’t get stuck in your comfort zone. Try something new.* So, I benched Vue and picked up React. I was immediately hit by **choice paralysis.**
|
||||||
|
|
||||||
In Next.js, I wasted a whole week just deciding on a data-fetching and state management solution (SWR vs. Zustand?). Once I finally started, I was overwhelmed by the complexity of Server Components (RSC) vs. Client Components—constantly defining `"use client"`, fixing mysterious Hydration errors, and manually managing state dependencies while optimizing endless callback functions.
|
It wasn't just a choice between A and B; it was a choice between five different ways to do everything. I spent more time reading docs and comparisons than writing logic:
|
||||||
|
|
||||||
I kept thinking: **I just want to write some simple business logic. Why am I spending 80% of my energy dealing with the overhead of the framework?**
|
* Do I fetch data with **SWR** or **TanStack Query**?
|
||||||
|
* Is global state better in **Zustand**, **Redux**, or **Jotai**?
|
||||||
|
* How do I bridge the gap between server and client data?
|
||||||
|
|
||||||
## 2. The Heavier the Framework, the Heavier the Cognitive Load
|
Instead of building features, I was researching "how to build." To make matters worse, I kept hitting those cryptic **"Hydration Errors."** One refresh, one error, and an hour gone trying to find the mismatch.
|
||||||
|
|
||||||
Later, I switched the frontend to Nuxt, which was indeed smoother. But on the backend, I stuck with **NestJS**, chasing so-called "standardization" and "enterprise engineering."
|
The most draining part was tagging everything with `"use client"`. I felt less like a developer and more like a clerk labeling boxes. I kept thinking: **"If most of this ends up running on the client anyway, why am I using a framework that splits the stack so aggressively and demands such high mental overhead?"**
|
||||||
|
|
||||||
But I only had 30 endpoints. The logic was incredibly simple. In NestJS, I was forced to write Controllers, Services, Modules, DTOs... the amount of code tripled. Even worse was the **ESM compatibility issue**. NestJS still clings to the CommonJS dream, leading to constant configuration errors when I tried to use modern ESM-only libraries. To run a simple TypeScript Worker thread, I had to spend hours researching ESM compilers.
|
### Step 2: Retreating to Comfort—and the Fear of Missing Out
|
||||||
|
|
||||||
The most frustrating part was **Swagger integration**. Most people prefer Zod for validation now, but Swagger is deeply coupled with the Class-Validator (Decorator) pattern. To get Swagger to recognize my Zod schemas and generate documentation, I had to manually write adapters and custom decorators.
|
I went back to my familiar Vue ecosystem and fired up Nuxt. Suddenly, I could breathe. My productivity skyrocketed.
|
||||||
|
|
||||||
**I felt like I wasn't building a product; I was repairing a broken tractor with incompatible parts.**
|
But the peace didn't last. I’d see another post praising the Next.js ecosystem and start doubting myself: **"Am I choosing the wrong path? Am I falling behind?"** I gave Next.js another shot for a few days, and like clockwork, all those petty, nagging frustrations returned.
|
||||||
|
|
||||||
## 3. Monorepo: The "Tender Trap" for Indie Developers
|
That’s when I realized: **Tech isn't about "better" or "worse"; it’s about fit.** Trust your "handfeel." That sense of flow (or lack thereof) doesn't lie.
|
||||||
|
|
||||||
To pursue "code reuse," I even set up a **Monorepo**.
|
### Step 3: The "Professionalism" Trap
|
||||||
|
|
||||||
I thought: *Front-end and back-end sharing types, enums, and error codes—how elegant!* The reality: trying to get a pure ESM frontend to share a package with a non-pure ESM backend plunged me into a bottomless pit of build configurations. Due to the NestJS environment, I had to compile and export the shared package every time I made a change, making frequent debugging and code modification an absolute nightmare.
|
Once the frontend was settled, I moved to the backend. I chose **NestJS** because it’s billed as the most "Enterprise-grade" option. To make it even more "professional," I forced it into a **Monorepo**. I effectively built myself a prison:
|
||||||
|
|
||||||
Code that should have taken one minute to write took ten because I was busy dealing with cross-package debugging, TS type synchronization, and build logic.
|
* **Immense Friction:** Changing a single shared enum or type meant re-building, waiting for workspace syncs, and restarting services. A 10-second change turned into a 1-minute wait.
|
||||||
|
* **Compatibility Hell:** NestJS is still clinging to CommonJS. Trying to use a pure ESM library or running a TS Worker thread resulted in config errors that made me question my career choices.
|
||||||
|
* **Ceremony Over Substance:** For 30 endpoints, I was writing endless Controllers, Services, Modules, and DTOs. The lines of code tripled, but the core logic stayed exactly the same.
|
||||||
|
* **The Swagger Tax:** I wanted to use Zod for validation, but Swagger only recognizes decorators (class-validator). I ended up maintaining two nearly identical data definitions just to have an API doc.
|
||||||
|
|
||||||
**I finally realized: Monorepos are built to solve "organizational collaboration." For an indie developer, they are often a productivity killer.**
|
**I traded my immediate efficiency for the "advantages of a large team" that I don't actually have.** I wanted speed; the framework demanded "maintainability" for a scale I'll likely never hit.
|
||||||
|
|
||||||
## 4. Returning to Pragmatism: My "Two-Tier Strategy"
|
### Step 4: Stripping it Down and Losing My Way
|
||||||
|
|
||||||
At the end of all this exhaustion, I reflected: Is there a perfect framework? The answer is no; there is only the *suitable* one. Consequently, I have simplified my selection logic into two tiers:
|
I ditched the heavy frameworks for **Fastify**, thinking I’d keep it lean. But I quickly discovered that the problem wasn't just "weight"—it was **"the anxiety of absolute freedom."**
|
||||||
|
|
||||||
* **Tier A: Rapid Validation (MVP / Personal Projects)**
|
Fastify is liberating, but for someone used to structure, freedom is a burden:
|
||||||
**Stack: Nuxt All-in-One.** Don't even separate the frontend and backend. Nuxt's built-in Server API (Nitro) is more than enough for small to medium businesses. Types are naturally shared, and there are no CORS or build-sync headaches. At the validation stage, **"Speed" is a hundred times more important than "Elegance."**
|
|
||||||
|
|
||||||
* **Tier B: Complex Business (Large Projects / Team Collaboration)**
|
* "Where should this file go?"
|
||||||
**Stack: Nuxt + NestJS (Decoupled) + Monorepo.** Only when the business is complex enough to require strict layering, Dependency Injection (DI) for decoupling, and multi-person collaboration will I endure the "ceremony" and management costs of these heavy frameworks.
|
* "How do I organize this into a plugin?"
|
||||||
|
* Logging, queues, auth—everything NestJS gave me for free now required me to find, integrate, and debug a third-party library.
|
||||||
|
|
||||||
|
I hated the rules of heavy frameworks, yet I craved their structure. My mindset was completely torn.
|
||||||
|
|
||||||
|
### The Epiphany: Tech is a Tool, Not a Totem
|
||||||
|
|
||||||
## 5. A Side Note: A New Hope in AdonisJS
|
One night, working late, I asked myself: **"Why am I doing this? I just wanted to build a simple tool."**
|
||||||
|
|
||||||
Just as I was summarizing these strategies, I stumbled upon a new framework—**AdonisJS**. Many developers describe it as the "Laravel of Node.js."
|
Everything clicked. I was applying "Long-term Enterprise Maintenance" standards to a "Solo Rapid Prototype." It was like trying to build an eight-lane highway just to go to the grocery store around the corner.
|
||||||
|
|
||||||
I took a quick look at its philosophy, and it seems to precisely hit the pain points I mentioned: it supports ESM natively, has a powerful built-in ORM and Auth solution, and doesn't require jumping through hoops with custom adapters just to get automated Swagger documentation.
|
I set a new, simple rule for myself:
|
||||||
|
|
||||||
This "Convention over Configuration" full-stack framework seems to balance development efficiency with engineering quality. I plan to use it in my next project and will share my findings once I have more experience.
|
1. **For Prototypes & Small Tools:** Use **Nuxt (or a monolithic framework) exclusively.** Frontend and backend in one repo, natural type synchronization, no CORS issues, no sync friction. The goal is to *ship*.
|
||||||
|
2. **For Complex Systems & Large Teams:** *Then* consider **Nuxt + NestJS + Monorepo.** The complexity is a fair trade for the architectural guardrails.
|
||||||
|
|
||||||
## 6. Conclusion: A Few Words of Advice
|
### A New Contender: AdonisJS
|
||||||
|
|
||||||
1. **There is no perfect framework, only the one that fits the moment.** Don't expect any "star" framework to solve all your problems; they all come with a cost.
|
During this spiral, I stumbled upon **AdonisJS**. It’s often called the "Laravel of Node.js." From a quick look, it seems to hit the sweet spot: it has the structure I crave (ORM and Auth built-in) but feels modern and supports ESM natively. I might give it a spin next time.
|
||||||
2. **Do not easily try a tech stack you aren't familiar with during indie development or tight deadlines.** Unless you truly have the time and energy to burn. You think you're learning new tech, but you're actually burning your product's lifespan.
|
|
||||||
3. **Be wary of "Big Tech Best Practices."** Many tools built to solve pain points in giant corporations (like Monorepos or extreme layering) only create pain points in personal projects.
|
|
||||||
4. **Familiarity > Modernity.** Even if a framework is called "old school," if it's intuitive to you, lets you finish work early, and helps you write clearer logic with AI assistance, it is your "silver bullet."
|
|
||||||
|
|
||||||
**The best tech stack is the one that allows you to forget the technology itself and focus on creating value.**
|
### Final Thoughts
|
||||||
|
|
||||||
Finally, the solutions I've summarized are only what fits my personal habits and current understanding; they may not work for everyone. Everyone's business scenarios and technical backgrounds are different. **If you have better ideas or different solutions, I'd love to hear them in the comments so I can learn from you too.** If I've missed anything, please let me know. Thanks in advance!
|
1. **Don’t blind-follow the hype:** What works for Vercel might not work for your weekend project.
|
||||||
|
2. **Trust your "handfeel":** If a tool makes you feel productive, that's worth more than any "State of JS" ranking.
|
||||||
|
3. **Ship first, optimize later:** For a solo project, an un-launched architecture is just expensive fan fiction.
|
||||||
|
4. **Watch out for "Config Friction":** If you spend more time in `.json` and `.config.js` files than in your logic, your tools are failing you.
|
||||||
|
|
||||||
|
This was my journey through the weeds. **My approach might be "wrong" or even a bit clumsy.** I’d love to hear how you handle the "stack anxiety." **Do you have a go-to setup that just works, or are you still searching for the "perfect" balance?**
|
||||||
@@ -1,76 +1,78 @@
|
|||||||
---
|
# 折腾来折腾去，到底是为了什么？ 一个全栈开发者的工程化反思
|
||||||
layout: "@/layouts/BlogPostLayout.astro"
|
|
||||||
title: "别再被\"最佳实践\"绑架了：一个全栈开发者的选型忏悔录"
|
|
||||||
description: "一名全栈开发者在开发 30 个接口的小项目时，过度追逐技术潮流而陷入困境的真实记录。本文探讨了重型框架的心智负担、Monorepo 的陷阱，并提出了一套务实的两套技术栈选型方案。"
|
|
||||||
date: "2026-01-08"
|
|
||||||
image: "https://images.unsplash.com/photo-1518770660439-4636190af475?q=80&w=1470&auto=format&fit=crop"
|
|
||||||
tags: ["技术栈选型", "全栈开发", "框架选择", "最佳实践", "开发者体验"]
|
|
||||||
tagId: ["tech-stack", "fullstack", "framework", "best-practices", "developer-experience"]
|
|
||||||
category: "技术分享"
|
|
||||||
categoryId: "technology"
|
|
||||||
readTime: "6 分钟阅读"
|
|
||||||
---
|
|
||||||
|
|
||||||
> **写在前面：**
|
> 记录一下最近做项目选型时，那些真能把人搞崩溃的细节。是我自己跟自己较劲，来回折腾后的一点总结。不一定对，但每句话都是花时间踩坑换来的。
|
||||||
> 本人是一名从前端转 Node.js 全栈的开发者。这篇文章只是基于我近期开发项目时的一些真实经历和感悟。由于个人知识储备和认知水平有限，文中的观点不一定正确，更不代表行业标准。这仅仅是我在踩了无数坑后的一点自我总结，发出来是希望能和大家交流，也给有类似纠结的朋友提供一个参考。如有谬误，欢迎评论区指正。
|
|
||||||
|
|
||||||
最近我为了做一个只有 30 个接口的书签类小工具，把自己折腾疯了。
|
最近想做个书签小工具，一共也就 30 来个接口，结果在“用什么技术”这个问题上，我纠结了快一个月。感觉就像在技术的林子里瞎转，看见哪儿有光就往哪儿跑，最后发现每个亮光后面都是个坑。
|
||||||
|
|
||||||
起初，我像个在技术丛林里乱撞的猎人：哪里有亮光（新工具/大牛言论），我就往哪冲。结果发现，每一个亮光后面都藏着一个更深的坑。
|
## 第一步：跟着“技术主流”走，结果浑身难受
|
||||||
|
|
||||||
## 1. 追逐流行，是内耗的开始
|
事情是这样的，我想自己做点小产品。工作上我一直用 Vue，很顺手。但网上看了一圈，大家都在说 **“Next.js + React + shadcn-ui”** 才是现在做东西的正道。生态好、组件多、未来可期。
|
||||||
|
|
||||||
我最开始随大流选了 **Next.js + NestJS + shadcn-ui**。我想着，既然大家都说这是"全栈天花板"，那选它准没错。结果现实反手就给了我一巴掌。
|
我一想，不能老用自己熟悉的，换个口味吧。于是放下 Vue，开始用 React。结果一上来就懵了：**选择太多了，不知道该用哪个。**
|
||||||
|
|
||||||
在 Next.js 里，为了选一个数据处理和状态管理方案（SWR 还是 Zustand？），我硬生生磨掉了一周。好不容易开工了，又被服务端渲染（SSR）带来的复杂度搞得头大——频繁定义 `"use client"` 指令、处理莫名其妙的"状态水合（Hydration）"报错、还要手动管理状态依赖并优化一堆回调函数。
|
根本不是简单的二选一，而是每个地方都有好几个选择，我大部分时间都在搜资料、看对比、做选择：
|
||||||
|
|
||||||
我当时就在想：**我只是想写个简单的业务逻辑，为什么要花 80% 的精力去处理框架带来的麻烦？**
|
* 数据请求是用 **SWR** 还是 **TanStack Query**？
|
||||||
|
* 全局状态是用 **Zustand** 还是继续用 **Redux**、**Jotai**？
|
||||||
|
* 服务端和客户端数据怎么同步？在这个边界上我反复拉扯。
|
||||||
|
|
||||||
## 2. 框架重一点，心智负担就大一点
|
感觉我的主要工作不是写代码，而是在研究“该用什么写代码”。更烦的是那些莫名其妙的 **“水合错误（Hydration Error）”**，写个页面一刷新就报错，然后就得花时间找哪里对不上。
|
||||||
|
|
||||||
后来前端切到了 Nuxt 确实顺手了些，但后端我依然守着 **NestJS**，追求所谓的"大而全"。
|
最心累的是到处都要加 `“use client”`。我感觉自己不是在写功能，是在给代码打标签。每加一行我就在想：**“如果这么多东西最终都要在客户端跑，那我为啥要选这个把前后端拆这么碎、心智负担这么重的框架？”**
|
||||||
|
|
||||||
但我一共才 30 个接口，业务逻辑极其简单。但在 NestJS 里，我不得不写 Controller、Service、Module、DTO……代码量翻了几倍。更崩溃的是 **ESM 的兼容问题**，NestJS 依然守着 CommonJS 的旧梦，导致我想用一些最新的 ESM 库时，各种配置文件报错。为了跑通一个简单的 TypeScript Worker 线程，我还得自己去研究 ESM 编译器。
|
## 第二步：用回顺手的，又怕自己落伍了
|
||||||
|
|
||||||
最心累的是 **Swagger 的集成**。现在大家都爱用 Zod 做验证，但 Swagger 深度绑定类装饰器模式（class-validator）。为了让 Swagger 识别 Zod Schema 并生成文档，我得自己手搓适配器和装饰器。
|
我回到熟悉的 Vue 生态，用了 Nuxt。果然舒服多了，开发效率起飞。
|
||||||
|
|
||||||
**我感觉自己不是在开发产品，我是在修一辆零件互不兼容的破拖拉机。**
|
但安静没两天，看网上还是到处在夸 Next.js 生态好。心里又开始想：**“我是不是选错了？会不会错过什么？”** 不信邪，又回头去试了几天 Next.js。结果，那些熟悉的、琐碎的麻烦全回来了。
|
||||||
|
|
||||||
## 3. Monorepo：独立开发者的"温柔陷阱"
|
这回我彻底认了：**技术没有绝对的好坏，只有合不合适。我相信自己用着舒服的感觉，这种“手感”骗不了人。**
|
||||||
|
|
||||||
为了追求代码复用，我还折腾了 **Monorepo**。
|
## 第三步：总想“搞得专业点”，结果给自己挖坑
|
||||||
|
|
||||||
我想着，前后端共享类型、枚举、错误码，多优雅！但现实是：为了让纯 ESM 的前端和非纯血 ESM 的后端共享一个包，我陷入了无穷无尽的编译配置中。由于 NestJS 的环境问题，我必须为共享包进行编译导出才能使用，导致频繁修改调试代码时异常麻烦。
|
前端定了，该写后端了。我选了大家说最工程化的 **NestJS**。为了显得更专业，又强行上了 **Monorepo**。这下彻底麻烦了，我亲手给自己搞了个大工程：
|
||||||
|
|
||||||
原本一分钟写完的代码，因为要处理跨包调试、TS 类型同步和打包逻辑，硬生生变成了十分钟。
|
* **开发摩擦力极大：** 在 Monorepo 里改个公共的枚举值或类型，要重新构建、等 Workspace 同步、重启服务。原本 10 秒钟的事，现在要等 1 分钟。
|
||||||
|
* **兼容性地狱：** NestJS 守着 CommonJS 的旧梦，我想用个纯 ESM 的库或者跑个 TypeScript Worker 线程，配置文件的报错能让你怀疑人生，得花大把时间研究编译器路径。
|
||||||
|
* **仪式感的内耗：** 就 30 个接口，要写一堆 Controller、Service、Module、DTO。代码量翻了几倍，但核心逻辑一点没变。
|
||||||
|
* **Swagger 的折磨：** 我想用 Zod 做验证，Swagger 却只认装饰器（class-validator）。为了那张 API 文档，我得被迫维护两份几乎一样的数据定义，手动同步两份 DTO 的痛苦只有写过的人才懂。
|
||||||
|
|
||||||
**我悟了：Monorepo 是为了解决"组织协作"的，对于独立开发者，它往往是效率杀手。**
|
**我用一个可能永远用不上的“大团队优势”，换来了眼前的“低效率”。** 我想要的是快点做出来，但重框架让我优先考虑怎么让代码“更好维护”，这完全本末倒置了。
|
||||||
|
|
||||||
## 4. 回归务实：我的"两套方案"
|
## 第四步：换个轻量的，反而更不会写了
|
||||||
|
|
||||||
在折腾的终点，我反思：有没有完美的框架？结论是没有，只有适合的。于是，我把我的选型逻辑简化成了两套：
|
我决定不用这些重框架了，选了 **Fastify**，想着以后不行还能换回去。但我发现，问题不只是“重”，而是 **“自由带来的恐慌”**。
|
||||||
|
|
||||||
* **方案 A：快速验证（MVP / 个人项目）**
|
Fastify 很自由，但对我这种习惯了某种结构的人来说，自由反而成了压力：
|
||||||
**技术栈：Nuxt 一把梭。** 别分前后端了，Nuxt 的内置 Server API（Nitro）足够处理中小业务。类型天然共享，没有跨域烦恼。在验证阶段，**"快"比"优雅"重要一百倍。**
|
|
||||||
|
|
||||||
* **方案 B：复杂业务（大型项目 / 团队协作）**
|
* “代码该放哪？”
|
||||||
**技术栈：Nuxt + NestJS 分离 + Monorepo。** 当业务复杂到需要严格的分层、需要依赖注入（DI）解耦、需要多人协作时，才去忍受这种"重"框架带来的仪式感和管理成本。
|
* “这个功能怎么组织成插件？”
|
||||||
|
* 日志、队列、鉴权这些在 NestJS 里现成的，现在都要自己找库、集成、调试。
|
||||||
|
|
||||||
## 5. 题外话：意外发现的新希望 AdonisJS
|
我嫌重框架规矩多，但真给自由了，我又不知道该怎么用了。我从复杂的流程里出来，又掉进了“什么都要自己找”的坑。
|
||||||
|
|
||||||
就在我总结完上述方案后，我最近无意间发现了一个新的框架——**AdonisJS**。它被很多开发者评价为 Node.js 界的 Laravel。
|
**我终于明白：我选的那些框架，都基于我自己的知识惯性。我嫌重框架规矩多，但内心又想要固定结构，这种心态本身就是撕裂的。**
|
||||||
|
|
||||||
我简单看了一下它的设计理念，感觉它似乎精准地击中了我上述遇到的很多痛点：它原生支持 ESM、内置了强大的 ORM 和 Auth 方案、不需要像 NestJS 那样去折腾各种复杂的适配器来搞定自动化的 Swagger 文档生成。
|
## 终于想明白：技术是拿来用的，不是拿来供着的
|
||||||
|
|
||||||
这种"约定优于配置"的全栈框架，似乎能平衡开发效率与工程质量。我准备在接下来的项目中实际试用一下，如果确实好用，有了心得后再专门写篇文章分享给大家。
|
又一个加班到很晚的深夜，我对着屏幕问自己：**我折腾这么久，到底图啥？不就是想快点做出这个小工具吗？**
|
||||||
|
|
||||||
## 6. 总结：给开发者的一点建议
|
一下子通透了。我之前一直在用“大团队长期维护”的标准，来要求我这个“个人快速项目”。这就像为了去隔壁超市买菜，非要先修一条八车道的高速公路。
|
||||||
|
|
||||||
1. **没有完美的框架，只有最适合当下的。** 不要指望任何一个明星框架能解决所有问题，它们都有代价。
|
我给自己定了个简单的规矩：
|
||||||
2. **不要在独立开发或工作中轻易尝试自己不熟悉的技术栈。** 除非你真的有大把的时间和精力去踩坑。你以为在学新技术，其实你是在浪费产品的寿命。
|
|
||||||
3. **警惕"大厂最佳实践"。** 很多在大公司里解决痛点的工具（如 Monorepo、过度分层），在个人项目里往往只会制造痛点。
|
|
||||||
4. **熟悉度大于先进性。** 哪怕一个框架被说成是"老古董"，只要你用得顺手、能让你早点下班，它就是你的银弹。
|
|
||||||
|
|
||||||
**最好的技术栈，是那个能让你忘记技术本身，而专注于创造价值的工具。**
|
* **做原型、小工具、简单应用**：直接用 **Nuxt 一把梭**。前后端在一个包里写，类型天然同步，没有跨域，没有同步内耗。目标就是快，能跑起来比什么都强。
|
||||||
|
* **复杂系统、多人协作、长期维护**：再考虑 **Nuxt + NestJS + Monorepo**。这时候复杂点能接受，因为确实需要架构支撑。
|
||||||
|
|
||||||
最后想说，我总结的这些方案也仅仅是适合我个人的开发习惯和目前的认知，并不一定适合所有人。每个人面对的业务场景和技术背景都不同，**大家如果有更好的方案或想法，非常欢迎在评论区讨论，让我也有机会学习一下。** 不对的地方也希望各位大佬多多指教，先行谢过！
|
## 顺便提一句：看到个新选择
|
||||||
|
|
||||||
|
折腾的时候注意到了 **AdonisJS**，有人说是 Node.js 里的 Laravel。简单看了看，它好像正好平衡了我的纠结：有我要的固定结构（ORM、Auth 都有），又是现代的风格，原生支持 ESM。下次可以试试。
|
||||||
|
|
||||||
|
## 最后说几句
|
||||||
|
|
||||||
|
1. **别盲目追技术热点**：适合别人的不一定适合你。
|
||||||
|
2. **相信自己用着顺手的感觉**：这比流行趋势重要得多。
|
||||||
|
3. **先做出来再优化**：对于个人项目，跑不起来的架构就是一堆废纸。
|
||||||
|
4. **警惕“配置内耗”**：如果配置时间比写代码还长，就该换工具了。
|
||||||
|
|
||||||
|
这些就是我折腾一圈的想法。**我的做法可能不对，甚至挺笨的。** 所以想听听你们怎么看。**你们有没有类似的问题？最后怎么解决的？** 欢迎在评论区聊聊，让我也学习一下。
|
||||||
@@ -1,76 +0,0 @@
|
|||||||
# 从追逐流行到回归工程：我技术选型的“降噪”思考
|
|
||||||
|
|
||||||
过去几年里，我尝试过很多 Node.js 框架和前端技术栈：**Express、Koa、Fastify、Hono.js**，以及前端的 **Next.js**。这些框架和工具都有各自的优点：轻量、灵活、性能好，社区里也有不少人推荐。然而，随着项目的深入，我逐渐发现了一个事实：**简单、快速实现、自己熟悉、生态完善、可扩展性好**，才是最重要的，而不是盲目追逐“最流行”或“性能最高”的框架。
|
|
||||||
|
|
||||||
## 为什么不是 Next.js？
|
|
||||||
|
|
||||||
我也写过 React 和 Next.js，但总感觉生态太杂。尤其是 **状态管理**，从 Redux、MobX 到 Zustand、Jotai，再到 React Query、TanStack Query，每一种都有各自的优缺点，但选择过多反而让我心智负担加重。很多问题并不是没有解决方案，而是解决方案太多、没有统一的“最佳实践”。
|
|
||||||
|
|
||||||
相比之下，**NuxtJS 在 Vue 生态下要更工程化**。比如：
|
|
||||||
|
|
||||||
* 内置路由、布局、服务端渲染等功能，不需要额外选型。
|
|
||||||
* Vue 的响应式和 Pinia 状态管理简单好用，不需要反复对比。
|
|
||||||
* 配合 Nuxt UI、TailwindCSS，可以快速构建出一致的前端体验。
|
|
||||||
|
|
||||||
对我来说，NuxtJS 的“约定优于配置”正好能让我聚焦在业务上，而不是被生态碎片化牵扯精力。
|
|
||||||
|
|
||||||
## 为什么选择 NestJS？
|
|
||||||
|
|
||||||
很多人说 **NestJS 太重**，但我的实际体验是：**它恰到好处**。
|
|
||||||
|
|
||||||
* NestJS 自带 CLI，可以快速生成模块、控制器、服务，大大提升开发效率。
|
|
||||||
* 内置依赖注入、装饰器模式，让代码组织更清晰、可维护。
|
|
||||||
* 和 TypeScript 深度结合，不仅提高了开发体验，也减少了运行时错误。
|
|
||||||
* 对数据库、认证、缓存、消息队列等都有完善的解决方案，遇到问题时社区文档和生态资源都很丰富。
|
|
||||||
|
|
||||||
更重要的是，在 **AI 辅助开发** 的今天，像 NestJS 和 NuxtJS 这种约定清晰、工程化程度高的框架，更容易被 AI 理解和提供正确的解决方案。相比一些过于灵活的轻量框架，AI 在这类框架上的“知识盲区”更少。
|
|
||||||
|
|
||||||
## 两套技术方案
|
|
||||||
|
|
||||||
结合我的经验和实际需求，我总结出了两套适合的技术栈：
|
|
||||||
|
|
||||||
### 1. 轻量级方案（业务简单）
|
|
||||||
|
|
||||||
* **NuxtJS**
|
|
||||||
* **Drizzle ORM**
|
|
||||||
* **Nuxt UI**
|
|
||||||
* **TailwindCSS**
|
|
||||||
|
|
||||||
适合快速原型、简单应用、验证市场。
|
|
||||||
|
|
||||||
### 2. 完整方案（业务复杂）
|
|
||||||
|
|
||||||
* **NestJS**
|
|
||||||
* **NuxtJS**
|
|
||||||
* **Zod**
|
|
||||||
* **Drizzle ORM**
|
|
||||||
* **Redis**
|
|
||||||
* **Postgres**
|
|
||||||
* **Nuxt UI**
|
|
||||||
* **TailwindCSS**
|
|
||||||
|
|
||||||
适合需要后端独立、扩展性强的项目，可以通过微服务、缓存、消息队列等方式支撑更复杂的业务。
|
|
||||||
|
|
||||||
## 性能并不是唯一的答案
|
|
||||||
|
|
||||||
很多人推崇 **Hono.js**、**Elysia.js** 等轻量框架，说它们“简单、快、性能好”。确实，在 Hello World 或简单 API 的场景下，它们的性能数据很漂亮。但在真实的生产环境里，**性能瓶颈往往不在框架**，而在：
|
|
||||||
|
|
||||||
* 数据库查询优化
|
|
||||||
* 缓存策略
|
|
||||||
* 多实例部署
|
|
||||||
* 微服务架构
|
|
||||||
* 负载均衡与扩展能力
|
|
||||||
|
|
||||||
这时候，单一框架的“性能优势”几乎可以忽略。真正决定系统表现的，是整体架构设计和资源利用。
|
|
||||||
|
|
||||||
## 结论
|
|
||||||
|
|
||||||
我的体会是：**技术选型没有绝对的好坏，关键在于适合自己和项目需求**。
|
|
||||||
对我来说，NestJS + NuxtJS 这套组合：
|
|
||||||
|
|
||||||
* 工程化、生态完善，能快速实现功能。
|
|
||||||
* 熟悉度高，减少了心智负担。
|
|
||||||
* 易于扩展，能应对简单和复杂的业务场景。
|
|
||||||
* 在 AI 辅助的今天，更容易获得准确支持。
|
|
||||||
|
|
||||||
因此，哪怕有人说它们“重”或“不如某某框架”，我依然会坚持：**适合自己的，才是最好的技术栈**。
|
|
||||||
Reference in New Issue
Block a user