如果是服务端主动推送的场景的话，可以考虑一下使用消息中间件 NATS: https://nats.io/

NATS 内置了楼上提到的负载均衡、广播等功能。
NATS 能够通过 SDK 与前端、客户端直接连接。
NATS 能够很方便地实现水平扩展，NATS 能够与你的用户权限体系集成。

https://docs.nats.io/running-a-nats-service/configuration/websocket/websocket_conf

npm pack 一下会得到一份模块压缩包。把这个压缩包扔到 oss 上，或者再开一个仓库专门用来存模块包，或者直接把模块扔 a,b 项目仓库里。

从 url 安装模块：npm install https://github.com/indexzero/forever/tarball/v0.5.6
从 本地安装模块: npm install ./package.tgz

参考：
https://docs.npmjs.com/cli/v10/commands/npm-pack
https://docs.npmjs.com/cli/v10/commands/npm-install
https://pnpm.io/zh/cli/pack
https://pnpm.io/zh/cli/install
https://yarnpkg.com/cli/pack
https://yarnpkg.com/cli/add

恭喜你找到了 React.createElement ，再省略一下每句必带的父组件名，换成 xml 带嵌套写法，恭喜你找到了 jsx

Angular 使工程化的思想深入人心；
React 使组件化的思想深入人心；
Vue 使响应式的思想深入人心；

这个 nuejs 啥也不是，纯纯的自嗨项目，没有解决任何切实问题，把三大框架已经做好的事情再干一遍。

hot-reloading 这种基础功能拿来当卖点、default unbundled 明显开倒车、2024 年了 TypeSCript Declaretions 也没有、组件模板语法和 Vue 如出一辙那么喜欢 Vue 直接用 Vue 不好吗？

我认为应该根据 key 对 users 做去重。

假如有一个最新用户列表和一个 [加载更多用户] 按钮，页面不按页码分页，每次点击按钮时直接把下一页数据塞进当前列表里。

假如在第一次数据加载后过了一段时间再去点击 [加载更多用户] ，在这一段时间内可能会新的用户，此时用户列表内的 key 就会碰撞。

举例来说，假如每页取 3 项：
第一次加载第一页用户为: [张三, 张四, 张五]；
新用户张一、张二注册，此时数据库中最新的 6 个用户为: [张一, 张二, 张三, 张四, 张五,张六]；
第二次加载第二页用户为: [张四, 张五, 张六]，此时前端用户列表为 [张三, 张四, 张五, 张四, 张五,张六] ，其中 张四, 张五 为重复数据；

既然无法避免重复，那就对列表做去重处理。

```tsx
const fetchUsers = useCallback(async () => {
const page = pageData // 异步获取到数据
setUsers((prevUsers) => {
const newUsers = page.filter(
(user) => !prevUsers.find((u) => u.id === user.id)
)
return [...prevUsers, ...newUsers]
})
}, [])
```

我来给泼个冷水
2024 年了居然还没有 TypeScript Declaretions
你可以不用 TypeScript 但不能没有 Declaretions

「综合水平一直是 flutter 最高」这个结论是怎么得出来的？

在我看来 Flutter 自认为的优势也是最大的缺点就是自绘。目前甚至很长的一段时间内自绘的性能/用户体验是比不过原生的。
假如原生的体验是 100 分，那么目前 Flutter 的上限大概只有 90 分，希望 Impeller 完善之后能把上限提高些。反观 React Native 始终使用原生渲染，在 0.68 使用全新的 Fabric 架构解决了 js 通讯瓶颈后，在性能上已经不成问题了，上限可以达到原生的 100 分。

体验一下 V2EX 的 Flutter 客户端和 React Native 客户端，Flutter 版本滑动、翻页的时候存在明显卡顿，RN 的体验明显好得多。
https://github.com/guozhigq/flutter_v2ex
https://github.com/liaoliao666/v2ex

你可能需要低代码框架：不生成代码，直接启动数据库的 crud 的 GraphQL 接口，后端几乎不用写代码，让前端直接调用 GraphQL 接口。

https://github.com/graphile/crystal
https://github.com/SeaQL/seaography
https://github.com/nocodb/nocodb
https://github.com/nhost/nhost

NextUI：漂亮，精准，自定义程度高，细节拉满

https://nextui.org/

你要学的是后端，而不仅仅是 nest.js 。

后端需要掌握的知识点有：数据库(MySQL 、PostgreSQL)、缓存(Redis)、消息队列、高并发、分布式、高可用、微服务等等等。
相比起来，用什么语言的什么框架是相对次要的。

数据库、Redis 、消息队列这些你可以很轻易搜到大把教程，我的建议是直接看官方文档。
https://www.postgresql.org/docs/
https://redis.io/docs/about/

至于分布式、高可用、微服务这些理论的东西。我最开始是直接找 Java 的教程看的，主要是学习一个思想，不是非得按教程来，Java 生态里的工具在 Node.js 里可能有另外的替代。很多 Java 教程涵盖了非常全面的知识点：
https://github.com/Snailclimb/JavaGuide
https://github.com/doocs/advanced-java
https://github.com/Jstarfish/JavaKeeper

还有 nest.js 的文档写的也算比较完善的，对新手也很友好，本身也是 Node.js 生态里的东西。

据我观察，大部分 Java 和 Go 开发者对 ORM 无感甚至讨厌 ORM ；而大部分 C#、Node.js 、Ruby 开发者喜欢用 ORM 。
原因其实很简单，C# 的 EF Core 、Node.js 的 Prisma, MikroOrm 、Ruby 的 ActiveRecord 很好用。

一款好的 ORM 应该尽可能提供该语言原生的写法，提供完善的类型安全、提供灵活的 Query Builder 以应对尽量多的 SQL 语法。

Java/Go 生态内缺少用起来顺手的 ORM 。要是 Java 有 EF Core 、Go 有 Prisma ，我相信所有人都会喜欢 ORM 。

后端太菜了，跟领导反应给后端上一些强制性的规范，比如让后端接入 OpenAPI 、或者使用 tRPC 、GraphqL 、gRPC 等强类型 API 来实现接口。

好奇什么样的人用什么样的语言能把布尔值写成 0/1, "on"/"off", 1/0, 1/2 ，直接布尔值不就完事儿了，整这么多损人不利己...

来点新花样： https://lapce.dev/

@theprimone #2
状态管理主要解决的问题有：
1. 跨组件状态传递
2. 组织 actionsa ，比如 createBook 、updateBook

zustand 强制在 create store 的时候组织 actions： https://docs.pmnd.rs/zustand/guides/updating-state

valtio 很自由，可以用你最熟悉的 js 语法组织 actions： https://valtio.pmnd.rs/docs/how-tos/how-to-organize-actions

Jotai 完全遵守 React Hooks 规则，本身没有组织 actions 的办法。需要使用 React 闭包 + useCallback 来封装 actions ，或者使用 Reducer 。
比如上面的 BookController 按 Jotai 的写法就会变成：
```ts
import { atom } from 'jotai'

const booksAtom = atom<Record<string, Book>>()

function useBooks() {
const [books, setBooks] = useAtom(booksAtom)

const getBooks = useCallback(async () => {
const books = await fetchBooks()
setBooks((prevBooks) => {
const nextBooks = { ...prevBooks }
books.forEach((book) => {
nextBooks[book.id] = book
})
return nextBooks
})
}, [setBooks])

const createBook = useCallback(
async (book: Book) => {
const newBook = await fetch('createBook', { method: 'POST', body: book })
setBooks((prevBooks) => ({ ...prevBooks, [newBook.id]: newBook }))
},
[setBooks]
)

const updateBook = useCallback(
async (id: string, book: Book) => {
// ...
},
[setBooks]
)

return { books, getBooks, createBook, updateBook }
}
```

因为我讨厌 useCallback 以及 Reducer ，所以不推荐 Jotai 。

vs code 能无痛远程开发，本地连环境都不用装，Goland 不能

你可能需要使用 zustand 或者 valtio 等状态管理库。

我个人是喜欢用 class 封装成 controller 的，然后在组件内使用 valtio 的 proxy 和 useSnapshot 来使用。

```ts
class BookController {
books: Record<string, Book> = {}

async getBooks() {
const books = await fetchBooks()
books.forEach((book) => {
this.books[book.id] = book
})
}

async createBook(book: Book) {
// ...
}
async updateBook(id: string, book: Book) {
// ...
}
}
```

在组件内使用：

```tsx
import { proxy, useSnapshot } from 'valtio'

const YourComponent = () => {
const controller = useMemo(() => proxy(new BookController()), [])
const { books } = useSnapshot(controller)

useEffect(() => {
controller.getBooks()
}, [controller])

const allBooks = Object.values(books)
const oneBook = books['bookId']

return (
<div>
{allBooks.map((book) => (
<div key={book.id}>{book.name}</div>
))}
<button onClick={() => controller.createBook(yourBook)}>创建</button>
</div>
)
}
```

valtio: https://github.com/pmndrs/valtio
zustand: https://github.com/pmndrs/zustand

Flutter 是个知名度很大但实际上并不怎么流行的框架。
我用 LibChecker 检查我手机上的 APP 有很多使用了 Flutter 的 SDK 。但实际上全面使用 Flutter 的只有《哔哩哔哩漫画》，有些 APP 部分页面使用 Flutter：《咸鱼》《飞猪》，更多是使用了 Flutter 的 SDK 但我找不到哪个页面是用 Flutter 写的：《微信》《微博》《豆瓣》《优酷》。
Flutter 视图是完全自绘的，交互体验上和 native 有很多不同，因此可以很容易判断哪个页面是不是用 Flutter 渲染的。比如在 Flutter 页面上双指滚动就能双倍滚动。

Flutter 成也自绘败也自绘。自绘的好处是可以在所有平台上获得一致的视图。坏处则是比不过原生的动画流畅性和交互体验，这方面有太多的 issues 了：动画反馈会延迟 1~3 帧，无法使用 Android 12 的滚动回弹动画，滑动和翻页时有明显的掉帧，严重的着色器编译时卡顿( https://docs.flutter.dev/perf/shader ) 。

总的来说 Flutter 开发的页面用户体验相比原生是明显倒退的，这可能也是为什么大厂不全面使用 Flutter 的原因。希望 Impeller 引擎完善之后能改进性能问题。

说到 Flutter 就不得不提老对手 React Native 。
RN 这两年在性能上做了诸多努力：0.68 支持 Fabric 渲染器架构，使用 jsi 与原生进程通讯，使得 js 与原生进程的通讯不再成为性能瓶颈； 0.70 使用 Hermes 作为默认 js 引擎，性能提升 51% - 63% ( https://reactnative.dev/blog/2022/07/08/hermes-as-the-default ) 。
另外 React Native 始终使用原生渲染，没有上面说的 Flutter 的一大堆问题。
假如原生的用户体验是 100 分，那么 RN 的上限就是 100 分，Skia 引擎的 Flutter 的上限是 90 分，希望 Impeller 引擎的 Flutter 的上限能达到 95 分以上。

再说 Dart 语言：我觉得本身 Dart 是门很不错的语言，奈何它的对手太强了，compose 的 kotlin 、RN 的 ts + jsx 、MAUI 的 C#。在一众优秀语言里 Dart 反而是平庸的。
Flutter 的状态管理方案也很难评，Flutter 生态里没有可以媲美 vue3 、或者 React 的 zustand 、jotai 、valtio 的状态管理库。Riverpod 略显啰嗦，GetX 相当于买了个冰箱送了个油烟机。

在现下总的来看：MAUI 和 Compose Multiplatform 还 too young ，担心踩坑没人管，那么还是得看 React Native 和 Flutter 。RN 在性能上不输 Flutter ；语言层面 TypeScript + jsx 优于 Dart ；生态上 npm 比 dart 繁荣得多，微软、Shopify 、京东、美团、Discord 、小米 都在大规模使用 React Native 。
结论是推荐 React Native 。

借楼吐槽一下 gRPC ，用着是真的麻烦：
1. 每次新加函数都要编写 .proto 文件，再重新代码生成；
2. protobuf 语法也很繁琐，在语言里序列号反序列化也麻烦；
3. 没有内置的负载均衡方案，需要另外实现或者网络配置；

马上 2024 年了，推荐使用 NATS 作为远程调用的方案：
✅使用 json ，简单高效
✅云原生、轻松水平扩展、高性能，服务与 NATS 之间始终保持连接，省去了反复建立 TCP 连接的开销
✅内置负载均衡、服务发现
✅可选的消息队列、键值存储

https://nats.io/
https://github.com/nats-io/nats.go/blob/main/micro/README.md

Protocol Buffers 是强类型的，能让通讯双方明确数据结构和类型，proto 文件本身具有文档的功能。
json 只是单纯的无类型数据，按 message Person { string params = 1; } 这么写过两个礼拜你自己都不知道 params 里有什么。