ArcBlock 北京黑客松，你来不来？

正文

请到「今天看啥」查看全文

API 服务的最大问题是不够直观，因而我们围绕着 OCAP API 提供了前端的 playground，方便大家实验和探索；当你在探索的过程中有了些许灵感，迫不及待想要做点什么的时候，我们提供了 javascript / nodejs / iOS / android 的 SDK，方便大家将灵感快速 MVP 化 —— 甚至，我们还贴心地为前端的同学提供了 react / vue 的 starter projects，一键带你飞上云端。下面是我们两周前在 Bellevue 举办的 hackathon 的一个作品，直接基于我们的 react starter project 和我们提供的 GraphQL subscription 功能：

讲到这里，我相信有些同学会问，为什么我们要采用 GraphQL 作为 API layer？

GraphQL 自 facebook 在 2016 年推出以来，并未大红大紫，究其原因，还是后端实现起来有些复杂，和工程师已有的知识体系（以及运维体系）有所冲突。我在两年前的文章： GraphQL，你准备好了么 有过一些分析。ArcBlock 之所以采用 GraphQL，是因为我们觉得它的思想 —— 减轻客户端的学习成本和使用成本，很契合 ArcBlock 的让 blockchain app 开发变得简单便利的使命。我们不但在 OCAP API 上采用 GraphQL，我们几乎 all in GraphQL —— 所有对外（或者未来可能对外）的 API，我们都采用 GraphQL。为此，我们打造了一套叫 Goldorin 的工具（尚未开源），来减轻 GraphQL 的开发难度。工程师只需要撰写 yaml 格式的 API 描述文档，Goldorin 会生成 Absinthe，Ecto 等相关的代码，最后工程师只需要在生成的 resolver 里面做完形填空，填写如何 resolve 各个 field 的函数即可。通过 Goldorin，GraphQL notation / schema 等一系列繁琐的事情都被工具完成，开发的难度被大大降低。不仅如此，最近我们还在思考：如何构建一个内部的服务，让前端的同学只需要提交 yaml，描述好她希望使用的 API，后端自动生成并部署 stub API，提供 理性 的 stub data，供前端调用。这样，前端就不需要巴巴等着后端提供支持，才能完成下一步的工作。

请到「今天看啥」查看全文