大家好,我卡颂。
codesandbox
是前端工程师经常使用的「代码在线运行环境」,页面如下:
他的应用场景很广,比如:
- 有代码逻辑要分享,分享个
codesandbox
链接 - 有新想法需要验证,又不想本地起个项目,用
codesandbox
- 技术文档演示
Demo
,用codesandbox
作为一个在线运行代码的编辑器,这么多人天天免费用,他服务器扛得住么?
毕竟,同样作为在线代码运行环境(主要是跑算法题)的leetcode[1],如果同时刷题的人多了,提交后都还得排队:
codesandbox
是如何实现的?他会面临leetcode
一样的服务器压力么?
codesandbox的分类
这个问题的本质其实是问 —— 用户在codesandbox
中写的代码,究竟是在前端还是后端编译成静态资源的?毕竟,如果是在后端完成,会增加服务器压力。
比如,对于下面这段React
代码:
// main.jsx import { createRoot } from "react-dom/client"; import { Cpn } from "./Cpn";
function App() {
return (
<Cpn />
);
}
createRoot(document.getElementById("root")).render(<App />);
要想在浏览器中运行,涉及几个前置工作:
- 需要编译
JSX
语法,比如将<App/>
编译为_jsx(App, {})
- 需要解析并提前下载所有依赖,比如这里的
react-dom
、react
包 - 需要解析模块依赖关系,比如
main.jsx
导入了Cpn.jsx
中的Cpn
组件。对于不支持ESM
的浏览器,需要将代码打包。对于支持ESM
的浏览器,需要处理引入路径 - 如果涉及到其他资源,比如图片、文字、
HTML
文件,需要有相应的处理
上述工作,codesandbox
是在浏览器还是服务器完成的呢?
在这个例子中,这些工作都能在浏览器完成,比如:
- 对于所有第三方依赖,可以在浏览器中直接请求
CDN
- 涉及编译的工作(比如编译
JSX
、模块依赖分析),本质其实是字符串的解析,可以用浏览器版本的babel
实现
上面的例子是一个纯前端的React
项目。但有些依赖服务端环境的项目没法采用上述方式运行,比如:
- 使用了
Docker
的项目 - 类似
Next.js
这样的全栈项目
这种情况就需要一个真实的服务端环境。
两者的区别可以用下图概括:
- 纯前端项目:编译与执行都能在浏览器完成
- 全栈项目:项目编译在服务端进行,浏览器负责项目执行
他们分别对应codesandbox
的两种运行环境:
Browser Sandbox
:基于浏览器的本地运行环境Cloud Sandbox
:基于MicroVM
的云端运行环境
当我们通过模板创建codesandbox
项目时,可以通过「右上角是否有Cloud标记」区分两者:
可以发现:
- 纯前端项目(比如
React
项目、纯JS
项目)使用Browser Sandbox
- 需要服务端运行环境(比如
Docker
项目、全栈框架项目)使用Cloud Sandbox
对于Cloud Sandbox
,他底层使用亚马逊开发的Firecracker
快速启动轻量级的MicroVM
,这也是AWS Lambda
底层使用的库。
所以,基于Cloud Sandbox
启动的项目确实会占用服务端资源。具体来说,每个项目会分配:
- CPU:2个虚拟 CPU(vCPUs)
- 内存:2GB
- 存储:6GB
这块是codesandbox
公司的核心业务。毕竟,免费试用满意后,可能就会上付费的Pro
版(更多资源分配),或者团队定制版。商业模式与Vercel
类似 —— 提供免费基础服务(自担部分资源费用),通过增值的云服务收费。
而前端开发日常使用codesandbox
创建的项目,大多数并不是基于Cloud Sandbox
,而是基于Browser Sandbox
启动的。这些项目并不会给codesandbox
带来太多服务端压力。
两种sandbox的区别
有个很直观的方式区分两种Sandbox
—— 当我们新建一个codesandbox
项目,在预览区域可以看到项目临时url
:
新开页面,访问这个url
,如果请求的资源包括:
- 项目运行所需的静态资源
webpack
热更新相关代码
那代表这是个Cloud Sandbox
项目。Cloud Sandbox
在云端启动后端服务与当前页面通信,就类似我们本地开发时起的后端服务一样。
如果请求的资源包括:
- 项目运行所需的静态资源
sandbox
初始化相关代码
那代表这是个Browser Sandbox
项目。
「sandbox初始化相关代码」是一个简化版的webpack
,他会在浏览器执行,下载依赖、编译代码,打包并执行代码。
我们平时使用codesandbox
时看到的如下初始化画面就代表Browser Sandbox
在浏览器执行相关操作。
比如,下图是在通过CDN
安装依赖(@babel/core
):
当依赖安装完成后,下面是编译代码:
Browser Sandbox实现原理
Browser Sandbox
相关代码都是开源的,让我们按照抽象程度从上往下介绍他。
首先是封装最完整的库 —— @codesandbox/sandpack-react
。这个React
库提供了很多开箱即用的codesandbox
模块。
比如:
SandPackCodeEditor
:codesandbox
左侧的代码编辑区域,底层采用的是codemirror[2]这个代码编辑器SandpackConsole
:codesandbox
中的控制台SandackPreview
:codesandbox
右侧的预览区域,会渲染一个iframe
,iframe
的地址对应了Browser Sandbox
的执行环境
各个组件通过postMessage
与SandackPreview
渲染的iframe
交互。
我们会发现,codesandbox
的核心实际上包含三部分内容:
- 各种编辑器相关模块的实现(比如代码编辑部分、控制台、预览)
Browser Sandpack
运行环境,是一个独立的网页,在预览模块(SandackPreview
)中通过iframe
渲染- 1与2之间通信的协议(即页面与
iframe
之间的通信协议)
@codesandbox/sandpack-react
实现了1,他依赖的@codesandbox/sandpack-client[3]实现了3。
2相关的源代码在codesandbox-client/packages/app[4]中。将这个包的代码部署上线后,就能获得一个Browser Sandpack
运行环境。
上面已经简单介绍了Browser Sandpack
的工作原理,再将他(2)与1、3结合起来的工作原理如下:
比如,用户选择React
作为项目模版:
编辑项目代码后,项目代码与preset
(类似webpack
中的preset
选项项,不同模版对应不同preset
)会通过通信协议传递给Browser Sandpack
页面。
Browser Sandpack
页面通过内置的mini webpack
与其他工具(比如babel
),编译并执行代码。
代码编译、执行的信息也会通过通信协议传递回各个需要的模块。比如,控制台模块可以根据type
为console
的信息打印消息。
总结
codesandbox
有两种代码运行环境:
Browser Sandpack
:针对「编译与执行都能在浏览器完成」的纯前端项目Cloud Sandpack
:针对需要服务端运行环境的项目
这两种环境会体现为一个独立网站,这个网站会作为iframe
嵌入在codesandbox
编辑器的预览模块中。
预览模块通过定义好的通信协议与其他模块(比如代码编辑模块、控制台模块)通信。
对于Cloud Sandpack
,会占用一定服务端资源。对于Browser Sandpack
,则不会占用什么服务端资源,因为他大部分逻辑都是在前端执行的。
参考资料
[1]
leetcode: https://leetcode.cn/problems/two-sum/
[2]
codemirror: https://codemirror.net/
[3]
@codesandbox/sandpack-client: https://www.npmjs.com/package/@codesandbox/sandpack-client
[4]
codesandbox-client/packages/app: https://github.com/codesandbox/codesandbox-client/tree/master/packages/app