JSONSpec: AST as a Service

原文发表于 2015-07-27,我的lofter:http://kimleo.lofter.com/post/46977_7c0165f

今晚刚刚设置好自己的Medium账户,然后就看到了这篇文章(原链接已失效),遂想起来之前关于Workflow的想法,以及一直在纠结究竟要不要提出的概念:AST as a Service。

当然,Adolfo Rodriguez关于Relevant的这篇文章,仍然更像是把JSON作为描述Workflow的语言(参见其GitHub Repo),而且依据我们之前的论述,一个语言只要满足Repeating、Branching和Reference就能够完成大多数任务了。

然而问题究竟在哪儿呢?

首先是关于是否有必要在请求的结果中描述逻辑的问题。

比如:

"foo":true, 

"cities":["Montreal","Toronto"], 

"city": {
    "_IF":"{foo}",
    "_THEN":{
        "city":{"_PATH":["cities",0]},
        "_RETURN":"{city}"
    },
    "_ELSE":{"_PATH":["cities",1]}
}

大致相当于下面的JS代码:

var foo=true, cities = ["Montreal", "Toronto"], city;

if(foo) {
    city = cities[0];
} else {
    city = cities[1];
}

但是,当这段代码逻辑出现的时候,其实就可以直接对其进行求值然后变成:

{
    "city": "Montreal"
}

简直节省了大量的带宽和客户端的业务量。

当然,也有一个理由让客户端知道如何处理这样的业务逻辑。比如,要求Dynamic或者是Reactive时,客户端就可以直接对当前获得到的业务逻辑,自己就能进行处理了。

那么问题来了,究竟什么时候去更新这套业务逻辑,或者是数据呢?

所以,这仍然是一个问题。

其次,是语言设计的粒度。

抛开可用性不谈,我觉得实际上并不需要精确地描述出每一个Math甚至是Date以及相关的东西。其实只要能够表述出不同的state、view和transition就足够了。因为这才是“Business Process”,而具体的数据交互和展现交给state和view来搞定就好。

另外,关于AST as a Service,是一个不错的发展趋势。只要开发者利用自己熟悉的工具生成具有统一规范的JSON数据(AST),就可以作为一个后台服务或者一项特殊的任务(task)——比如批量处理大规模的数据——来运行。(嗯,听起来还是像BaaS的做法),于是,在部署的时候更多的只要考虑这个AST的Interpreter如何实际规划就好。

当然,这个Common AST也并不一定真的就是一个树状结构,比如JavaScript。

=============================

结论:Workflow大法好!