0%

软件版本的选择 一文中提到过一个原则:通过使用前后端通用的组件来减少组件的总体数量。由于 webpack 等工具的存在,许多原本设计给 Node.JS 使用的库,也能在未经修改的情况下给浏览器使用,乍看之下组件的通用度大幅提高了,但实际用下来,却发现存在着导致编译结果体积膨胀的问题。

因此在实际使用过程中,对库的选择还要进一步审视和辨别,正如该文中所说:

裁剪不能过度的牺牲功能、性能或用户体验。
阅读全文 »

技术背景

下面所列的是本项目中主要用到的技术和工具,以及你需要对它们掌握到什么程度才能顺利的阅读本文。

本文及相关代码在 macOS 下写作,如果你使用其他系统,下面的部分命令可能需要相应调整。

PostGraphile

PostGraphile 可以根据 PostgreSQL 数据库中的内容自动生成 GraphQL 接口。 开发人员设计好数据库中:表的结构、表之间的关系、用户的操作权限, PostGraphile 就能自动将这些关系映射到最终的 GraphQL 接口中。 表中的注释会被用于接口的说明,更有智能注释提供额外功能。 这被开发者称为 DDGD(Database-Driven GraphQL Development),即数据库驱动的 GraphQL 开发。

本文主要就是介绍这个工具,所以目前不要求你对它有所了解。

PostgreSQL

PostGraphile 只支持 PostgreSQL 数据库,并充分利用了它的强大能力。 比如通过行级权限实现细致的访问控制,通过触发器实现订阅等。

本文不要求你使用过 PostgreSQL ,但你必需要有最基本的数据库理论知识。 你可以从 这里下载到 PostgreSQL 的安装包,也可以通过自己熟悉的包管理工具安装它。

GraphQL

GraphQL 是一种用于接口的查询语言,其最大的特点是灵活,数据按需取用。 甚至将原先只能在服务器上通过 SQL 查询实现的联表等能力转移给了客户端。

本文会对它的基本使用进行介绍,想要详细掌握可以考虑阅读 Learning GraphQL 一书。

Node.js 与 Express

PostGraphile 本身使用 Node.js 编写,既可以作为独立的命令行工具使用, 也可以嵌入到 Express 应用中作为大系统的一个组成部分使用。

阅读本文需要你对 Node.js 与它的包管理工具 npm 有基本的了解。

nanographql

一个最轻量的 GraphQL 查询生成器,只负责生成请求 body 的功能,因此可以和各种请求库整合,且不受客户端类型的限制。既可以用在 H5 页面,也可以用在小程序等场合。

你不需要预先对其有所了解。

todomvc/vanilla-es6

本项目的主要目的是说明 PostGraphile 及相关技术的使用方法,为了便于理解,借用大家都熟悉的待办事项作为实例。 因为重点不在前端,所以这里是对现成的 Todo 项目进行改造,来对接 GraphQL 接口。

todomvc 是一个开源项目,用来比较各种前端框架的 Todo 实现,为了覆盖尽可能多的受众,我们采用 vanilla-es6 版本作为本项目演示的基础。

PostGraphile 是一个可以根据数据库结构生成 GraphQL 接口的工具。 它的自动化程度非常高,实现了表结构、关系、限制、访问权限等的自动映射,能有效提高服务端接口的开发效率。尤其是对于不和第三方对接的系统,甚至可以做到直接免除所有后端开发工作。

我在工作中使用了 PostGraphile,并取得了一定的成功,于是希望将这个好东西推荐给大家。 这里,我想通过为一个待办事项服务搭建 GraphQL 接口的过程,来展示如何使用 PostGraphile 。 如果能引起你想试着用一下它的兴趣,我的目的就算达到了。

这里涉及的大多数内容,在 PostGraphile 的官方文档中其实都能找到,毕竟我也是照着官方文档来学习的。 只不过官方文档以功能为出发点,而我是顺着一个假想的项目需求来介绍。

我们将从一个单机版的待办事项应用开始,逐步改造成一个代办事项服务。 首先,我会介绍一个基于浏览器(SPA)的代办事项软件,事项被保存在浏览器中,不需要与服务器交互; 接着,我会把它改造成可以将数据保存在远程数据库中的联机系统,并在此过程中介绍 PostGraphile 的基本功能; 然后,将其从单用户系统扩展成多用户,引入账号和登录的概念,并在此过程中介绍 PostGraphile 的权限管理功能; 最后,进一步完善系统权限,让用户只能访问到自己的代办事项,并在此过程中介绍 PostgreSQL 的行级权限功能。

除了实现上述功能,我还将在整个过程中穿插自己使用时遇到的问题和解决方法,并在最后讨论一下与外部系统交互的解决方案。

严格来讲,PostGraphile 并不是将后端的工作自动消灭了,而是将后端开发过程中与数据库建设之间重复的工作给消灭了。 你需要更严谨的设计和管理数据库才能达到更高的自动化目标,这会迫使你花更多时间在数据库上面,而这些时间都不会白费,因为你会在完成接口服务的同时,得到了一个更健壮的数据库。

Angular、React 和 Vue 的大流行导致现在越来越多的 Web 项目以单页面应用(SPA)的形式进行发布。

在前端文件的缓存方面,由于我早先是使用 PHP + Riot.js 的组合,虽然也是单页面应用,但主入口由 PHP 提供,默认就不缓存,所以只需在 nginx 中将所有静态文件强制缓存到客户端就行。

而换到 Node.js + Vue 之后,主入口换成了 index.html,并且和其他静态文件一起都是通过 express.static 提供给客户端的,所以要针对性处理才能同时满足性能和功能方面的要求。

记得之前有一次搞过头,把 index.html 也缓存了,从而影响到前端的正常更新,最终只能改回默认的缓存规则。为了尽可能加快用户访问速度,又不把事情搞砸,今天终于静下心来对其进行了合理的优化。

阅读全文 »

两年前(2018年),在使用 PostGrahphile 一段时间后,打算总结自己在实践中的经验,于是陆续用数周闲暇时间,写了 《PostGrahphile入门》 一文。止于2019年4月18日,完成了预计的7个章节中的前5部分,今年想要继续时,发现其中多处已跟不上最新的发展,而自己的认识也已更进一步。遂计划重来一版,先将原有部分翻新,再补上缺失的后两章。用每周更新的博客形式呈现,初步估计需要3个月左右。如果顺利,再花2-3周做成完整的电子书,最后定期迭代,使其紧跟技术更迭和个人认识的发展。

阅读全文 »

一套环境通常不会只部署一遍,你会遇到各种需要重复部署环境的情况:也许是一个项目需要多台服务器来运行;也许是同时需要管理多个项目;也许是需要生产环境和开发、测试环境的一致性。总之,掌握高效的方法和工具是非常必要的。

这周我来讲讲自己在服务器环境部署上经历的四个阶段,以及选择背后的原因。

上周讲了服务器系统的选择,这周回来继续讲软件版本的选择,更具体一点来说是服务端运行环境中软件版本的选择。

每个人遇到的情况不同,做出的选择也不同,所以这个问题并没有标准答案,而会是一些方向性的思考。

我的出发点是让尽量少的人来维护尽量多的项目,所以得出的结论可能会和网上常见的文章不同。

就让我学学《程序员修炼之道》先给出一个一般性原则:

Tip
出于减少开发和维护成本的目的,必须减少组件数量,如果组件数量无法减少,就减少它们组合的数量。

这里的组件是一个非常宽泛的概念,既可以指操作系统,也可以指编程语言里面用到的包或库,还可以指数据库、缓存这样独立运行的应用。

这是一个寻找最大公约数的过程。

阅读全文 »

CentOS 8 生命周期的突然缩短,让我再次面对服务器操作系统的选择。

如果你使用一个公司的产品,但不向他付钱,那么你就只是用户,而非客户。网游行业的从业经验又告诉我,不付钱的用户是产品的一部分。

Red Hat 决定将 CentOS 8 的支持周期将从原来预计的 2029 年缩短到 2021 年年底,并劝大家都去用 CentOS Stream,或者买他们家的商业服务,就是一个很好的例证。原来的 CentOS 用户,现在要么选择成为 Red Hat 的编外测试人员,为他们的商业客户提供价值,要么选择成为“氪金玩家”。

商业行为毕竟不是慈善事业,我们没啥好说的,只是又到了做选择的时间。

阅读全文 »

久仰其大名,今年第二版面试,终于买来一本,五百页,断断续续三个月读完。

本书推崇的核心理念被简称“ETC” —— Easier to change ——即软件从设计到编码,首先要考虑“容易变更”,作者云全书其他方法皆是此原则的特例。在我看来其观点与《简约之美》异曲同工,后者写成一本书,只为教给读者一个“常识”,就是软件项目想持续成功,唯一重要的就是“降低维护成本”,至于如何实现,草草带过了,毕竟全书正文不足百页。现在看来,答案自然就是“容易变更”。

这一对比,更凸显《程序员修炼之道》的特点——“务实”。全书给出整整 100 个“提示”,供读者参考。若与读者日常工作方法直接对比,确实能揭示不足,指明提高的方向。其中部分是我日常已有感受,却无法言明的,一旦点破有豁然开朗之感;另有部分是针对一个问题,已经想过几条路可试,却没来得及逐一实践去验证各自优劣的,作者直接给你摊开了一一剖析,读后亦有收获。

当即发愿要按图索骥,查漏补缺。但果真做成待办事项,样样力求完美,估计三年也未必能把勾打满。这时只能说句“进一寸有一寸的欢喜”。

与很多“N 条”、“N 个”开头的文章类似,此书也稍稍有凑数之嫌,最后两章比如测试部分给出的“提示”明显密集了,虽不至于不负责任,但着眼点显然更小了,和前面的不在同一个重量级。

总体而言,此书读一遍,可在心中种下一些理念的种子,遇到合适的场景能时时想起就会有所受益。但要实现其完整价值,必须多看几遍,至少拆开来再细细看一遍,看一部分,就花点时间去项目里实践几个“提示”,吃透了,再往下看一点,循环往复,才算物尽其用。