未分類
8 9 月 2020

web 开发可不可以像集装箱一样组装起来？

web 开发可不可以像集装箱一样组装起来？

資深大佬 : milu2003516968 3

最近想做一款产品，搭建官网，然后我感觉有很多重复性的工作。
比如我希望为网站增加一个问答系统，又比如我希望为网站增加一个文章系统，又比如我要开发网站的账号系统，注册+登录+手机验证+邮箱发送验证+找回密码等等。
搭建完之后，我还要搭建产品的文档和帮助中心等等。

其实这些东西，你做下一款产品的时候，这种工作依然是重复的。

我也在想，这世界上，会不会还有人跟我一样，做着一样重复的工作呢？

也许你会说，搭建问答系统？网上有很多开源的问答系统啊，至于文章系统？也有很多 CMS 啊。
至于帮助中心，网上很多产品啊，语雀、gitbook，很多很多。

但你有没有发现，这些东西都很重，比如我如果引进一个问答系统，就是引进一整套的东西，文章系统，又是一整套的东西。

也就是说，我希望这些服务可以定制化、标准化、颗粒化。

最好像集装箱一样，问答系统是一个集装箱，文章系统是一个集装箱，帮助中心是一个集装箱。注册登录也是一个集装箱。

当我搭建我的网站时，我希望这些集装箱拼在一块，组合起来。节省我的效率。

比如文章系统，我可以给你提供接口，甚至是一个 UI 模块。你只需要在前台引入就行了。

后端的文章点击、点赞、文章查看量、文章的发布和修改，都是我们网站提供的。

再比如，问答系统，一个问答系统，你只需要在前端嵌入问答系统就行了。问答的数据分析，后台的统计查看，都在我们网站上进行。

这样，互联网就像是一个一个的基建工程，我们提供最底层的模块化组装服务。

你们觉得这样会不会节省很多效率？

大佬有話說 (100)

  • 資深大佬 : svipchao

    fastadmin?

  • 資深大佬 : Trim21

    django app （）

  • 資深大佬 : yhhsuf

    如果不介意客制化…后端 Django app, 前端 React Component?

  • 資深大佬 : falcon05

    WordPress，装相应的插件就有了

  • 主 資深大佬 : milu2003516968

    @falcon05 可能你们都没理解我的意思，我希望提供一种类似微服务的东西，只是提供服务，接口，跟语言无关。

    比如你说 wordpress，那么等于局限了我的语言就是 php，而且我必须装一个 wordpress 的东西。这个东西很庞大的。

    而我的环境是 nodejs 。

  • 主 資深大佬 : milu2003516968

    而且，你们有没有看见 zoom 的官网，帮助中心其实也是自己造的，如果有轮子，他为什么要自己造呢？

    https://www.zoomvideo.cn/download/gettingstarted/

    我如果自己搭建，估计也是自己造的，因为我要引入别的东西，会很庞大。每家公司都有这种东西的，我看见很多都是自己造的，而不是第三方的东西。是他们喜欢自己造吗？恰恰是因为没有好的解决方案。

  • 主 資深大佬 : milu2003516968

    还有很多公司的新闻中心，blog 文章，有时候就是需要简单的功能而已。如果引入一个博客系统，太累赘了。有的时候，我就需要一个服务，就是一个 api 接口，让我展示在前端而已，后端的东西全部打包成一个服务就可以了。
    我观察了很多的公司的网站，其实都是自己开发的居多，如果有现成的解决方案，他们为什么要自己造呢？

  • 主 資深大佬 : milu2003516968

    再来说说注册登录这个东西，账号系统，包括微信登录，手机验证。邮件发送，找回密码。
    如果有一家公司能提供一整套的解决方案，我只需要调用 api 接口，那也是大大提升效率的。而且这些东西每家公司需求都差不多，是可以做成一个标准的服务组件的。

  • 主 資深大佬 : milu2003516968

    总结起来，这些东西如果目前有一家公司能够提供一套方案给我，可能我半个月的工期，直接缩短成 3 天就完成了，而且成本大大降低。

  • 資深大佬 : jin7

    除非世界上只有一种语言 一种框架

  • 主 資深大佬 : milu2003516968

    之前想搞一个帮助中心，产品文档的东西，我发现这个 https://www.vuepress.cn/config/ 东西还挺好用，然后花了几个晚，看人家的教程配置，然后又是部署在服务器上面。我就想，这种东西，难道就没有人做成一个服务吗？
    文章在后台发布和修改，前端只需要引入就行了。很难吗？我为什么要花几个晚上去研究这些配置和代码，光一个侧边栏都搞得我火大。

    而且如今有语雀啊这些乱七八糟的知识库，可是我为什么就用不上呢？这些东西都太庞大了，而且我还要跳到人家的网站去才行，各种体验非常不好。

    所以，有类似需求的人肯定不止我一个人。我看到大多数公司都是自己搭建的多。

  • 主 資深大佬 : milu2003516968

    @jin7 api 跟语言框架是没关系的。我现在前端也只是调用了后端的 api 而已，这个后端可以是 nodejs，或者 php，都没关系的。现在前端和后端普遍都是互相分离的。

  • 資深大佬 : tydl

    @milu2003516968 微信 qq 集成登录

  • 資深大佬 : nvkou

    开源 SSO ～开箱即用的用户管理，权限管理
    firebsse ～开箱即用的移动推送
    各种云数据库～开箱即用的数据库
    即使是 WordPress 都有 API 可以调用的啊。不是只能 php 渲染

  • 主 資深大佬 : milu2003516968

    @tydl 不是这个东西，我要表达的不是这个东西。

  • 主 資深大佬 : milu2003516968

    @nvkou 不是这个东西，我要表达的不是这个东西

  • 資深大佬 : richangfan

    那就是系统本来就有的功能，只是没开启。你到管理后台一开启，好像真的添加了一个模板似的

  • 資深大佬 : zoikhemlab

    你的意思是纯靠 api，各种服务只暴露相应的出口就行对吧？

  • 資深大佬 : renmu123

    你先问问产品经理同不同意

  • 資深大佬 : blless

    阿里好像有搞一个 ice 不知道是不是主想要的

  • 資深大佬 : goinghugh

    如果你只是简单的使用某种功能，这种标准的还是比较容易做的。但是一般情况下，每个公司都有自己的需求，比如账号系统，假如现在有第三方的账号系统，账号体系可能是大而全，也可能是小而精，大而全的时候你简单的使用，会引入很多你不需要的东西到系统中，如果小而精，那又各种不满足，需要你自己理解源码进行二次开发，这样并不会减少太多的工作量。并且需求不是静态的，明天提了一个新的需求让你实现，团队面对一堆“外部系统”估计也是头大的。并且大而全和小而精的定义不是有绝对的界限，而是根据每个人的需要来定义的

  • 主 資深大佬 : milu2003516968

    @zoikhemlab 也不全是。比如文章系统，你可以提供一些简单的组件，把文章列出来，比如热门文章、图文并排，或者纯文字列出来。这些可以通过提供 vue 组件的方式，成本应该不算高。又比如问答什么的，也是类似。总之，又有前端，又有后端。

  • 主 資深大佬 : milu2003516968

    @blless 飞冰，感觉又不是。他只是一个前端组件而已。

  • 主 資深大佬 : milu2003516968

    @goinghugh 第三方存储必要的数据就行了，你需要扩展的数据，自己本地数据库另外开一个就行，好像丝毫不受影响。

  • 資深大佬 : TomVista

    假设你的程序一直活着,
    你这个思路会导致技术成本无限拔高,最终不可维护,
    然后重构,你这程序怕是没人能够从一个个黑箱中重构出来

  • 資深大佬 : libasten

    阿里云有个服务商，叫“速成美站”，是给一些中小企业建官网用的。

    我有个朋友购买了那个服务之后，还是不会弄网站，让我帮忙看看，我折腾了好久，感觉就是和主说的一样，搭积木做网站，产品系统（竟然支持电商），文章系统，登录模块啥的。

    不过这些搭起来也不轻松。

  • 資深大佬 : woodensail

    你说的是 serverless 化的组件吧？其实现在很多啊，比如各大地图服务商的地图组件，比如某些第三方评价组件之类的。都不需要开发者部署服务，直接注册个账号后充钱，然后再页面里面引入组件即可。

    但是这么搞的一般都是大型组件，比如上面提到的地图，如果是小组件，一个页面里面几十个不同公司的组件，风格完全不一样，那真不是一般的丑。

    当然另一种做法就是只用接口，自己做 ui，这个就是目前很常用的做法了，第三方客服，第三方 im，第三方直播系统。这写东西各大云服务商都有卖，是很主流的做法。

  • 資深大佬 : lower

    我为啥要把数据放在你的服务器上？

  • 資深大佬 : levn

    表面上是重复的，实际上是多样的。

  • 資深大佬 : tabris17

    这些服务只是看上去一样而已，即便是非常普通的评论功能，也会有千奇百怪的需求在里面

  • 資深大佬 : zavieryip

    纠正一个说法,节省的是时间,提高的是效率
    只能说太过于理想化了
    从反面来说,假设完全按照你说的那样做,那你的产品倒闭了,我公司也跟着倒闭吗

  • 資深大佬 : securityCoding

    主的意思是 把模块 api 标准化,前端需要调整后端直接引入一套 sdk 即可

  • 資深大佬 : zhw2590582

    那我不是要失业了

  • 資深大佬 : Rxianbei

    技术上确实可以做到，但那就需要集装箱的提供商绝对可靠，能应对各个国家地区不同的法律并作出调整，比如谷歌就不行。
    同时需要提供商有较好的服务延续性，不能说砍就砍，比如微软就不行。
    同时需要提供商有很好的信用，比如中国企业基本都不行。

  • 資深大佬 : across

    搜“无代码快速开发平台”

  • 資深大佬 : NilXuan

    我认为这件事是有价值的，至少可以减少重复工作；当然，能不能提高效率，得看产品自身是否简单好用；如果使用产品的难度高于自己搭建项目，就得不偿失了；
    它的难点在于保证产品的扩展性和可维护性，感觉这需要很厉害的产品经理来洞察需求以及很厉害的架构师设计系统架构；
    至于对外服务，既可以提供解决系统成品，将系统交由客户自行部署；也可以提供托管服务，甚至可以提供维护升级服务；
    主如果有兴趣尝试玩一玩，记得带上我，hh ；

  • 資深大佬 : ipwx

    CMS 做的最好的就是 WordPress 。大部分需求用 WordPress + 插件 + 你自己开发就能解决。。。但你又不愿意用 PHP，那你要么自己每次动手开发整个系统，要么再花十年做个 NodeJS 版的 WordPress 。

  • 資深大佬 : taowen

    组装的难度在于切分模块。切分得太碎了，模块之间就会有很多的互动，从而丧失切分模块的目标

    * 你无法独立理解每个模块。因为模块组装起来会的行为，不是每个单个模块行为的简单加和
    * 你无法在多个项目之间对模块进行独立复用，因为任何一个模块都会牵扯出一大堆关联的模块

    我举了很多具体的业务场景来说明这样的困境 https://github.com/taowen/modularization-examples

  • 資深大佬 : charlie21

    你看看这群网友，同一个问题，换一个提问范式就能得到不同的回答

    你带有挑衅色彩问，大家都说你不行 /t/705780
    更高级的编程方式（可视化无代码编程）：现寻求技术大牛或者有勇气挑战新技术的技术合伙人

    你弱弱地问，大家都为你出馊主意 /t/706713
    web 开发可不可以像集装箱一样组装起来？

    人类的感觉是多么不可信阿

  • 資深大佬 : danhahaha

    码农就是码头搬运工人，集装箱普及的时候，就是码农失业的时候，希望不要有这样的集装箱

  • 資深大佬 : wysnylc

    软件工程的前辈是建筑工程
    建筑工程中有模版化,但是只有临时住房使用而且扩展麻烦唯一好处是可重复利用和迅速移动.但是虚拟世界重复利用和移动就一瞬间的事
    所以建筑工程几千年没解决的事情,你说软件工程这百来年的发展怎么做到?

  • 資深大佬 : dzdh

    learncloud?

  • 資深大佬 : cmdOptionKana

    集装箱一样组装，前提是：需求像集装箱组装一样简单。

    而 web 开发，如果需要开发，目的就是与众不同，要有新东西新玩法。

    比如，你要把 V2EX 的前端抄过去，很简单，前端入门的人拿来练手就可以抄过去。但这样的网站没有特色，做不成大事。难点在于 V2EX 当初自己自创的这个，与当时其他网站都不同的表现方式，包含了极大量原创的概念，几乎每一个“零件”都是定制的。

    你再看看最近发展良好的笔记网站 Notion，如果它用集装箱一样简单的方式，用现有的其他网站的“零件”去拼凑，就不可能做出自己的特色。而 Notion 的成功，正因为它包含了极大量原创的概念，几乎每一个“零件”都是定制的。

  • 資深大佬 : hazardous

    这不是 PaaS 么，只不过传统的 PaaS 提供的是 API 接口，而主需要的是连页面模块都提供了，用时候页面上只要嵌入一个远程模块就可以了，数据也是保存在服务提供商那儿的。

    感觉就用户认证麻烦了点，如果有很多类似的服务器提供者，那必然没有统一的用户认证系统，每个服务都要去各自的提供商去验证，如果使用某一个服务提供者提供的多个服务，那用户认证简单了，但是跟 SaaS 就没什么不同了。

  • 資深大佬 : jaylee4869

    你的想法很危险。会让大量平凡码农失业（逃

  • 資深大佬 : GreyYang

    复杂度不会消失,只会转移. 如果你的基础设施封装了大量复杂度且配置少, 方便集成使用, 就会不太灵活, 例如需要对一个问答系统的某一个方面进行一个定制, 可能无法实现, 这样的基础设施功能受限; 如果你的基础设施配置灵活, 各种定制定制接口丰富, 那么复杂度实际还暴露在用户侧, 配置搭建所需要的专业性和时间精力就会大大增加. 这是一个比较棘手的问题. 具体可以参考 No Code 和 Low Code 词条相关背景.

  • 資深大佬 : Achiii

    想要自定义装修功能？

  • 資深大佬 : n37r09u3

    说的就是 headless cms 吧 CaaS

  • 資深大佬 : Achiii

    我用过一个小程序的留言功能，同 leancloud 一起的，感觉就是特别方便

  • 資深大佬 : abcbuzhiming

    主，你不要以为就你一个聪明人，类似的想法早就有人想过，只是他们都复杂度打败了，非定制的组件无法应对复杂度问题，否则通用组件早就淘汰所有程序员了

  • 資深大佬 : walsh

    当然可以，设计一个强人工智能就实现了，更简单的，招聘几个码农

  • 資深大佬 : hoyixi

    其实国外已经有很多产品了，面向小白建站的。

  • 資深大佬 : matrix67

    面向特定领域的软件工具之所以让人觉得复杂，是因为这个问题本身复杂。我们把解决特定领域问题而所需的知识叫做”领域模型“(domain model)。如果我们不了解领域模型，就不能理解为什么 Photoshop 比系统自带的 Paint 复杂几千倍, 或者为什么我们需要正则表达式这种诡异的东西。我们讲的复杂与简单，都是工具设计哲学层面的。

    以王垠说的 TeX 为例。写出《计算机程序设计艺术》的 Knuth 到底知不知道程序语言设计的基本原则我们可以不加讨论。了解一点字体设计和排版的都知道，计算机排版问题是个复杂的问题。的确，软件工具的设计目标，是把复杂的问题简化。然而，大多数人不知道的是，简化问题是一个两步过程。第一步，我们需要把现实的问题映射到一个领域模型。第二步，是把这个模型简化到我们人可以处理的地步。很多时候这两步合并起来了，让我们觉得这两步好像是一步，并且认为所有的设计，都应该朝简化的方向走。这是一个对设计的错误认识。

    举个非计算机领域的例子：用电饭锅煮饭非常简单，加米加水再按个按钮就行了。电饭锅的设计者的设计目标是操作简单且能完美地煮米。作为工具的设计者，它一方面需要了解大米是怎么煮熟的，另一方面需要提供给用户一个简单的按钮。TeX 作者，从一开始就不是设计一个电饭锅，而是一个精确的温控炉子。有了这个精确的温控炉子，想烧饭的可以把它封装成电饭锅，想做蛋糕的可以把它封装成蛋糕烤箱。设计电饭锅的人的设计，并不比设计精确的温控炉子的人好，或者差。设计者的初衷决定了产品的形状。Kunth 的初衷，正是设计一个可以让他人排版出任何想排版的东西的系统。也就是说，做出一个最终非常简单的，只有一个按钮的排版系统不是他的设计目标。做出一个可以高度定制的系统才是他的目标。

    我感觉上面这段说的挺好。

  • 資深大佬 : cheunjq

    感觉这不是技术的问题，而是利益的问题

  • 資深大佬 : shm7

    可以啊。所以 web 开发可替代性就像这些集装箱一样。

  • 資深大佬 : windyCity

    @cheunjq #53 是技术的问题，也是成本的问题，模板粒度太细，太繁琐。粒度不够细，适应面就不够大，可定制性就弱。

    通用的模板太难做，就算做出来，维护成本也高到不划算。不同行业，不同公司，个性化需求多到你怀疑人生。最后发现还是招程序员定制开发来的划算。

  • 資深大佬 : azcvcza

    前端这种那么吃用户体验的地方，套模板倒也不是不行，万一哪里需要改了，需要的工作量不比重新开发来的少

  • 資深大佬 : springz

    前端微服务吗？我记得有个方案，稍等我查下。

  • 資深大佬 : v2orz

    可能主说的是金蝶用友这样的？这行业里面的大部分需求都是配置组装了

  • 資深大佬 : xianxiaobo

    其实很多外包公司在做这个事情，如何最快的搭建开发完成网站，并满足用户多样化的需求。
    但是没办法做到你想象的那么完美。
    提供接口就稍微简单些，但是提供 UI 模块就难了，除非你们都用统一的前端框架，并且用统一的样式。
    而且缺点就是扩展性问题，如果要扩展开发就很难。

  • 資深大佬 : lio444

    就是做成 Axure 这样的，任何人都可以做一套系统出来。可以自己根据自己需要进行修改调整。

  • 資深大佬 : springz

    single-spa https://github.com/single-spa/single-spa
    阿里乾坤 https://github.com/umijs/qiankun

  • 資深大佬 : springz

    感觉是类似后端微服务的概念，将一个大型系统分隔成为独立的可复用的子模块，子模块可以自由组合结合很少的业务逻辑就能快速组合成一个新的大型系统。

  • 資深大佬 : springz

    类比的注册登录系统其实已经有人做了，国外 Auth0，国内 Authing 。

  • 資深大佬 : JCZ2MkKb5S8ZX9pq

    虽然这些工作是重复的，可是下一个客户来的时候，我多花 20%的力气，就多收 100%的钱了呀。

    当然有可能有鲇鱼乱入，来拼价格拼服务。但具体做到实际运营的时候就会发现，做出产品的成本，是远低于运营销售推广的成本的。所以节省下来的开发费用，在总费用里可能占比并不高。

    程序员的特长是做得出，做生意需要的是卖得掉。

  • 資深大佬 : springz

    类比的帮助中心也有人做了 zendesk，这些都使用过。

  • 資深大佬 : exc

    我有跟主同样的想法，并且正在做，因为我是多项目并行开发的，这些基础构件不独立出来，会非常影响开发体验的。

  • 資深大佬 : exc

    这些东西，有些是可以做成第三方库进行项目集成，有些需要做成第三方服务进行调用，也有些只需要设计成一个 API 就可以了，多开几个项目就能体会出来。

  • 資深大佬 : exc

    不过主要求数据都在自己的网站（或某一个数据中心）上，不太好，应该给使用的人选择权。

  • 資深大佬 : charten

    以前 jq 一统天下的时候有，现在你也可以去巴拉 jq 的插件，很丰富，有些设计到现在都不过时…

  • 資深大佬 : laike9m

    dark-lang 了解一下？虽然好像不能写前端

  • 資深大佬 : jerfoxu

    这个想法很好，的确是有太多重复性的事情了！如果有一家工作把这个事情做的简单一些，很多公司很多岗位是完全没必要的。

  • 資深大佬 : wgco

    主是不是上次看到的说想要开发出一个根据产品画流程图就直接生成代码的哦

  • 資深大佬 : lxk11153

    类似第三方评论系统？这不就行了[doge]

  • 資深大佬 : Saszr

    永远不知道客户会提出什么需求

  • 資深大佬 : jabin88

    有个类似想法。语雀作为大后台。前端页面自己根据 api 自己写。可惜语雀 api 开放的比较少，只有库和文章，也就只能做一个文章发布类，我目前是做了一个 blog 。评论语雀不开放，那就没办法了。只要开放评论和 tag 接口。感觉 cms 的功能就差不多了，前端自己写，后端用语雀。

  • 資深大佬 : xiaoxinshiwo

    springboot-starter

  • 主 資深大佬 : milu2003516968

    @jabin88 语雀我用过，直接抛弃了。还要新开一个页面跳到你网站，域名还是你的，不利于 seo 什么的。体验也不好，而且我不需要那么重的东西。我就是需要一个简单的文档，你别给我别的东西，我用不到。

  • 主 資深大佬 : milu2003516968

    @zavieryip 看我补充的附言。

  • 主 資深大佬 : milu2003516968

    @cmdOptionKana 关键还是你怎么定义这些零件，怎么切割每个需求制造成一个个的零件。

  • 主 資深大佬 : milu2003516968

    @matrix67 你不可能满足所有人的需求，但是你可以满足某个细分领域的需求。很多个细分领域集合起来就是一个大的市场。

  • 主 資深大佬 : milu2003516968

    @exc 可以随时导出数据，不会让你过分依赖我们的服务。适用于前期需要快速搭建原型或者网站的创业公司。可能我这个产品三个月半年运营不好直接就关了，这类用户不会太在意这些东西的。万一做大了，给你导出数据到你自己的网站不就完了嘛

  • 主 資深大佬 : milu2003516968

    @charlie21 你说的那个项目，一看就知道不靠谱，他还找人实现出来，所以一堆人会嘲弄他的点子。
    我要是说我要开发一个时光机穿梭的项目，特来找技术合伙人，肯定一群人喷我。

  • 主 資深大佬 : milu2003516968

    @charlie21 而且你把我的问题跟他的归于同一个问题，那是你没有审好我这个题想表达什么。

  • 資深大佬 : pkoukk

    可是现实世界中的问题不就是系统总会膨胀嘛，一个没有人用的简单系统，确实可以，可这么小也没必要模块化。
    一个很多用户使用的系统，很快就会产生很多需求，需要定制化开发，模块也就不通用了。

  • 資深大佬 : pokon548

    你说的不就是 serverless 容器么（

    推荐试试 Leabcloud （非利益相关，只是刚好觉得符合 LZ 需求

  • 資深大佬 : pokon548

    leancloud…神奇的自动补全

  • 主 資深大佬 : milu2003516968

    @pokon548 不是这个，我现在需要一个简单的博客系统，你告诉我有什么解决方案。别告诉我安装一个 wordpress 。

  • 資深大佬 : km000

    这个想法是很有价值的，最终还是要看执行。

  • 資深大佬 : pokon548

    @milu2003516968 这…尽力说清楚自己的需求不久好了嘛。

    Hexo 、hugo 之类的不是一搜一大把嘛（

  • 資深大佬 : pokon548

    整评论用 Valine，投票随便找个能的网站弄个 iframe 。
    再插到文章模板里不是同样很香吗。就几行代码的事。

  • 主 資深大佬 : milu2003516968

    @pokon548 你看我附言的第一条问答，很多人根本就没看清楚问题是什么。
    wordpress，gitbook，hexo，你觉得混互联网有几个不知道这些东西呢？

  • 資深大佬 : firefox12

    很好的视点，的确 web 缺乏这个能力， 很多年以前，其实是有这样的发展的， 很多留言版服务商， 聊天室服务商。大家在自己的网页里面引入一个页面 就可以了。但是现在 网页的发展 耦合性越来越强了，前端自己的耦合性就很强，希望和别的页面再耦合，缺乏一个公共的对接方案。现在基本都是基于 node 模块级别的组合，还没有这种大模块的组合，我认为这是很有前途的。

    至于数据的问题 绝对也是很大的问题，引入了前端 还有后端的问题。

  • 主 資深大佬 : milu2003516968

    @firefox12

    现在前端组件化，比如很多前端方案都是标准的组件模式了，就是一种集装箱的思想。换几年前，没有这种理念的。
    还有微服务什么的，都是面向比较小的颗粒去划分模块。所以未来的服务肯定也是如此。

    比如你现在想搭建一个论坛系统，不可能沿用以前 discuz 那种庞大的东西了。讲究轻和快，融入你自己的项目里面。

    博客系统，不可能搭建一个 wordpress 这种东西了。如果你的应用需要十几个这样的东西，你的项目肯定十分臃肿。

    所以，划分成粒度比较小的模块，反复重用，标准化，才能提高效率。

  • 資深大佬 : firefox12

    @milu2003516968 你也知道微服务，但你知道微服务之间交互的协议是什么吗？ 关键不在于具体哪种，而是要有一种大家可以通用的。

  • 資深大佬 : wangyzj

    前端圈为了让前端组件化已经奋斗多年且乱的一比
    你这个问题让前端们情何以堪啊

  • 資深大佬 : Michelangelono

    不要你觉得不行就是不行，你倒是问下客户的需求是什么

  • 資深大佬 : wanguorui123

    这就是我在设想业务组件；

    业务组件包含：UI 组件 + 后端业务模块；

    UI 组件：包含多套 UI 布局方案，也可以做样式定制；

    后端业务模块：提供标准化的 API 对接前端的 UI 组件，后端业务模块可以集成到自己的后端系统中，提供一套事件接口对接自己系统的权限验证功能，也可以重写部分方法做功能对接，业务模块也可以存在第三方 PaaS 提供商，通过统一的 OAurh 等方式授权，一次授权，所有第三 PaaS 提供的 API 都可以被 UI 组件调用；

    效果：最终达到集装箱式的组装所有业务组件，根据不同客户需求，使用不同业务组件进行组装。

  • 資深大佬 : wanguorui123

    我也正在验证这个设计理念

  • 資深大佬 : tikazyq

    主的意思是定义一些基本的组件（ component ），也可以叫模块（ module ）、功能（ feature ）、包（ package ）等（叫法可能不同），相当于 web 开发的最基础组成单元，然后万物都可以由这些最基础的组件进行组装，然后拼凑成一个大的 web 应用