04月30, 2017

A Tiny WEB IDE

从去年年底申请大创项目,“构思”了大半年的时间,一直都是纸上谈兵。终于在五一假期,赶在中期答辩到来以前,把最初的版本做了出来。果然 Deadline 是第一生产力。

我们大创立项的名称是“基于 Docker 实现的 Web 在线编程平台”,其实就是一个广义上的 Web IDE 以及一些额外的服务。市面上的 IDE 良伪不齐,实现的功能也有多有少。但有一些特性是作为 IDE 必备的,比如编辑器和集成的编译运行功能。

前端的技术栈,我一直确定的是 Vue.js,因为我们的前端团队不过三名成员,并且可以预计大部分代码会是我个人写,所以我们需要的是灵活轻量的框架。Vue 的设计初衷就是做一个为个人开发者和小型团队敏捷开发的框架,在这点上符合我们的需求。jQuery 也是一个备选项,但在当下 JavaScript 的 API 逐渐成熟,jQuery 这种直接操作 Dom 的框架逐渐被工业界舍弃,所以被我否了。在前端,我们还需要一个开源的编辑器,毕竟自己造一个这么大的轮子肯定是一个吃力不讨好的活,经过一番考察,我选择了 CodeMirror。前期,前端的压力并不大,更多复杂的业务逻辑后续才会慢慢上来,主要的压力在于后端。

在后端,我们需要实现 IDE 的编译和运行功能,在这方面需要关于操作系统、编译工具、后端语言等一系列的知识,显然在知识层面上我们是有缺陷的,所以在这方面的技术选型也倍经波折。立项之后,我们最先找到了 Coding 的 Web IDE 项目,它实现的功能与我们的需求很类似,并且也是基于 Docker 的。但我们在一开始就没能把它完整地跑起来,一方面是由于其文档的不完善和代码在不同系统上的部署问题,另一方面它是用 Java 写的,在这方面我们没有开发经验。于是这个项目被我们搁置了。后来 boge 决定研究一下我们 ACM 队使用的 BNUOJ 的后端代码(虽然我们一直承担着 OJ 的维护任务,但对其后端实现还不甚明了),它是用 CPP 写的,使用了一些开源库,然后由于看不下去也搁置了。于是后端的情况并不乐观,后续的进展会在下文提到。

除了后端与前端外,还有一个负责前后端通信的中间层。中间层包括了派发静态文件的一个静态网页服务器,以及连接后端 Api 的路由层。在工业界,中间层一般也属于大前端的职责范围,在我们团队也基本是这样。所以在开始时,考虑到前端团队要写前端和中间层的上下文切换负担,我是想用 Node.js 实现。但在寒假深入学习使用 Node.js 以后,我发现要写出高质量可维护的 Node 代码需要较深的功底,可以想象到学妹们看着 Node 代码迷茫的眼神。所以这个过程中,我一直在犹豫,在范神等一干高喊着“PHP 是世界上最好的语言”的人的安利下,差点选择了 PHP7,直到我看到了 Go。学习了半天 Go 以后,我便决定使用 Go 来写中间层。这中间有几点考量:一是 Go 自身的严谨,从设计上就避免了一些低级错误,适合我们的新手团队;二是 Go 内置的网络和并发库就很全面易用,不需要依赖太多的第三方库;三是我发现了一个 Go 的官方项目,与我们当前的 IDE 需求类似,可以供我们前期学习效仿,快速成型;此外 Go 的学习成本不高,我熟悉基本语法后就可以基本看懂大部分 Go 代码。

于是我花了半天时间,写出了中间层代码,解决了前期的基础需求。整个大的理念上,我们使用 RESTful API 的设计风格,前端通过 AJAX POST 请求到不同语言的编译接口上,接收返回的 JSON 格式的编译运行结果。

在上述的开源项目的帮助下,我还成功地在 Docker 容器里起了支持编译运行 Go 代码的沙箱。这个沙箱还比较简易,但由此带来的好处就是方便我们的学习掌握,并且能不受限地运行大部分的 Go 代码。

这样一个微型 WEB IDE 就成功地运作了起来。在接下的开发中,我们只需要逐步完善它,增加支持的功能,增强系统的鲁棒性。总的来说,我们在技术选型上耗费了大量的时间,这其实是因为我们贫乏的经验,这个过程对于我们也是一个学习积累的过程。俗话说:万事开头难,当下算是开了个不错的头,足以应付中期答辩,可喜可贺。

本文链接:https://sxing.xyz/post/a-tiny-web-ide.html

-- EOF --

Comments

评论加载中...

注:如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理。