阿里 Midway 解决了什么问题？

admin

前段时间发现了阿里的 Midway 框架，当时看的云里雾里，感觉他好像就是一个服务端框架罢了，类似于 laravel 、spring
官网介绍说这是一个 serverless 框架，可以直接部署在 serverless ，无惧被云服务商绑定，但是像 laravel 、spring 等不也可以直接部署吗，也不怕被服务商绑定啊
前天又看到了 Taobao UED 的 《前后端分离的思考与实践》 https://www.w3cschool.cn/jdgasx/，文章中说，这样设计框架的目的，好像就是为了把 controller 的责任移到了前端，前端去负责控制器、视图，后端负责数据和业务处理，说好处是可以职责划分。是在本身的业务层中间又插一层 node ，职责划分更明确了，但是前后端的沟通成本 /开发成本会不会更高？
发现这个框架也可以直接操作数据库，也可以用 Midway Hooks 的方式结合 vue 和 react ，目前感觉的好处就是，写页面不用在绑定接口了，中间的数据传递都让框架本身处理了。但是这样搞，和传统 laravel 、springMVC 不也一样吗~只不过一个服务端渲染，一个本地渲染
目前我能想到的更深一步的好处是，可以基于 react 的函数式编程，实现千人千面的效果。但是这样对 app 、pc 的应用好像没有效果。而且徒增一层 node ，感觉深知有点多余呢……

我前公司的做法是：后端：负责数据和业务逻辑，对外提供细粒度的 dubbo 接口中间层：根据前端需要，调用不同的接口并拼接数据，对外提供 http 接口，同时负责页面的服务端渲染前端：负责多端视图和样式处理因为中间层主要服务于前端，所以使用 node.js 开发，由前端维护。至于你说的前后端沟通成本，我们是通过规范化的接口文档来约束。上面说的主要是回复你关于前后端分离的实践，而 Midway 框架本身我没怎么接触过，只能理解为它是 node.js mvc 框架的一种，具体优缺点楼下各位大佬回答
解决了 KPI 不足的问题。
serverless 包层 kpi 的皮而已。用处还挺多的，比如晋升、开会，以及宣传自家开源贡献等等
6 啊，kpi 项目~
就一个 node 框架而已
不是阿里开源的明星项目，最好别用。说不定是个 kpi 项目，后面无人维护
谁没被 weex 坑过
国内企业里，阿里的开源项目是最多的，但同时烂尾项目也是最多的，这些项目了解了解思路学一下就可以，真正要用到生产上的话得充分考察一下。任何架构都是有适用场景和不适用场景的，比如加一层 BFF 可以让后端专注于资源和核心业务，前端可以更灵活地实现表层业务，如果后端只服务于这一个前端的话，加一层确实意义不大，因为 BFF 的工作后端也可以做，但如果后端是被很多业务团队的前端共用的，加一层就可以让后端仅提供通用 API ，细节让前端根据自己的业务特点自己在 BFF 层定义，从而有可能可以节省开发成本。很多东西的存在不是为了完全替代其他方案的，而是在某些情况下比其他方案更适合，比如一个项目需要加一个 BFF 层来节省开发成本，而且 BFF 层要让前端团队去负责，那么让精通 JS 的前端在写 BFF 的时候肯定也是首选同样用 JS 的 Node.js 技术栈，再让前端去学 PHP 、Java 成本就太高了。你觉得多余，是因为你目前的项目场景不适合这个方案，不一定代表这个方案在任何场景都多余。
@libook 有道理，大佬牛逼
赞同 @libook 的看法，阿里的 JS 项目我用过的，唯二好用的，只剩下了 Antd 和 ahooks 。别的都烂尾的挺严重的，学学思路就好。随意上生产环境可能会死的很惨。