2024 年终回顾
2024 年 JS 生态发生了很多变化，React 19，React Native 0.76，Vite 6 发布。
FaasJS 除了支持以上框架的新版本外，也在 2024 年发布了以下新特性：
@faasjs/server
- 支持 ES Module；
- 支持原生 Response，提升 stream 处理能力；
- 去除厂商依赖，强化独立部署能力；
- 支持对系统 SIGTERM 等信号的处理，保证请求执行完毕后再退出；
- 日志输出内容大幅优化和简化，方便排查和分析；
- 支持 middleware 模式，方便接入其它后端框架的插件；
- 支持静态文件，并且以 stream 的方式输出，减少内存占用。
@faasjs/react
- 支持 React 19；
- 支持 Server Action；
- 添加了一系列辅助函数，如：
createSplittingContext轻量化替代 Redux 等状态管理库；useEqualEffect，useEqualCallback等高性能的比较对象的 Hook；splittingState可快速生成多个 states；usePrevious，useStateRef等辅助 Hook。
- 新增表单组件，可同时用于 React 和 React Native。
2025 年计划
FaasJS 发布至今已经有 5 年，其目标始终是为独立开发者和小团队提供快速开发和低成本运维的解决方案。
2025 年，FaasJS 将继续其定位，基于现有的 JS 生态，做出新的尝试和调整：
强化日志和监控
FaasJS 最初就内置了应用性能的日志，但仅仅以日志的形式输出，对于监控和分析并不友好。
因此明年计划大幅强化 @faasjs/logger，支持 JSON 格式的日志输出，并提供可扩展的 Transport，以便接入各种监控系统。
基于新的日志系统，不仅可以方便的监控日常的请求耗时和错误、数据库耗时等，还可以通过自定义拓展和标签能力，实现诸如大模型 token 用量等监控。
明确技术栈
早期 FaasJS 为了兼容主流的各类基础设施，做了一些兼容包，但这对于独立开发者和小团队来说，很少出现需要同时使用多个基础设施的情况。
因此，2025 年，FaasJS 将明确支持的技术栈，并去除不必要的兼容。
目前计划的核心技术栈为：
- Docker
- 即可独立部署，也可以部署到 Lambda 等云服务；
- 使用标准的 Dockerfile，以便兼容 Podman 等其它容器引擎；
- 有可能会推出轻量级的自部署工具，以简化部署和运维流程。
- Alpine
- 作为基础镜像，减少镜像大小。
- Node.js
- 作为运行时，支持最新的 LTS 版本；
- Bun 和 Deno 等其它运行时也在提升对 Node.js 的兼容性，因此不做特殊的兼容支持。
- Npm
- 作为包管理器，支持最新的 Npm 版本；
- Yarn，Pnpm 等其它包管理器有一些兼容性问题，因此不做特殊的兼容支持。
- TypeScript
- 作为主要的开发语言，支持最新的 LTS 版本；
- 强化前后端的类型约束，提升开发效率。
- React
- 作为主要的前端框架，支持最新的 LTS 版本；
- 由于 React Native 及 Expo 发展迅速，目前市场上没有更好的跨平台方案，因此前端还是以 React 为主。
- Vue 不再做兼容包，但可以通过
@faasjs/browser来支持。
- PostgreSql
- 作为主要的数据库，支持最新的 LTS 版本；
- 可能会用 postgres 替代 pg，目前还在评估中；
- 可能会用 drizzle 替代 knex，目前还在评估中；
- Redis，MongoDB 将不再做兼容包，简化技术栈。
- Vitest
- 作为主要的测试框架，支持最新的 LTS 版本；
- Vitest 支持了一些 Jest 需要第三方库才能实现的功能，并且性能更好，因此明年将逐步从 Jest 迁移到 Vitest。
接入 Astro 生态
Astro 的技术栈很重，但开发体验很好，比起越来越难用的 Next.js，它更适合于 FaasJS 的定位。
我目前正在研究如何将 Astro 与 FaasJS 结合，以提供更好的开发体验。
但底层依然是上文提到的技术栈，特别是会基于 Docker，因为实测发现各类 edge 服务（如 cloudflare、vercel 等）的依赖缺失很容易导致部署失败。
结语
明年的计划是 FaasJS 诞生以来最大的一次调整，还有很多不确定性，如果有什么建议或意见，欢迎留言交流。