MoreRSS

site iconJust lepture修改

Hsiaoming Yang,typlog 和 authlib 的创建者
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

Just lepture的 RSS 预览

开发 Prosefly

2026-10-11 08:00:00

我已经做了一个博客和播客托管平台 Typlog,最近又做起了 Prosefly。它可以管理 GitHub 仓库里的文档和文章,提供一个可视化编辑器,写完后保存的仍是 Markdown、MDX 文件。

为什么又做一个

既然已经有了 Typlog,为何又要做一个 Prosefly 呢?

我以为现在是做静态网站的好时候。有了 AI,做一个网站容易多了,自己设计一个主题亦不再那么麻烦。文章保存成 Markdown、MDX 文件,和网站代码放在一起,AI 便可以直接读取、修改,改文章时也可以顺便改一下页面。

不过,文章保存在哪里是一回事,怎样写文章又是另一回事。我仍然想要一个好用的写作后台。调整格式、插入图片,总不想每次都去修改源码。静态网站的自由我想要,写作时的方便亦不想舍弃,于是便有了 Prosefly。

还有一个缘由,是文章的 frontmatter。在 Typlog 里,这些字段都是我预先定义好的,用户不方便改。假使想写书评,需要加上作者和评分,便要看平台有没有提供这些字段了。网站可以按自己的想法改,文章的字段却不能随意定义,多少有些不便。

Prosefly 的做法是直接读取项目中用文本定义的 frontmatter schema,再生成相应的编辑界面。需要什么字段,便在 schema 里添加什么字段。这样我做一个新模板时,也不必先想平台支不支持了。

开发顺序

最先做的是可视化编辑器,这一部分花了很久。当时还没有开始写完整的平台,只想着先把编辑器做好:写作时可以方便地调整格式,保存下来又是 Markdown、MDX 文件。说起来简单,做起来却颇费时间。

Prosefly 的可视化编辑器

等编辑器接近完成,才开始做 Prosefly。不过亦没有立刻写 Web 应用,而是先创建了 GitHub 组织,做了几个 Astro 主题和模板,然后才开始开发平台。

先做模板,是想看看实际的网站里,文章应该怎样组织,frontmatter 应该怎样定义,编辑器又该如何配合。只对着编辑器想,总不如拿一个网站来试试。于是等到开始写平台时,已经有了可以编辑的内容,也有了使用这些内容的网站。

犯过的错

Prosefly 是用 Cloudflare Workers 写的,需要按组织拆分数据库,让各个组织的数据互不混杂。我最初选了 Workers for Platforms,它可以部署和运行用户的 Worker 代码,用来做数据隔离亦是可以的。

可是项目越写越复杂。编辑器已经花了许多时间,模板也做了几个,到了平台这一层,却越做越麻烦,一度想就此放弃。原本只是想把各个组织的数据分开,结果还要部署和管理不同的 Worker,平白多出许多事来。

后来才发现,Durable Objects 便可以做我需要的事。每个组织的数据放在各自的 Durable Object 里,应用仍是同一个应用,也不必为此部署和管理不同的 Worker。换了方案后,平台简单了许多,才又有心思继续做下去。

现在想来,完全是自己想复杂了,倒险些把项目也一并放弃了。

Building Prosefly

2026-10-11 08:00:00

I run Typlog, a hosting platform for blogs and podcasts. Recently, I started a new project, Prosefly. It lets you manage documents and articles in a GitHub repository and write with a visual editor.

Why build another one?

I had already built Typlog. Why start Prosefly too? This is a golden age for static websites: AI has made them much easier to build. When content lives in Markdown and MDX files alongside the website’s code, AI can read and edit it directly, and work on articles and pages together.

Storing data in files and writing articles are two separate things, though. I still want a friendly visual editor. Formatting and inserting images feel more comfortable there, so I don’t have to edit source every time.

AI has also made it easier to build your own theme. You can change the website to suit your ideas and define its frontmatter fields along with it. For a book review, for example, you could add an author and a rating to the schema.

In Typlog, those fields are predefined by me and are not easy for users to change. Prosefly reads the frontmatter schema defined in the project’s text files and generates the editing interface from it. When making a new template, I don’t have to start by checking whether the platform supports the fields I want.

Development order

I spent a long time designing the visual editor before starting the complete platform. Most of my attention was on the editor: the files would be Markdown and MDX, but I wanted a visual writing experience. I wanted that part to be mostly ready first.

Visual Editor by Prosefly

Once the editor was close to complete, I started working on Prosefly. Even then, I did not jump straight into the web app. I created a GitHub organization, made several Astro themes and templates, and then started building the Prosefly platform.

Working on templates first gave me actual websites in which to organize content, define frontmatter, and see how the editor fit. By the time I started the platform, I already had content to edit and websites that used it.

A mistake I made

I’m building Prosefly with Cloudflare Workers and need to isolate each organization’s data. I initially chose Workers for Platforms. It can deploy and run users’ Worker code, and it can provide that data separation too.

The project became much more complicated. I had already spent a lot of time on the editor and made several templates, but building the platform kept getting harder. At one point, I considered giving up.

Later, I realized that Durable Objects could handle the data separation I needed. Each organization’s data could live in its own Durable Object. It would still be one application, without deploying and managing separate Workers for that purpose. Switching to this approach made the platform much simpler, and I kept going.