出于我无法满意的好奇心,我乃至想在Markdown中嵌入一个低代码渠道。用户只需求编写简略的文章就能完成一些体系规划任务。

首要我先假定现代Markdown编辑器的特色:

  • 首要,它基于云存储和同享

  • 除了文章外,相关资源也需求在线存储

  • 它可以运用人工智能来撰写和微调特定段落以包括特定细节

  • 用户应可以规划自己的数据和表单,以在文章内搜集必要的信息

  • 它需求跨渠道支撑, 它可以嵌入就任何其他Web体系中

  • 它应支撑协作式多用户编辑

  • 它可以运用各种MDX组件,便利未来扩展

在持续下一部分内容之前,让咱们来观看一段完成品的视频

【AI + Markdown = Amarkdown】 www.bilibili.com/video/BV1wu…

咱们接下来应该做什么?

首要,接下来的进程是技术选型

我想澄清,在我完全开发出这款编辑器之后,才撰写了这篇文章。接下来的许多规划决议计划都是经过绵长而弯曲的进程得出的,一开始并没有如此清晰的愿景。


为了保证以Markdown编写的文章最终可以在线出现,它们的内容应该由Web进行烘托

毫无疑问,我应该挑选React。尽管我更倾向于新式的SolidJS,但咱们开始的愿景是在未来集成更多MDX组件。因此,我应该挑选更大的React生态体系。

Frontend choice: React


关于桌面客户端容器,也有许多选项:Electron、Tauri、PWA装置方位应用程序。 我测验比较了这些选项,并决议首要排除PWA,因为假如我需求在将来为客户端增加杂乱的本地服务以取得更强壮的功用,它会对我形成限制。至于Tauri,它代表了未来,但整个东西链没有成熟,并且我更喜爱编写Node.js服务,而不是Rust

Desktop container choice: Electron.


关于后端服务,我有两个选项:Node.js和Golang,这让我陷入了长时间的窘境。因为我在前端运用TypeScript,挑选Node.js会让我可以有效地运用trpc和Zod进行类型约束,并在前端和后端重用验证函数,从而取得良好的开发体会。但是,这会将我与JavaScript生态体系联系在一起。 另一方面,Golang供给了较低的内存开支,与Node.js相似的并发能力以及更低的无服务器本钱。经过深思熟虑,我决议开发自己的脚手架,将前端恳求层的代码生成与Golang后端接口结合起来。这供给了相似于trpc的开发体会,并为将来扩展就任何后端语言供给了潜力.

Backend choice: Golang.


因为用户数据存储在云中,数据库的挑选至关重要。你有几个挑选:MySQL、Postgres、MongoDB,包括它们的云产品,如阿里云或腾讯云的数据库, 咱们可以挑选任何云产品;在这里,咱们只讨论数据库的类型。 因为这个项目的目标超出了简略的用户文本存储,我计划整合一个低代码渠道。因此,我期望数据库可以兼容无形式(No schema)办法。 我无法防止运用关系型数据,比方用户装备、OpenAI令牌运用、文章基础目录以及一些需求强壮业务支撑的付款功用,这要求一个稳健的关系型数据库。但是,我还需求允许用户规划自己的表结构,相似于MongoDB存储用户规划的表,运用户可以自在规划字段。 我信任详细细节应该在未来的另一篇文章中详细论述。目前,我将总结我的定论。

Database choice: Postgres + JSONB


因为需求协助用户办理Markdown中提到的资源,咱们需求一个目标存储解决方案。

Object storage choice: 阿里云 OSS


为了显著削减数据库读取开支,必须用一个键值内存数据库来弥补体系,而在这种情况下,咱们挑选了Redis。经过计算,我信任在用户基数经历爆炸性增长之前,一个单独的专用Redis实例应该完全足够。

Cache database choice: Redis


与Redis比较,恳求和CDN层的缓存的确可以更高效。它可以协助削减数百万次的重复恳求。 CDN被分布在全球各地的邻近节点上。

比CDN还要更高效的缓存是用户自己的设备。因为用户可能有大量文章,不适合运用本地存储进行存储;咱们需求运用indexedDB。

经过运用indexedDB -> CDN -> Redis -> Postgres作为这些缓存层,咱们可以将Postgres上的开支显著降低到一个十分低的水平。

Request caching choice: IndexedDB + CDN


我期望用户可以运用人工智能来优化文章的细节,因此挑选一个AI产品是至关重要的。 在这方面,毫无疑问,OpenAI的GPT-3.5是体会最简略且最佳的挑选。GPT-4.0的本钱太高,使得用户难以负担得起。

现在GPT-3.5现已支撑微调,咱们可以以十分低的开发本钱完成出色的作用。

AI choice: OpenAI’s GPT-3.5.


工作正在逐渐变得更加杂乱,测验技术的挑选的确至关重要。

我需求在测验方面做一些决议计划。单元测验应该包括哪些范畴?前后端测验应该怎么进行?我在这个范畴有一些经验,乃至开发了一个小型的开源自动化测验渠道:github.com/ymzuiku/tes…

关于后端单元测验,我正在运用Golang内置的测验库。但是,因为我触摸过JS生态体系中的交互式测验办法,比方Vitest和Jest,我对这种办法产生了喜爱之情。我喜爱可以在终端中专注于特定的测验,在所有测验之间快速迭代,并且我开发了一个小型的CLI东西,它在Go内置的测验东西之上包装了一些简略的终端指令,完成了相似Jest的开发体会:github.com/ymzuiku/goj…

关于前端测验,我正在运用Vitest进行单元测验,关于端到端测验,我正在运用Cypress。

Testing choices: Go test + Vitest + Cypress


关于程序部署和持续集成/持续交付(CI/CD),有许多挑选可供挑选。在我的场景中,GitHub Actions现已完全足够,并且作为免费选项,它也是一种本钱效益较高的挑选。

CI/CD choice: GitHub Actions

下一篇文章行将到来 (假如有人点赞的话)

上述列表包括了项目中运用的许多技术。在接下来的文章中,我将测验逐渐描述我是怎么开发这个项目的,为上面提到的技术栈供给实际的见地