accessToken 、refreshToken 双 Token 只在分布式|微服务架构下有意义。

考虑我们有用户微服务和订单微服务，我们把用户信息存储在用户微服务，向订单微服务发起请求时需要验证用户有效性：
1. 如果使用单 token 方案，订单微服务接到请求时 需要向用户微服务发起询问来验证用户有效性，在这一步至少需要一次网络通信。
2. 如果使用双 token 方案，向用户微服务发起请求时携带 refreshToken ，向订单微服务发起请求时携带 accessToken ，accessToken 过期时向用户微服务发起请求重写签发 accessToken 。
accessToken 具有以下特性：
· 明文：这允许订单微服务直接从 accessToken 读取用户信息而不必询问用户微服务；
· 具备签名：这允许订单微服务直接验证 accessToken 的有效性而不必询问用户微服务；
· 不可篡改：这使得 accessToken 一经用户微服务签发则在有效期内一直有效，当用户更改密码或其他需要重制登录状态的时候 accessToken 也不受影响，为了满足重制登录状态的需求 accessToken 的有效期一般比较短。
总结一下，双 token 方案使得订单微服务微服务不用向用户微服务发起询问，代价是 accessToken 不可篡改、登录状态难以清除。

回答楼主的问题：
1. refreshToken 只能向用户微服务发起请求，订单微服务无法验证 refreshToken 的有效性；

2. 是的；

3. accessToken 不可篡改，不可延时；

个人看法：双 token 方案带来的「无需向认证服务询问」的特性有一点点优势；但很多场景会有下「踢出用户」的需求，这时候使用双 token 要么等着 accessToken 过期，要么向认证服务发起询问，前者实时性低，后者让损失了 双 token 方案唯一的优势。我的建议是摒弃双 token 方案，使用单 token 存 redis ，认证服务和业务服务都直接从 redis 读取用户状态。

JSX 已经赢了，Vue 支持 JSX ，TypeScript 天然支持 JSX ，后来的前端框架 SolidJS 、Qwik 都直接使用 JSX 作为描述 View 的方案。

在组件化时代，应该以组件为单位做分离。组件内部将逻辑(JS)、视图(HTML)和样式(CSS)写到一起对开发效率有非常大的提升。JSX 允许在 JS 里描述视图，Tailwind 和 css-in-js 允许在 JS 里直接写样式。

接口格式一般听后端的，但是文档一定要写清楚。
最好是加上 OpenAPI/tRPC/GraphQL 确保端对端类型安全，能避免很多接口对接的问题。

React Server Component 在我看来不是一个好的设计，为了解决一个简单问题的问题引入了更多概念和复杂度。

最初 RSC 要解决的简单问题是：在服务端渲染时如何请求数据？
由于 React hooks 令人费解的设计哲学，React 传统组件无法异步。在客户端渲染时，一般通过 `useEffect` 来获取数据。而在服务端渲染时，我们无法使用 `useEffect`，这使得在服务端请求数据（以及其他异步操作）成为了一个问题。顺带一提，vue3(nuxt.js) 就不会面临这个问题，因为 vue3 的组合式 API 没有 React hooks 的一堆限制，并且 setup 是能够异步的。

Next.js(RSC)给出的答案是：设计一个全新的服务端组件，专门用来在服务端发请求。好处是，这个组件可以异步了，坏处是，在这个组件中无法使用 hooks 。
Remix(React-Router-v7)的答案是：Loader 。预先定义好要加载的数据，框架会在数据加载完后将数据注入到组件中。

在我看来 Loader 方案明显比 RSC 更好：

1. 性能更好：Loader 单次加载完成页面所有数据； RSC 每次加载一个组件，加载完父组件的数据，再加载子组件的数据。
2. 更低的心智负担：Loader 只需要提前写好请求，然后方便地通过 useLoaderData 拿到数据； RSC 则引入了额外的服务端组件的概念，在编写时得区分是否为服务端组件，还得到处写 "use client"。

包括新出的 TanStack 也是提倡使用 Loader 方案而不是 RSC 。

参考：
https://react.dev/blog/2020/12/21/data-fetching-with-react-server-components
https://nuxt.com/docs/getting-started/data-fetching
https://remix.run/docs/en/main/discussion/data-flow
https://tanstack.com/router/latest/docs/framework/react/guide/data-loading

不用设计，已经有现成的 GO 语言了

现阶段选 React 不会错，生态比其他好得多，js 性能问题也解决了。

React 可以开发前端，做 APP 直接用 React Native/Capacitor ，做小程序用 Taro 。React 理论上可以适配到所有图形引擎或者平台上，包括 Flutter 同款的 Skia ，要是 Impeller 性能出色的话，React 再适配到 Impeller 也完全可行。

新出炉的 React Native 0.76 默认启用了新架构，性能大幅提升，再加上 hermes 引擎，js 的执行速度早就不是瓶颈。

Flutter 的优势是界面是完全自绘，能保证所有平台的一致性。这同时也意味着放着完善的 ios/android 生态不用，全部都另起炉灶。这当然是值得鼓励的，但是谷歌给到 Flutter 的支持显然不如 Apple 给到 iOS 的，也不如谷歌自己给到 Android 的，于是 Flutter 在体验上始终与原生 APP 存在差距，尤其是高帧率逐渐普及之后，Flutter 不得不放弃 Skia 自研 Impeller 。

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

React 的思路和 Flutter 非常不一样。
React 有一层虚拟 DOM ，目前 React 的虚拟 DOM 适配了 web(react-dom)、iOS | Android (React Native)、windows (react-native-windows) 还有社区维护的 tvOS 、Skia ，甚至 React 还能直接渲染到视频 ( https://www.remotion.dev/) 。按理说要是 Flutter 的 Impeller 性能出色的话，React 再适配到 Impeller 也完全可行。
而 Flutter 想做的是跨平台的图形界面的渲染引擎。Flutter 的界面是完全自绘的，这意味着放着完善的 ios/android 生态不用，全部都另起炉灶。这当然是值得鼓励的，但是谷歌给到 Flutter 的支持显然不如 Apple 给到 iOS 的，也不如谷歌自己给到 Android 的，于是 Flutter 在体验上始终与原生 APP 存在差距，尤其是高帧率逐渐普及之后，Flutter 不得不放弃 Skia 自研 Impeller 。

新出炉的 React Native 0.76 默认启用了新架构，性能大幅提升，再加上 hermes 引擎，js 的执行速度早就不是瓶颈。

而 Flutter 好像越来越不受 Google 重视了（ https://www.v2ex.com/t/1084590 ） ，之前提到的全新 Impeller 引擎还没有完成 ( https://github.com/orgs/flutter/projects/21 ) ，期待 Impeller 能够拉近 Flutter 与原生的差距。

我个人体验下来 React Native 的流畅度是显著好于 Flutter 的，React Native 在动画表现上确实 Native 。Flutter 写的页面一滑动就知道是 Flutter 写的（看惯了 120 hz 再看 60hz 肉眼可见掉帧）。

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

其实，除了你，我们都是 NPC

1. GraphQL 需要整个团队巨额的学习成本，相比整个用 GraphQL 重构不如糊个 BFF 层； GraphQL 的生态和普及度还比不上 RESTful ；

2. 权限处理和 RESTful 并无二致，在请求进来时判断用户权限，在查数据库时加额外条件；

3. 我个人理解拿到参数就能验证了，楼主可能在找一种更便捷的验证手段，推荐使用 GQLoom 框架( https://gqloom.dev/ )，天然集成 zod 、valibot 作为验证库，有完善的中文文档。

GraphQL 很好用，对比 RESTful API 简直完胜。但是很多人并不理解 GraphQL ，甚至把 GraphQL 和 SQL 混为一谈。

GraphQL 在团队开发中解决了 3 个主要问题：
1. 服务端到客户端的强类型：GraphQL 本身是一门语言，而且是强类型语言。使用 GraphQL 客户端能够通过服务端提供的 schema 生成全面的 API 类型，极大减轻了前端的负担；
2. 文档与沟通：每个 GraphQL 服务都会有一个 schema 文件，这个文件就描述了该服务内的所有接口，要了解该服务可以直接看 schema 而不是代码；
3. 接口聚合：GraphQL 允许客户端定义要获取的字段，前端想拿什么接拿什么，避免了前后端扯皮（ https://www.v2ex.com/t/1036619 ）。大型项目里常常需要 BFF 中间层也是为了接口聚合，很多 BFF 层甚至都是拿 GraphQL 搞的。

看楼主的发言，我估计后端是直接用 PostGraphile, hasura 这样的框架直接把数据库表以 GraphQL 的形式暴露给前端。不得不说这是效率极高的做法，但是很难控制权限访问，只适合快速开发阶段使用。常规开发时我还是建议使用 nest.js 这样的框架老老实实做功能。

顺带安利我们团队自研的 GraphQL 框架 GQLoom：
https://github.com/modevol-com/gqloom
GQLoom 是实现优先（ Implementation-First ）的 GraphQL 框架，适用于 JavaScript/TypeScript 。GQLoom 最大的亮点是允许使用 Zod 、Valibot 这样的 Schema 库构建 GraphQL ，代码简洁且有完善的类型安全，马上会跟进对 Prisma 、Drizzle ORM 的集成。

TypeORM

> 当我把一个表字段定义为 nullable: true 或者 nullable: false 的时候，似乎并不影响这个字段在代码里是 optional 还是 required ？

是的，装饰器无法影响 class 内属性的类型。


> 如果我不通过 ORM 自动建表，而是自己在 navicat 里建表，那是不是 TypeORM 里面的 @Column 装饰器参数就没有任何意义？

不完全是，@Column 装饰器参数的主要作用就是生成简表语句，其次 TypeORM 在运行时会通过装饰器参数（元数据）做一些判断，避免一些错误的 SQL 。

> 我定义一个 Entity ，所有字段都是 Not Null 的，类型也都是 required 的，结果 TypeORM 允许我往这个表里保存空对象？等着数据库报错？

是的，装饰器无法影响 class 内属性的类型。但为了更好的类型安全你应该在 tsconfig.json 中配置 strictPropertyInitialization 为 ture ，并为每个属性声明是否为 nullable ( https://typescriptlang.org/tsconfig/#strictPropertyInitialization )

我个人建议你尽早抛弃 TypeORM ，TypeORM 项目已经不再积极维护了。换更严谨 mikro-orm ( https://mikro-orm.io/ )，mikro-orm 能通过 ts-morph 从 class property 提取类型以及 nullable ，能够避免装饰器内 nullable 属性与 class property 声明的 nullable 不一致的情况
https://mikro-orm.io/docs/defining-entities

tRPC 简单但严谨
https://trpc.io/

React Native 和 Flutter 的思路很不一样。

React Native 秉承 React + web 的理念，使用 React + JavaScript 运行时借助各平台原生组件呈现视图。
React Native 的优势是：可以轻松使用系统原生视图、获得原生级的用户体验和动画流畅度，使用 js ，能够轻松热更新；
React Native 的缺点是：在各个平台呈现的视图不一致；

Flutter 使用自己的绘图引擎，在各个平台上自绘视图，运行机制更接近游戏引擎。
Flutter 的优势是能够自制复杂的视图控，；在所有平台上获得一致的视图；
Flutter 的缺点是：Flutter 的绘图引擎（ Skia 、Impeller ）比不过原生的动画流畅性和交互体验，这方面有太多的 issues 了：动画反馈会延迟 1~3 帧，无法使用 Android 12 的滚动回弹动画，滑动和翻页时有明显的掉帧，严重的着色器编译时卡顿( https://docs.flutter.dev/perf/shader ) ；难以在 Flutter 视图内嵌入原生组件

另外近些年前端的开发理念一直比较领先，React 虽然稍微落后 vue3 、solidjs 、qwik ，但比起 Flutter 还是领先一个大版本的。Flutter 使用嵌套地狱写视图，React 有 jsx ； React 状态管理的 zustand 、jotai 、valti 一个比一个简单易用，Flutter 连 hook 都没有。

对于不需要复杂的绘图操作的 APP ，也就是普通 新闻、聊天 APP 的话，应该首选 RN + expo ；如果你要开发具有复杂视图的 APP ，比如游戏、谷歌地球、高德地图、Wonderous ，应该首选 Flutter 。
具体到楼主的 记账 APP ，肯定首先 React Native 。

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

推荐 Nest.js ，应该是最完善的 GraphQL(node.js) 框架了，并且有丰富的生态
https://docs.nestjs.com/graphql/quick-start

不喜欢 Nest.js 依赖注入这一套的可以就用 TypeGraphQL： https://typegraphql.com/

如果想要类型安全，推荐 Pothos ，Pothos 的问题是过于学术派以至于开发体验不好，需要写很多冗余重复代码以确保程序正确
https://pothos-graphql.dev

Redux 早该被扔进垃圾桶。
状态管理建议用 zustand: https://github.com/pmndrs/zustand 。

都存 redis 了，那用 jwt 设过期时间也没有太大意义了。
我的建议是直接换成类 session token ，格式是 `{user-id}-{random-string}`，拿类 session token 作为键、用户信息作为值存进 redis 。

https://v2ex.com/t/979326

整个项目没有任何性能优化，根组件的 update 将导致整个页面的 update 。没有 memo 。只有两个 useMemo ，其中一个 useMemo 根本没必要，应该直接提升出组件外作为常量。