Rspack 真的很香。
之前 nodejs 服务打包都是用的 Webpack ，但是 Webpack 编译太慢，开发时不得不用 ts-node 、tsx 这类即时运行的工具跑 nodejs 应用。生产时为了减少应用体积，会对项目进行 Webpack 打包，将项目编译成单个 js 文件，然而这导致项目部署时经常报依赖错误🥲。
换了 Rspack 之后，得益于 Rspack 飞快的编译速度，开发时能够直接 "rspack build --watch && node --watch dist/index.js"运行编译产物，开发和生产环境的终于能够保持一致。
也试了 esbuild 、swc 、vite ，但是都对 node.js 的编译打包支持不太好，难以正确处理所有依赖(尤其是 .node 文件)。

你说的对，在 2023 年 useReducer 和 Redux 可以说是最落后的状态管理方案了。

现在有好的多的状态管理解决方案：
喜欢 Redux 这种单向数据流思维的可以用： https://github.com/pmndrs/zustand
喜欢 React Hook 函数式思维的可以用： https://github.com/pmndrs/jotai
喜欢 vue3 reactive 的可以用： https://github.com/pmndrs/valtio

早期 React 状态管理大家都是摸着石头过河，难免会走出 useReducer 和 Redux 的弯路。

我理解 build 是把源代码编译成可直接运行的代码，比如把 ts 编译成 js ，把 ESNext 编译成 ES5 ，把 js 编译成字节码。
常用的工具有：
https://github.com/microsoft/TypeScript
https://github.com/babel/babel
https://github.com/swc-project/swc
https://github.com/bytenode/bytenode

打包(bundle | pack)根据不同的项目类型有不同的操作。

对于通用模块项目(npm package)，打包需要将源代码编译成 esm 模块以及 cjs 模块，有时还需要输出 .d.ts 类型声明文件。
常用的工具有：
https://github.com/rollup/rollup
https://github.com/evanw/esbuild
https://github.com/unjs/unbuild
https://github.com/egoist/tsup
https://github.com/developit/microbundle

对于应用项目(app)，打包需要将源代码以及依赖资源(cs, json, 图片, 甚至 node 本身) 构建成静态文件或者可执行文件，目的是减少 app 体积、方便部署。
常用的工具有：
https://github.com/evanw/esbuild
https://github.com/vitejs/vite
https://github.com/webpack/webpack
https://github.com/web-infra-dev/rspack
https://github.com/nexe/nexe
https://github.com/vercel/pkg

@fordoo #18

jwt 的出现就是为了无状态、不访问 db 。既然业务需求不能无状态，不如直接把 jwt 的签名、验证这一套省略了。用最简单的最直观的 session 模式。

vs code 设置里搜索：Http: Proxy
填上: https://127.0.0.1:7890

参考： https://v2ex.com/t/844018

https://nextui.org/

这才是面向 C 端的组件库，细节丰富，动画效果十分丝滑。
另外还天然集成 tailwind ，能够完全自定义。

让设计师把图扔到 Figma 或者蓝湖 或者 MasterGO 或者即时设计 上，前端根据需要自主选择导出的格式和尺寸

要出活快的话，Nuxt.js + tRPC 全栈。
直接不分前后端，能省不少麻烦。

不管是可读性、维护成本、性能、SEO ，Remix 都完胜 Server Component：
https://remix.run/blog/react-server-components

个人完全不能理解 Server Component 有什么用。
原本大部分 SSR 的前端应用是为了支持 SEO ，结果 Server Component 都不支持 SEO ，那要 Server Component 有什么用？

另外就是 Server Component 强行整了两套不同的规则和写法。
隔壁 Nuxt.js( https://nuxt.com/docs/getting-started/data-fetching#usefetch ) 整的多好：直接在组件内 await fetch 。

MongoDB 有什么不好，为什么不全放 MongoDB ？还望不吝赐教.

@ksmiloLove 2023 可以试试 tRPC( https://trpc.io/ )，比 GraphQL 要省事儿的多，代价则是牺牲了灵活性。

对于 Nest.js 应用来说，可以使用 [Code first] 的开发模式，只需增加少量代码即可切换到 GraphQL 。
Nest.js 内置了对 GraphQL 的一流支持，开箱即用： https://docs.nestjs.com/graphql/quick-start
配合 CodeGen( https://the-guild.dev/graphql/codegen )，客户端强类型 API 拿来就用。
用过 GraphQL 再也不会想回到 REST： https://www.apollographql.com/blog/graphql/basics/graphql-vs-rest/

都用 nestjs 了，直接 上 GraphQL 岂不美哉。GraphQL 出参不仅能过滤字段，还附赠强类型 API 文档，配合 CodeGen 客户端类型也省的写了。

你是不是再找 Strapi： https://strapi.io/
不过是 Node.js 的框架，类似的低代码框架还有：
NocoDB： https://www.nocodb.com/
Graphile: https://www.graphile.org/

用过 nuxt3 和 remix ，这两个之间推荐 nuxt3 。

你真的需要 nestjs 吗？
nextjs 本身已经是一个后端了，无需搭配另外的后端库(nest 、koa 、express 、fastify)。
比较新的开源项目 civitai 就是整个 nextjs +prisma ，不用其他后端库 https://github.com/civitai/civitai

如果数据规模不大，查询结果的行数在几千行以内，通常不需要特别优化，直接 count(1) 不会有大的性能问题。

如果数据规模较大，查询结果行数在几十万行规模以上级别，这时候翻页都是麻烦事儿。一般会在数据库内另外记一个值来存手动 count ，每次新增行 count + 1 ，每次删除行 count - 1 ，通过事务来确保与实际行数一致。
比如知乎的粉丝列表页面： https://www.zhihu.com/people/gong-qing-tuan-zhong-yang-67/followers?page=2333
翻页翻到后面直接不展示数据了，因为此时数据库需要 skip 上万行才能查询到结果，开销太大了。

另外一个很实用的办法是把分页换成加载 [加载更多]，这样就不用 count 了，用户也更难 skip 上万行。