分享分为 5 个部分：

1. 介绍 2014 年淘宝使用 midway 在收藏夹进行前后端分离的实践情况。主要包括技术方案、部署架构和合作方式。
1. 淘宝为什么要做前后端分离：webx 的带来前后端开发合作上的问题，后端要写模版，指责不清晰；
2. 采用node架构后的开发方式的转变，指责清晰。但是部署架构上会相对复杂，且稳定性上会遇到一些问题。
2. 谈谈蘑菇街为什么要做前后端分离，在选择前后端分离技术架构时候所考虑的问题。 
1. 蘑菇街在 2016 年初的状况：所有代码在 php 里面，前端也写 php view 层里面各种逻辑，甚至还有连数据库的；
2. 选择哪种技术方案进行前后端分离：node、php 还是其他，为什么最终会选择 vm 的方案。
3. 在确定了技术方案之后，我们是怎么剥离前后端，怎么采用一套基于 jvm 的方案来解决两端的问题（蘑菇街前后端分离的框架介绍），以及前后端分离过程中面对的发布、联调等问题。...

浏览器端 JS 异常监控算是前端领域的老生常谈了，必要性与重要性不言自明，它看起来非常简单却也容易在实施中各种碰壁。JS 有跟其他主流语言类似的异常机制，浏览器也有相关的异常捕获接口，但是不同浏览器之间实现上的差异需要针对性处理。生产环境部署的 JS 一般都经过压缩，如果要定位异常在源码中对应位置需要利用 sourcemap 来处理代码位置映射。

本次分享介绍百姓网在 JS 异常监控方面的探索过程。了解和借鉴其他团队的经验，对比之后制定适合自己项目的方案，力争对现有代码的影响最小化。在了解 window.onerror 的限制与不足后，利用 Babel 进行 AST 转换，将 JS 代码用 try catch 包装起来，并依据浏览器特性分别加载源 JS 和包装后的 JS。上报的异常数据发送到服务端（sentry）用于检索和统计，既可以结合 sourcemap 查看异常对应源码位置的上下文代码，也可以配合灰度测试与异常预警机制提前发现问题。除此之外还有很多细节上的小问题，例如噪音消除、浏览器 Error 对象实现差异等。