有一点值得考虑的是：对于微服务架构来说，在一个系统的不同部分使用不同的技术栈是一种不错的体验；而对于一个前端团队来说，在同一个系统中使用不同的技术栈就不是一种不错的体验。

　　API设计——应该变得简单

　　如我们所见的Spring Boot已经变成推荐采用的程度了，atv，按雷达上的习惯用语：“我们已经在多个项目上使用这个框架”——反正我最近的项目都是用这个框架。如果你考虑使用 Java，那么一定不要错过这个框架，以及使用这个框架来实施前后端分享。

　　对于大部分不需要考虑SEO的应用来说，将后台变成一系列RESTful的API并不是一件复杂的事，但是在后台API上的设计就变成一件麻烦的事。因此尽管在实践的过程中有契约作为保证，但是不一定是可靠的。作为一个前端程序来说，我们在调用后台API的过程中，总会遇到这样、那样的问题。除此，还有接口不好用的问题——“要是你可以在这里使用超媒体API，那么我的代码就会更加简单了”。

　　因此在 API 设计上，雷达上给出了两个不错的案例：

　　强化后台查询

　　代表例子就是Facebook的GraphQL，它是在Facebook内部应用多年的一套数据查询语言和 runtime。原本为了请求一个用户及其好友信息，需要发起多个API请求。现在，我们只需要在客户端拼装好对应的Query语句，在这个语句里将大部分需要查询的东西写好，即 JSON格式的数据，开奖，然后发给服务端来处理。而在我们客户端上，我们所获取到的结果都是我们所需要的，不需要再做特殊处理了。

　　这一切，看上去很美好——除了，在客户端上拼查询语句。

　　过去，我们使用搜索引擎来搜索数据，就需要在前端拼好对应的Query，再传给后台API，由后台API返回我们需要的结果。在这个过程里，我们在Query做一些对应的数据处理。

　　反正，他们都是使用查询语言来搜索结果。如果你考虑使用QL的话，不妨做一层Wrapper，以后好做迁移。

　　前后端同时优化

　　Netflix在这样复杂的API请求下，创建了自己的库Falcor——它可以从多个数据源获取数据，并在服务端上汇总成一个JSON model；在客户端上，请求时我们只需要加上对应的参数即可——可以将多个请求合并到一起，也可以只针对某一个部分发出请求。这样可以降低发出多个请求所带来的复杂度。

　　我想，一种最实用的做法：就是将一些更新频率较低的API合并成一个大的API(大部分人都会这样做吧)。

　　简化的后台——无服务器架构

　　除了上面的这些内容，后台还有一些东西蛮好玩的，其中一个就是Serverless架构，即无服务器架构。不过，这种架构目前在国内运行起来还是有点难度的，缺少一系列的配套措施。如在这期的雷达上，Auth0可以为我们提供一个授权服务，以及AWS Lambda可以直接使用 AWS系列云服务来对数据进行处理。

　　关于这期技术雷达我就不多说了，读者可以自己去看。点击原文就可以获取最新一期ThoughtWorks技术雷达。

　　那么未来，你想玩哪种技术。