 |
XCFOXV2EX 第 433443 号会员，加入于 2019-08-01 22:06:00 +08:00今日活跃度排名 6600 |
XCFOX 最近回复了
3 天前 回复了 jiaoguan1688 创建的主题 › 前端开发 › 到底是 gin+html 渲染还是 nextjs 我纠结症犯了 |
react 生态太好了，太多成熟的组件库可以用，比自己手写 html 好看太多了：
https://www.heroui.com/
https://ui.shadcn.com/
https://ui.aceternity.com/
https://www.heroui.com/
https://ui.shadcn.com/
https://ui.aceternity.com/
React 、Vue 的框架都挺不错的，都是全家桶解决方法，看你喜欢哪个。下面是我个人的喜好和推荐：
可选框架：
- Next.js: 时下最流行的框架，生态丰富，功能齐全，但是使用 Turbopack 作为打包器，比 Vite 慢太多了，另外还有今年饱受争议的 React Server Component ，如果你喜欢 PHP 你可能会喜欢 React Server Component ；
- React Router V7 | Remix: React 全栈框架，架构设计比 Next.js 更干净，内置 Loader 、性能好过 Next.js ，对 APP 整体的掌控比 Next.js 更细致，使用 Vite 作为打包器开发体验良好；
- Nuxt.js: Vue 全栈框架，内置 Vue 全家桶，Vue 的开发体验其实一直比 React 要好，而且没有 React Hooks 的一堆坑，使用 Vite 作为打包器开发体验良好；
UI 与界面：
- shadcn/ui ( https://ui.shadcn.com/): 漂亮的可定制的 UI ，使用 Tailwind ，功能完善
- HeroUI ( https://www.heroui.com/ ): 超高颜值 UI ，使用 Tailwind ，组件齐全，开箱即用；
API 接口：
如果你使用了 Next.js 、React Router V7 、Nuxt.js ，你也许不需要额外的后端框架，直接用对应框架的后端功能就能解决大部分问题。
但是如果你想要给接口上工程化工具保证接口的强度和可靠性，那么我推荐：
- tRPC ( https://trpc.io/ ): 端对端类型安全接口，使用 TypeScript 确保接口可靠性；
- oRPC ( https://orpc.unnoq.com/ ): 端对端类型安全接口，以及 OpenAPI ，方便沟通、测试和回顾；
- GQLoom ( https://gqloom.dev/ ): 端对端类型安全接口，以及 GraphQL ，方便沟通、测试、回顾和 AI 阅读，与 Drizzle 、Prisma 深度集成，在几分钟之内构建完整的 CRUD 服务，（利益相关：我是 GQLoom 作者）；
- 不推荐 NestJS: NestJS 显示是设计过度了，TypeScript 没有 Java 那么多条条框框，TypeScript 装饰器由于其类型不健全也是逐年式微；
数据库操作：
- Prisma ( https://www.prisma.io/ ): 流行的 TypeScript ORM ，封装到位，对 SQL 的抽象程度比较高，适合写业务；
- Drizzle ( https://orm.drizzle.team/ ): 新兴的 TypeScript ORM ，性能出众，对 SQL 非常还原，适合熟悉 SQL 的选手；
- 不推荐 TypeORM: 近年维护不积极、类型不安全、空不安全
另外你可能需要了解：OpenAI 从 Next.js 转向了 Remix | React Router
可选框架：
- Next.js: 时下最流行的框架，生态丰富，功能齐全，但是使用 Turbopack 作为打包器，比 Vite 慢太多了，另外还有今年饱受争议的 React Server Component ，如果你喜欢 PHP 你可能会喜欢 React Server Component ；
- React Router V7 | Remix: React 全栈框架，架构设计比 Next.js 更干净，内置 Loader 、性能好过 Next.js ，对 APP 整体的掌控比 Next.js 更细致，使用 Vite 作为打包器开发体验良好；
- Nuxt.js: Vue 全栈框架，内置 Vue 全家桶，Vue 的开发体验其实一直比 React 要好，而且没有 React Hooks 的一堆坑，使用 Vite 作为打包器开发体验良好；
UI 与界面：
- shadcn/ui ( https://ui.shadcn.com/): 漂亮的可定制的 UI ，使用 Tailwind ，功能完善
- HeroUI ( https://www.heroui.com/ ): 超高颜值 UI ，使用 Tailwind ，组件齐全，开箱即用；
API 接口：
如果你使用了 Next.js 、React Router V7 、Nuxt.js ，你也许不需要额外的后端框架，直接用对应框架的后端功能就能解决大部分问题。
但是如果你想要给接口上工程化工具保证接口的强度和可靠性，那么我推荐：
- tRPC ( https://trpc.io/ ): 端对端类型安全接口，使用 TypeScript 确保接口可靠性；
- oRPC ( https://orpc.unnoq.com/ ): 端对端类型安全接口，以及 OpenAPI ，方便沟通、测试和回顾；
- GQLoom ( https://gqloom.dev/ ): 端对端类型安全接口，以及 GraphQL ，方便沟通、测试、回顾和 AI 阅读，与 Drizzle 、Prisma 深度集成，在几分钟之内构建完整的 CRUD 服务，（利益相关：我是 GQLoom 作者）；
- 不推荐 NestJS: NestJS 显示是设计过度了，TypeScript 没有 Java 那么多条条框框，TypeScript 装饰器由于其类型不健全也是逐年式微；
数据库操作：
- Prisma ( https://www.prisma.io/ ): 流行的 TypeScript ORM ，封装到位，对 SQL 的抽象程度比较高，适合写业务；
- Drizzle ( https://orm.drizzle.team/ ): 新兴的 TypeScript ORM ，性能出众，对 SQL 非常还原，适合熟悉 SQL 的选手；
- 不推荐 TypeORM: 近年维护不积极、类型不安全、空不安全
另外你可能需要了解：OpenAI 从 Next.js 转向了 Remix | React Router
18 天前 回复了 p1nk 创建的主题 › 程序员 › 大模型在技术上 能 / 怎么 实现比较准确的数据库查询 吗/呢 ？ |
分析一下我的思路：
1. 将数据库以 GraphQL 的形式暴露 API ，使用 Hasura 或 Graphile
2. 将 GraphQL 通过 MCP 连接到 AI ，使用 https://github.com/blurrah/mcp-graphql
1. 将数据库以 GraphQL 的形式暴露 API ，使用 Hasura 或 Graphile
2. 将 GraphQL 通过 MCP 连接到 AI ，使用 https://github.com/blurrah/mcp-graphql
26 天前 回复了 muchan92 创建的主题 › 程序员 › 人心中的成见是一座大山，数据转换思想 |
楼主已经领悟到了响应式的真谛。
但倘若我拿出纯 TypeScript 响应式代码而且可以在 Vue3 、React + Valtio 、NestJS 、MikroORM 等几乎所有框架中无缝运行，阁下又该如何应对呢？
https://www.typescriptlang.org/play/?#code/MYGwhgzhAEAiD2BbAlgO3tA3gKGtY8qEALgE4Cuwx8pAFAA7kBGIyw0T8YpAJgIwAuaCVJoA5gEosAX2y5oYgKbEOXXgCZaUnHjyll5UqmgADACSZiAC2QQAdJ279p0dSfmz5SlY94BmLSx5PQMjUwtrWwc1HnUXP3c8WU8CIhUeJDQMAF5oVEUAdzhM9FoAckYIKzKJOVSIeBBFOxB4MXLffiEygBpoDJR0aKc+WvrG5tb2ss71br6BrOGNMcIGppa2jpi-ef6S+GWePwkgA
但倘若我拿出纯 TypeScript 响应式代码而且可以在 Vue3 、React + Valtio 、NestJS 、MikroORM 等几乎所有框架中无缝运行，阁下又该如何应对呢？
https://www.typescriptlang.org/play/?#code/MYGwhgzhAEAiD2BbAlgO3tA3gKGtY8qEALgE4Cuwx8pAFAA7kBGIyw0T8YpAJgIwAuaCVJoA5gEosAX2y5oYgKbEOXXgCZaUnHjyll5UqmgADACSZiAC2QQAdJ279p0dSfmz5SlY94BmLSx5PQMjUwtrWwc1HnUXP3c8WU8CIhUeJDQMAF5oVEUAdzhM9FoAckYIKzKJOVSIeBBFOxB4MXLffiEygBpoDJR0aKc+WvrG5tb2ss71br6BrOGNMcIGppa2jpi-ef6S+GWePwkgA
39 天前 回复了 GopherRustaceans 创建的主题 › 职场话题 › AI 发展到今天，再卷技术还有很大意义吗？ |
目前的 AI 还是在背答案，没法处理没见过的场景。
我让 Trae + Claude 搭一个 React-Router v7 + tailwind v4 的项目，AI 完全搭不出来。
leetcode 每日一题 中等以上的题 AI 写的代码有几题能过？
这两天爆火的 https://github.com/microsoft/typescript-go 能让 AI 写吗？
什么时候 AI 能写出 typescript-rust ?
我认为 AI 是数学、统计学的终极工具。现在的 AI 学习了海量的代码，并且有非常强的泛化能力。
从能力上看，现在的 AI 大部分是实习生|初级水平，能够识别和理解常见的技术问题，但需要依赖上级工程师（人类）的指导和帮助，问题解决的过程可能较慢，且容易出现反复。
再卷技术还有很大意义吗？有的，兄弟，有的，你需要成为中高级程序员才能更好地指挥 AI 帮你干活。
"90% of code will be written by AI in the next 3 months"
毫无疑问的是，AI 将为行业带来巨大的生产力的提升。现在 AI 给我的感觉是手底下多 3 个 实习生，我可以把重心放到更难的工作上，把脏活累活交给 AI 。
生产力的大幅提升对社会来说无疑是好事。
但对于我们这些从业者来说更多的是焦虑，也许我们会成为新一代无处可去的纺织工人，也许现在的 AI 已经到头了。
或许以后开发成本低了 个人就可以独立开发做出 WPS, Chrome, 黑神话悟空，这未尝不是好事？
我让 Trae + Claude 搭一个 React-Router v7 + tailwind v4 的项目，AI 完全搭不出来。
leetcode 每日一题 中等以上的题 AI 写的代码有几题能过？
这两天爆火的 https://github.com/microsoft/typescript-go 能让 AI 写吗？
什么时候 AI 能写出 typescript-rust ?
我认为 AI 是数学、统计学的终极工具。现在的 AI 学习了海量的代码，并且有非常强的泛化能力。
从能力上看，现在的 AI 大部分是实习生|初级水平，能够识别和理解常见的技术问题，但需要依赖上级工程师（人类）的指导和帮助，问题解决的过程可能较慢，且容易出现反复。
再卷技术还有很大意义吗？有的，兄弟，有的，你需要成为中高级程序员才能更好地指挥 AI 帮你干活。
"90% of code will be written by AI in the next 3 months"
毫无疑问的是，AI 将为行业带来巨大的生产力的提升。现在 AI 给我的感觉是手底下多 3 个 实习生，我可以把重心放到更难的工作上，把脏活累活交给 AI 。
生产力的大幅提升对社会来说无疑是好事。
但对于我们这些从业者来说更多的是焦虑，也许我们会成为新一代无处可去的纺织工人，也许现在的 AI 已经到头了。
或许以后开发成本低了 个人就可以独立开发做出 WPS, Chrome, 黑神话悟空，这未尝不是好事？
可爱捏
63 天前 回复了 puzzle9 创建的主题 › 程序员 › 后端的大佬们 你们的接口文档注释写道什么程度呀 |
接口用的 GraphQL ，代码里会写详细的字段注释，再用框架生成 GraphQL Schema 。前端直接用 GraphQL Schema 生成接口 SDK ，确保端对端类型安全。
78 天前 回复了 Leon6868 创建的主题 › 程序员 › 组件化 Tailwind 传递 ClassName 参数最佳实践求解答 |
可以参考 HeroUI ，给最外面层组件加一个 classNames 属性来传递子组件的 className
https://www.heroui.com/docs/components/card#slots
https://www.heroui.com/docs/components/card#slots
111 天前 回复了 MingLovesLife 创建的主题 › 程序员 › 不懂就问，请教一下前端无感刷新 token 到底有没有意义？ |
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 读取用户状态。
考虑我们有用户微服务和订单微服务，我们把用户信息存储在用户微服务，向订单微服务发起请求时需要验证用户有效性：
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 读取用户状态。
Select Language