V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
gongquanlin
V2EX  ›  Node.js

阿里 Midway 解决了什么问题?

  •  
  •   gongquanlin · 2022-04-06 14:37:31 +08:00 · 7959 次点击
    这是一个创建于 722 天前的主题,其中的信息可能已经有所发展或是发生改变。

    前段时间发现了阿里的 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
    kid740246048
        1
    kid740246048  
       2022-04-06 17:19:19 +08:00
    我前公司的做法是:
    后端:负责数据和业务逻辑,对外提供细粒度的 dubbo 接口
    中间层:根据前端需要,调用不同的接口并拼接数据,对外提供 http 接口,同时负责页面的服务端渲染
    前端:负责多端视图和样式处理
    因为中间层主要服务于前端,所以使用 node.js 开发,由前端维护。至于你说的前后端沟通成本,我们是通过规范化的接口文档来约束。

    上面说的主要是回复你关于前后端分离的实践,而 Midway 框架本身我没怎么接触过,只能理解为它是 node.js mvc 框架的一种,具体优缺点楼下各位大佬回答
    vibbow
        2
    vibbow  
       2022-04-06 21:16:08 +08:00
    解决了 KPI 不足的问题。
    afewok
        3
    afewok  
       2022-04-06 21:34:26 +08:00
    serverless 包层 kpi 的皮而已。用处还挺多的,比如晋升、开会,以及宣传自家开源贡献等等
    gongquanlin
        4
    gongquanlin  
    OP
       2022-04-07 09:04:30 +08:00
    6 啊,kpi 项目~
    dany813
        5
    dany813  
       2022-04-07 12:48:26 +08:00
    就一个 node 框架而已
    huruwo
        6
    huruwo  
       2022-04-07 18:00:17 +08:00
    不是阿里开源的明星项目,最好别用。说不定是个 kpi 项目,后面无人维护
    huruwo
        7
    huruwo  
       2022-04-07 18:01:50 +08:00
    谁没被 weex 坑过
    libook
        8
    libook  
       2022-04-08 11:11:31 +08:00   ❤️ 1
    国内企业里,阿里的开源项目是最多的,但同时烂尾项目也是最多的,这些项目了解了解思路学一下就可以,真正要用到生产上的话得充分考察一下。

    任何架构都是有适用场景和不适用场景的,比如加一层 BFF 可以让后端专注于资源和核心业务,前端可以更灵活地实现表层业务,如果后端只服务于这一个前端的话,加一层确实意义不大,因为 BFF 的工作后端也可以做,但如果后端是被很多业务团队的前端共用的,加一层就可以让后端仅提供通用 API ,细节让前端根据自己的业务特点自己在 BFF 层定义,从而有可能可以节省开发成本。

    很多东西的存在不是为了完全替代其他方案的,而是在某些情况下比其他方案更适合,比如一个项目需要加一个 BFF 层来节省开发成本,而且 BFF 层要让前端团队去负责,那么让精通 JS 的前端在写 BFF 的时候肯定也是首选同样用 JS 的 Node.js 技术栈,再让前端去学 PHP 、Java 成本就太高了。

    你觉得多余,是因为你目前的项目场景不适合这个方案,不一定代表这个方案在任何场景都多余。
    gongquanlin
        9
    gongquanlin  
    OP
       2022-04-14 18:20:36 +08:00
    @libook 有道理,大佬牛逼
    willx12123
        10
    willx12123  
       2022-06-19 10:46:15 +08:00
    赞同 @libook 的看法,阿里的 JS 项目我用过的,唯二好用的,只剩下了 Antd 和 ahooks 。别的都烂尾的挺严重的,学学思路就好。随意上生产环境可能会死的很惨。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   956 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 20:36 · PVG 04:36 · LAX 13:36 · JFK 16:36
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.