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