最近关注到gayhub阿里的仓库新开源了一个代码库，地址:
https://github.com/alibaba/schema-plugin-flow，看README文件上介绍，这是一个能让开发者通过修改配置相关代码，即可完成对业务逻辑和页面布局的扩展，从而避免对源代码的修改。乍一听介绍我以为是一个跟low code相关的一套解决方案，但是实际看了上手玩过了之后，感觉这样去对他进行一个定义似乎并不准确，具体的详细来看看。
一、定位
刚刚也提到了刚刚接触到Sifo的时候我以为他是一个low code的解决方案，但是这个表述并不准确，先来看下另外一款类似能力的解决方案，也就是百度的amis，这款解决方案的话他的着眼点就完全在于low code，旨在全部通过JSON配置的方式快速低成本的搭建出前端页面。而Sifo也是通过JSON配置的方式来组织页面结构，二者在这点上极为类似。
首先说说为什么前端要做low code方面的研究，其实我个人认为low code的应用场景大多在于B端的一些业务场景，为什么这样说呢？因为B端的业务大多页面较为固定，更多的是各种表单表格数据图等等的排列组合和扩展，而往往这些业务场景下又会出现，页面极其类似但是总有那么些特殊的定制化的改变和业务需求，这点在企业Sass服务中尤为常见。
而在这样的业务场景下，如果我们是按照常规的业务解决方式去开发这些业务需求，那么付出的资源是巨大的，一方面是在开发上面，每开发这样一个页面，都需要开发者去写大量的重复代码，虽然可以通过组件复用的方式来解决部分麻烦，但是终归还是需要开发人员去组织这些代码，从而组织出我们想要的页面。
low code的解决方案就是为了应对这样的业务场景，通过JSON配置这样低成本的方式，去完成页面的快速组织，这样的组织方式也不需要对开发者的前端技术有极高的要求，甚至可以实现交予服务端进行配置，直接通过元数据注入的方式生成页面。amis的主要落脚点就是在这个地方。
而传统的开发方式，另外一方面需要耗费巨大资源的，就是在后期的维护与更新上面。例如刚刚提到过的，在一些通用化的场景里面会有一些定制化服务的需求，这个时候如果去动复用组件或者页面的源代码， 那么成本是极高的，稍有不慎还有影响到其他相关的地方。这里就涉及到一个高扩展的能力了。Sifo的着眼点主要就是在这一块儿，他可以通过内部的控制器实现不侵染源代码的情况下的二次开发扩展，这也是他最主要的一个能力。
所以，我们应该准确的定位这两个解决方案，amis是一个纯粹的low code快速低成本配置化生成页面解决方案，重点在于low code，而Sifo是一个高扩展的配置化生成页面解决方案，重点在于高扩展。
当然这部分关于low code的内容只是基于这两个解决方案做对比而做的片面分析，low code的作用远远不止于此，乃至于最后的终极目标no code去追求可视化搭建这一块儿，是一个很有前景的研究方向，如果有什么不对的地方还望大家指正。
二、使用
在具体的使用上面，Sifo的官方文档也提供了很详细的hello world指引，这里就不多表了。大家可以通过上面贴出的链接去仓库自行查看，cv带师别的不行这点还是很在行的。这里主要说下初步上手使用过后的一些感受。先列举一下:
优点：
- 学习成本低
- 业务侵染性低
- 接入成本低
- 可扩展性高
不足：
- 应用场景支持较少，具有局限性
- 对开发者要求稍高
下面来详细说明我这些弟弟看法的来源，当然这里我没有放具体的demo代码，与其看我的demo不如去看官方的demo来的好理解，个人觉得脱离了真实业务场景的demo都是差不多的：
1.学习成本低
Sifo的上手如果有前端基础的话并不困难，当然Sifo当前的目标受众应该也都是开发者。如果是跑起来的话按照官网的示例代码直接run就可以了。初步使用搞清楚SifoModel这个核心的几个参数就差不多能正常上手了。
这里的schema就是一个页面结构的配置JSON文件，而Plugins就是这个页面相关的插件，比如页面、组件和一些模型等等。而namesapce则是与二次开发扩展有关系。具体的使用方式是这样的(这里以vue为例):
这样的使用上手方式跟amis非常的类似，都是通过一个json文件来作为页面主要的结构配置，然后加上一些其他的能力，包括框架内置的一些UI库，Sifo在这里用的是蚂蚁的ant-design系列组件库作为内置默认组件库。实现了一种数据驱动的页面配置。
2.业务侵染性低
首先Sifo的官方说明是一个高度可扩展的JavaScript库。也就是说他是一个底层的运行库，与我们常见的React/Vue等UI框架是完全独立解耦开来的，也就是说在实际运行的过程中，Sifo对我们写在这些UI框架内的业务代码几乎是没有任何侵染的。
换句话来说，我们在使用Sifo的过程中，除掉上层UI框架库内的业务相关代码，以及跟Sifo结合也就是组件的使用方式不同以外，在Sifo这个框架层的东西是完全一致的，可以拿出来进行复用。而体现在Sifo框架里面，就可以理解为，Sifo的Schema对应的是页面上的配置，这一点跟我们的组件息息相关，而Plugin用来处理一些业务逻辑，这两点可以完全分割开来进行复用。其实这里就是一种可插拔的插件式开发的思想。
3.接入成本低
这一点我觉得是Sifo的一大特色，因为相比于amis而言，amis目前仅仅只支持在React的环境下使用，或者使用JDK的方式进行使用，当然使用JDK的话就不能进行一些自定义能力的使用，比如自定义组件之类，这是一种对非开发者使用的方式，这里我们不加以讨论。而Sifo得益于前面提到的跟UI框架完全解耦，完美的支持了React和Vue两种常用的UI框架，这一点对于我这种Vue型切图选手是非常友好的。也正是因为与UI框架完全解耦，那我们就可以通过对原来的项目进行组件级的修改，就能快速的接入到Sifo中来，整个项目的迁移成本是不算太高。
可以看到的是在Sifo的源码中就对这两种UI框架进行了支持。但是在amis中如果要使用vue相关的能力，那么不仅需要用到自定义相关的能力，还需要在自定义的React组件中引入Vue相关。当然这一点因为两种解决方案的侧重点不一样，所以有些功能性的偏差，倒也说不上谁好谁差，只是Sifo对于使用Vue技术栈的公司和开发者更加友好。
4.可扩展性高
这一点算是Sifo的核心所在了，毕竟官方一直在强调的就是高扩展性。这里我所理解的可扩展性，主要是集中在组件层面，在业务层面的比较少。怎么来说呢？首先捋一捋Sifo的业务和逻辑组成方式，首先在组件层面，通过内置组件或者自己开发的自定义组件完成，在页面层面，通过Schema配置的JSON配置文件进行页面的组织，然后再通过Plugin进行逻辑层面的复用和组织。这样的组成方式完全把视图和逻辑层分离开来了，那么就对我们实现脱离于业务逻辑，进行视图层的页面结构修改，渲染组件的修改，组件内部改造提供了实现的基础。当然我们也可以仅仅对业务源代码进行修改。也就是说，组件，页面，逻辑插件都可以进行灵活的替换和扩展。这点对于B端Sass服务的业务场景来说，是个福音。
在类似的amis中，则没有看到有这样的能力，当需要对框架内的某部分视图或逻辑进行改动的时候，都需要先侵入到原来的页面源代码中去，找到对应的模块，再进行相应的操作。在扩展性上面确实比较受限。
5.应用场景局限
从目前的使用上来说，Sifo的解决方案都比较适用于页面场景相对比较固定的B端业务场景，在C端来说，对于高扩展的能力要求更高，拿我之前在微信实习的经历来说，一个组件可能会用到其他另外三个组件的视图和能力，同时对逻辑的处理还有不同之处，在这种场景下的话，使用这种配置化组织页面的方式，可能就没有在B端使用的那么得心应手了。如果官方开发者有意愿往这个方向去发展下，针对一些复杂场景的高扩展做一些更深层次的优化，那么我相信Sifo的应用和影响都会越来越广。当然这只是我一些片面的认识。
6.技术要求
这一点也是我个人感觉Sifo的一些弱点，amis的话可以提供JDK的方式给非开发者使用，直接配置生成页面，而Sifo则需要一定的前端基础才能上手去使用。是否也可以考虑做一些简化后的版本提供给非前端开发者使用呢？这对Sifo在其他地方的使用也有一些帮助。当然也是因为受众的原因，amis主要是针对配置化生成页面，受众不一定是前端开发者，而Sifo更多的是帮助前端开发者去解决掉开发过程中视图与逻辑耦合，重复性页面效率低，传统开发扩展性低等问题。
三、尾声
其实我个人对Sifo的了解不算特别深，也是处在一个学习和上手使用的阶段，只是在使用过程中有些感想，回想起之前的很多开发场景都可以用这样的能力去快速解决，在这个过程中也跟一些做B端的朋友安利了这款框架，他们在使用的过程中也评测了一下，有朋友跟我反馈说这样的能力完全可以交给后台同学来完成对前端页面的控制，仔细一想确实是这样，后台同学返回一份schema的配置，前端同学来写合适的render以及plugin，确实可以实现服务端配置化页面生成。总而言之，Sifo的能力我看到的只是冰山一角，目前看到的只是low code和高扩展这两个地方，下一步的话我打算在自己的团队中逐步上手使用一下，把之前的一些基建的系统用Sifo重构下，再去尝试一下更深层次的能力，这波啊，这波是切合到具体的业务场景中，具体问题具体分析。这波我在第一层。等团队的使用反馈出来之后，再针对一些原理性和更深层次的能力做一次评测，希望能看到Sifo更多的能力，也是自己学习的一个过程吧。