开源项目 Puer: 实现 “低碳” 的前后端分离开发

leeluolee · 2014年10月29日 · 最后由 leeluolee 回复于 2014年10月29日 · 3878 次阅读

puer

简而言之,Puer 是一个可以实时编辑刷新的前端服务器。特性一览:

  • 提供一个当前或指定路径的静态服务器
  • 所有浏览器的实时刷新:编辑 css 实时更新 (update) 页面样式,其它文件则重载 (reload) 页面
  • 提供简单熟悉的 mock 请求的配置功能,并且配置也是自动更新。
  • 可用作代理服务器,调试开发既有服务器的页面,可与 mock 功能配合使用
  • 集成了 weinre,并提供二维码地址,方便移动端的调试
  • 可以作为 connect 中间件使用 (前提是后端为 nodejs,否则请使用代理模式)

使用

cd /path/to/workspace ↵
puer ↵

!puer

其它移步主页

这里也有简单的中文介绍


这是个极简的工具 (实现和使用),所以两年多来一直没进行推广,都是自己和周围同事的御用品。不过最近初次发布到 HN 很意外的上了首页, 意外收获了一些关注,目前应该还可以在 github trending 里找到,相信可能对大家有一定的意义。 查看了关注者的区域发现国人很少, 所以决定来这里推广下。

为什么不发 CNode 发 ruby 圈? 因为在这里曾得到有营养的反馈,产生了一些好感,就这么简单。

好像不支持 sass 和 slim 呢, 对我没什么用... rails 早就可以这么做了, 加个 guard 就可以

#1 楼 @luikore 跟 guard 其实关系并不大,如果是 live-reload 我在这里回答了一次 https://gitter.im/leeluolee/puer 可以参考下

guard-livereload, 前后端更新都可以监控,实时刷新

我提一点建议,在我看来完全理解 puer 和 livereload 的区别(尽管在功能上有重合之处并且重合之处还不能完全覆盖 livereload),但是不管你相信与否,能理解这一点的人(特别是前端)比较少。

这就是为什么多数人都会把注意力放在 livereload 上,因为这是所有 puer 提供的特性里面最最容易理解的一项(偏偏这项做得并不算全面,很多 edge cases 都不支持,比如 #1 提到的)

所以我建议你可以稍微跟大家解释一下其他的特性,比如说 request mocking / proxy or as middleware / weinre。并且不要只是几句话概括它们是个啥,而是多少描述一个或几个实际应用的场景,可以解决什么问题,可以带来什么便利等等。

request mocking / proxy or middleware 这两项功能我最近都有在用,但不是通过 puer,而是其他的工具或是自己实现,所以我非常了解它们对前端工程师的意义。比如说 request mocking 可以用于测试(依赖异步请求),也可以用于没有现成 API 可用的时候做 rapid prototyping;proxy or middleware 我主要用来和 API backend 访问,特别是当前后端完全分离的时候,有些情况下你没法去改后端,所以没法实施 CORS,甚至你的应用场景也不支持 CORS,但是本地开发的时候我需要跨域访问,于是我可以受益于代理。

或许它们还有其他的好处,但我所用的差不多就这些。weinre 我知道是干啥的,但由于我专注于 web,所以还没机会尝试它。如果你能在介绍 puer 的时候把这些东西描述一下,甚至能录个 demo 那就更好了。这样大家才不至于把大部分的注意力都放在(其实最弱的)livereload 功能上去——实际上若只为 livereload,我个人绝不会选择 pure,一来不够强大,二来作为前端开发反正 grunt/gulp/broccoli……这些我总要用一样的,这些东西用熟了,有没有 pure 对我来说区别不大(至少你提到的这些功能,基本上都有对应的插件可以实现,而且这些插件都是 do one thing,do it well)

#4 楼 @nightire

请问 request mocking 部分,认证怎么 mock 吗?(token/session) 关于这方面有合适的工具吗?求推荐

之前想写个 iOS APP 玩玩的时候就没有找到特别合适的 mock 工具,最后只能 sinatra 搭了一个

@nightire 非常感谢 细心的回答。 其实由于之前是个人工具,其实我也清楚与 livereload 去做功能对比也不科学,其实从 reload 的功能角度上 puer 就直接缺乏两个基本需求

  1. 没有抽象去向:即文件变化后只引起浏览器刷新一种结果,比如 livereload 提供了预编译的选择。这个其实很好解决
  2. 没有抽象来源:即来只有文件变化一种,比如可能希望是一种操作引起你的刷新,而不仅仅是文件变化。

这两点也是我马上会考虑的问题,问题是一旦引入预处理等机制,就必然需要考虑使用带来的复杂性,参数太多说不定还需要配置文件 (或脚本),甚至后续还会有 GUI,趁现在还算简单我还有时间去考虑这些问题,特别是已经有 gulp、grunt 这类构建时。

puer 现在能引起一些关注的主要原因估计就是简单,puer 做了很多无需插件介入的注入工作。 一个还有些功能的工具可以在命令行下使用而不显繁琐 (当然 puer 也提供了 API,可以与 gulp 之类的集成) 可能是它的简单价值。

夹缝之下,寻求生存 ,确实也是一门学问。

关于专业性,其实除了 inspect 可以去掉,puer 功能不算东拼西凑, mock 和 proxy 其实都依赖启动的服务器

需要 登录 后方可回复, 如果你还没有账号请 注册新账号