Directus

Directus APP使用VUE 3， Typescript，用Vite构建。 本文记录在评估Directus APP过程中了解到的前端相关知识。 1. vite 构建工具，类似webpack。 1.1. 原理 使用了浏览器的ES6模块加载功能，所以前端可以按需加载JS模块。开发过程中不需要打包了。 <script type="module" src="./foo.js"></script> 以上 module类型加载的 foo.js 中可以再import其它的模块，也可以export。浏览器认识js中的import和export命令，会按需向后台发请求加载。 1.2. 应用 在vite.config.ts中配置开发服务器，例如下面监听8080端口，API请求发送到8055端口。 server: { port: 8080, proxy: { '^/(?!admin)': { target: process.env.API_URL ? process.env.API_URL : 'http://localhost:8055/', changeOrigin: true, }, }, fs: { allow: [searchForWorkspaceRoot(process.cwd()), '/admin/'], }, }, 2. VUE 把js/css/html组织起来的方式。 运行环境（js库）提供数据绑定，改状态就会更新显示，方便JS更新页面。 2.1. 基本概念 data 一个函数，返回组件实例的数据对象。 props 一个数组，或者对象。是父组件调用此组件时候的可配置参数。 data和props都可以在template中访问，区别是 data不是通过父组件传递的，是子组件私有的，是可读可写的。 props中的数据，都是通过父组件传递给子组件的，是只读的。 data存储组件的状态， 没有data的组件就是无状态组件。 mixin， 为了DRY，为了减少重复，把组建脚本部分相同的地方（data，props,method…)抽离出来，单独放到一个对象里面。 然后在组件中mixin进去。 setup函数， 用来替代mixin，实现Composition API。 其输入为props, context，输出是一个对象。对象的所有属性都可以在组件中访问。 2.2. 组件生命周期 ...

1. Collection 一个Collection对应数据库的一张表。directus的collection里面有一些独有的概念，例如alias域， sort属性等。 1.1. alias Fields that do not map directly to an actual database column are called “alias” fields. For example, presentation fields (such as dividers and groups) and certain relational types that display data stored elsewhere (such as One-to-Many (O2M) and Many-to-Many (M2M)). O2M, M2M, M2A 等，都不会在表里面有实际的列。称其为alias域。 alias虽然在实际数据库表里面没有列，但是在direct_fields表里面有记录。例如上面pages集合的element域，是m2a类型的alias。 direct_collections表里面描述系统所有受directus管理的表，direct_fields里面描述所有表的所有属性。 通过这种非侵入的方式， 数据库中原有的表结构可以不做改动。 1.2. sort 属性 如果collection建立时候，选择了支持sort，表里面就会多一个sort列。 这一列的作用是支持在app上手工拖拽的方式调整记录的顺序。 原理很简单，表里面加了一个number类型的sort列， 当拖拽的时候，会导致该列的值根据记录的位置产生变动。 1.3. share APP的一个功能， 可以把模型中的一个记录生成一个链接，发送给其它人只读访问。 可以设置密码，有效期，以哪一个身份读取等。 ...

1. Docker client通过运行在主机上的docker daemon操作image和container，registry提供image的发布和下载（类似npm和pip）。 Docker 镜像是一个特殊的只读文件系统，提供容器运行时所需的程序、库、资源、配置等文件，还包含一些为运行时准备的配置参数（如匿名卷、环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。 Container是image的运行实例，是运行在宿主机上的一种特殊的进程。一个image可以有多个container。 Container是在Image基础上叠加了一个读写层，在container内部做一些写操作后，可以commit读写层生成新的image 上图省略掉了存储配置文件信息的init层。init层位于上图image和container两层之间。存放运行操作系统时候需要写的一些目录/文件。例如/etc 目录。init层commit时候不提交。 因为没必要，每次只读层运行时候都会自动生成init层内容。 1.1. commands # d d d # d d d d d d d d d d o o o o o o o o o o o o o I c c c C c c c c c c c c c c m k k k o k k k k k k k k k k a e e e n e e e e e e e e e e g r r r t r r r r r r r r r r e a p i r i p r r s r r p c a e u m m n s u u t m m o p t x l a i e n n a r t e l g r - r < $ t l a c e a - - t C ( o c h s < i d O d < c h - e I t < N o C a i l M f c T c O l < t l A c l o A k N _ c o G e a n I e T f o - E n s t N r A i n d w t k a E I l t i o I o - i R c N e a r r D s h n o E _ i e l > e e I n R n n c d l r D t a e t l _ > a I m r u o n i D e s - a n > n - 从 查 删 查 交 w m e a s r 看 除 看 互 o e r 4 m q e 本 某 有 式 r > 删 查 9 e l g 地 个 哪 运 l 除 l 看 f > i i 有 i 些 行 d c s 端 7 t s 哪 m c o 口 9 e t 些 a o 重 n - 映 6 对 r i g n 后 启 t a 射 0 于 / y m e t 台 a q 信 e d b 下 a ， a 运 i ) 息 b o i 载 g 可 i 行 n 7 c n h e 以 n e e k / e 只 e r 4 e s l 写 r 删 : r h l I 除 / o D 所 d r - 的 有 o u 在 w 前 c c n 名 o 几 o k / 字 r 位 n e s 是 l t r t d a _ a d i f r i i n i t r m e l e a r e 启 c g _ 动 t e n 的 u a 容 s m 器 - e ， s 可 q 以 l 拷 用 i 贝 这 t 文 个 e 件 来 的 到 a 容 d t 器 o t 内 c a 执 k c 行 e h s r 到 h 里 控 面 制 台 上 看 输 出 。 1.2. Dockerfile 是用来build image的配置文件，从一个基础image开始，运行一些列配置命令，得到另外一个image ...

1. 起因 在配置Directus使用钉钉扫码登录时候，发现钉钉的免密登录（OAuth 2）和RFC规范不一致。 需要做协议转换后才能和Directus正常通信。 需求比较小众，没有现成的软件，只好自己动手了。 2. 主要功能 能作为API通信的中间人， 转发客户端和API服务器之间的通信， 记录LOG，方便分析协议； 作为中间人，能修改请求的内容， 修改响应的内容；可以做协议适配，转换。 APIPROXY is a RESTFUL API proxy, monitor and adaptor. Forward RESTFUL API to another host. It’s man in the middle who can monitor and modify the header and body of the API Request & Response. Good for protocol study and adaptation. Features API proxy: forward any incoming API to remote sever and return the response back to client. API monitor: you can get detailed log of the API req and res in the log file. API adpator: modify the request and response on the fly while forwarding, including parameters, body, http headers etc. API mock server: you can add your own API for testing purpose easily. 3. 目前状态 初步实现了对钉钉OAuth2协议的RFC6749兼容封装。 目前Directus已经可以通过它的翻译支持钉钉免密登录。 ...

Directus本身是NodeJS实现的API服务器。 其能支持多大的TPS取决于数据库系统，API查询设计等多个因素。本文提供一些架构上的考虑，目的是使得Directus应用能随着业务的增长，通过增加硬件等方式，同步提高系统处理能力，在性能上具有好的扩展性。 1. 如何规划可扩展的Directus应用 Directus 对于高负载情况的处理有以下两个关注点： 横向扩展应用服务器（directus实例多部署几个） 数据库服务器采用高性能方案，例如Amazon Aurora或者CockroachDB Rijk van Zanten: That being said, I do highly recommend horizontally scaling your Directus instance if you’re planning on running it at scale. Make sure you use Redis for caches / rate limiter, and S3 or another shared file storage for the file storage. At that point, the bottleneck will become the amount of allowed connections and the overall server performance of the database. That being said, there’s a lot of database services nowadays that scale virtually endless, like Amazon Aurora or CockroachDB. ...

1. 项目简介 这个小项目预期结果是让 Directus 支持使用钉钉账号来登录。 在了解OAuth2协议后(参见上一篇blog，参考资料1），已经有足够知识储备来实施。 Directus 原生支持使用GitHub登录， 所以，解决思路是先从GitHub入手。按下面步骤进行： 配置Directus使用GitHub账号登录，熟悉Directus对OAuth的标准支持功能 配置Directus使用钉钉账号登录，由于钉钉的协议实现和RFC6749/GitHub有不同，这里有可能需要见招拆招 上线Directus到服务器环境，在钉钉的PC版和手机版验证 2. 环境配置 在本地用ngrok暴漏出一个服务，来接受OAuth服务器的redirect。 ngrok http 8055 得到 https://445a-240e-47c-30b0-3b10-600e-ea25-cde5-2334.ngrok.io/ 作为外网域名来访问本机8055端口的directus。 3. Directus 使用 GitHub账号登录 按参考资料2中配置参数。以下配置中，对每一个新的GitHub授权用户，Directus在登录过程中会使用用户email自动创建一个Directus用户，并且将其角色赋值为AUTH_GITHUB_DEFAULT_ROLE_ID。 A A A A A A A A A A # # U U U U U U U U U U T T T T T T T T T T A A H H H H H H H H H H U U _ _ _ _ _ _ _ _ _ _ T T P G G G G G G G G G H H R I I I I I I I I I _ _ O T T T T T T T T T G G V H H H H H H H H H I I I U U U U U U U U U T T D B B B B B B B B B H H E _ _ _ _ _ _ _ _ _ U U R D C C A A P A D I B B S R L L U C R L E C _ _ = I I I T C O L F O E I " V E E H E F O A N M D g E N N O S I W U = A E i R T T R S L _ L " I N t = _ _ I _ E P T g L T h " I S Z U _ U _ i _ I u o D E E R U B R t K F b a = C _ L R L O h E I " u " R U = L I L u Y E t 7 E R " = C E b = R h e T L h " _ _ " " _ 2 . = = t h R I e K " . " " t t E D m E . d h p t G = a Y . 5 t s p I " i = a . t : s S 0 l " e . p / : T f " e " . s / / R 5 m . : g / A f a . i a T 1 i . t p I b l . g h i O 5 " d i u . N a 9 t b g = - " h . i " 1 u c t t 0 b o h r 6 . m u u f c b e - l . " 4 m c e g o c l i m 7 o n - g u a i o s 8 n a e b / u r 8 o t " - a h 6 u / f t a 1 h c 1 / c 4 a e 8 u s 2 t s a h _ 0 o t 6 r o 0 i k f z e " e n " " 重启Directus让配置生效后，可以看到登录界面的GitHub选项。 ...

1. 引言 开源软件已是信息社会的基石。 GitHub上软件种类众多，市场定位和成熟度也各不相同。 对于成熟的通用软件，例如Linux，NGINX等。将这类软件引入自研项目中不存在太多顾虑，因为通用所以用的人多。可以找到大量的成功案例，众多的开发维护人员。一旦碰到问题，也容易在网上搜到答案。 但还有一类开源软件， 定位相对没有那么通用，虽然其在细分领域已经做的比较好了，但由于生态环境较小，在项目中引入时候，还是有很多因素需要考虑： 现有的开发人员有能力掌握并承接后续开发吗？ 如果使用中出现问题， 有没有合适的开发人员去解决？或者去做二次开发？ 系统上线后，有没有合适的人员去长期维护？ 对这类软件，在引入到项目中前，有两种办法增强信心： 找到合适的人 成为该软件开源社区的一员 2. 找到专家 有如下几个方法。 在软件的开发者中搜索是否有中国开发者，尝试建立联系。 百度该软件相关的讨论区，QQ群等。 加入并倾听，识别出专家。 寻找并参加该软件相关的培训。 寻找GitHub上该软件的相关软件。 例如引用该软件的软件，该软件的Plugin等等。并合作者建立联系。 以上的目的都是在现实世界建立起和专家的联系。 然后通过和专家的电话，邮件，吃饭喝茶等各种交流来进一步了解该软件在国内的生态情况，以及软件的优缺点。 为后续引入打好基础。 和专家建立起联系后， 后续也方便和专家进一步在项目上合作共赢。 3. 融入开源社区 如果国内找不到专家。 就只能撸胳膊上，让自己成为专家了。 3.1. 学习使用 主要看如下几方面的内容： 软件自身的官方文档 Youtube上的介绍视频，以及第三方教程 软件的单元测试 以上，结合大粒度的源码分析，可以掌握软件的大体脉络。 3.2. 和同行讨论 一般开源软件社区有如下几个地方。 GitHub项目Issues GitHub项目Discussions Discord或者Slack等讨论组 Email邮件组 通过加入并查看大家在讨论哪些问题，能了解到软件的一些使用细节和适用场景。 在学习的同时，也要多思考，多提问题， 多回答社区的问题。 回答社区的问题可以针对和自己项目相关的领域问题，积极回答问题有两点好处： 驱动自己认真深入思考，如果我在项目中碰到这个问题，该怎么处理？ 和其它社区用户，以及软件开发维护者们建立联系 以上是 Headless CMS Directus 的项目讨论社区。 我最近在调研用Directus来做API中间件，watch了该项目的讨论区，GitHub会把所有讨论实时发到我一个特定的邮箱里面。 通过查看大家的讨论，有很多收获。我也把自己学到的经验总结提炼出来帮助其它用户， “Most Helpful”榜单排名第5的就是我。 3.3. 小规模MVP验证 在看的基础上，也需要动手做。 按照自己项目的特点，定义一个和该软件相关的最小MVP流程，尝试引入该开源软件实现。 以上三点，相辅相成，可以同步进行。 理想的结果是： 自己变成了专家，后续在项目中引入 研究过程中发现软件不适用，果断放弃