awesome-go 里找
awesome-go 本身就不错，收集、整理 go 库
语言只是语言，还得选择方向，不是所有程序员都做 web

搜索：
scala：没有官网
APL：没有相关的
donald：2 条结果，没有主页
taocp：没有结果
这个是 UI 的 beta，后台 mock 数据？

@Desiree 一个页面一个特定的接口？
对前端来说肯定是最美好的世界，但后端怎么办？一个页面很多都会包含来自多个模块、服务、系统的数据，后端怎么办？前端增减页面、页面中的数据，后端一起改？
由前端决定还是前后端协商决定，这个数据确实会不同啊，前端肯定想着一个 API 拿到所有格式化好的数据，后端肯定想拿到砍人啊

个人使用 GraphQL 的主要原因是强类型。
React + TypeScript 下用 introspection 出来的 schema 和 gql tag 里的查询语句预编译生成 react 的 hook，保证编译能过。
服务端用 apollo 的 gateway 做 federation， 组合多个 GraphQL 的后端，几个后端的协调一下命名等，相互间访问和隔离问题都不大。
GraphQL 用来提供 “one api”，跟 SQL 什么的都没什么关系，GraphQL 也不是 SQL 的有效抽象。
用什么数据库也无所谓，反正都在 resolver 里解决。
高度动态确实不太好，直接变成 AnyQL，类型意义全没了。
分页用 Relay 定义，支持 cursor 或 offset，实现起来比较麻烦，但客户端上好用点。

在返回要求 Optional 的函数里返回 null 的程序员是不是应该开除？

主业就是这方面的东西，说实话公司从 0 做起难度太大，意义也不大，除非是要做这个行业了。
1. 搞定这几百台各种各样设备的数据采集：各种 PLC 、Modbus 、OPC-UA 、哑设备？
2. 考虑网络连接等：以太网、无线、EtherCat 、Ethernet/IP ？
2. 打通企业现有的信息化系统、MES 、ERP ？
2. 理解数据，建立模型：谁来建模、谁来分析？
2. 考虑系统给谁用的，结果是给谁看的：老板、主管、技术人员 ？