我一直盯着自己的作品集架构,慢慢意识到它已经变得多么零散。目前humfurie.org和humphrey.humfurie.org跑着完全独立的后端,老实说,看起来挺乱的。
事情是这样的:我一开始是用Laravel单体架构(上面叠了Inertia + React),这对快速上线来说非常合适。后来我把humfurie.org做成了一个Next.js项目,用了另一种我还在逐渐建立信心的语言写的完全不同的后端。两个前端都是React,这在一致性上是好事,但它们背后驱动的技术栈完全不同。Laravel那边是紧密耦合成一个整体的,所以我没法轻松地只把前端层单独拆出来。
于是我在想:如果我不再假装它们是两种独立的体验,而是把它们统一到一个域名下面呢?让所有流量都经过humfurie.org,然后用humfurie.org/humphrey来提供Laravel的作品集部分。所有东西都在同一个屋檐下。
为什么这个方案吸引我
从品牌角度来看,单一域名感觉更干净。它传达的是"这一切都是我做的",而不是"这些是散落各处的项目"。它也让访客的理解方式更简单:他们先看到我的主要作品(humfurie.org),然后看到一个专门展示我Laravel后端技能的板块。作为一个靠Laravel建立职业生涯的人,这似乎值得明确地凸显出来。
而且,我已经在跑Traefik了,所以反向代理这部分不是难点。真正的问题是,这份复杂度是否真的值得。
但让我犹豫的地方
让我不确定的技术部分是路由。Traefik绝对可以根据路径把请求路由到不同的后端。但应用层需不需要知道这层路由的存在?如果Laravel在提供静态资源(CSS、JS),那些路径大概率是相对于根路径硬编码的。突然把它放到/humphrey下面,可能会让一切都崩掉。用Next.js构建的React前端也有自己的客户端路由,而它默认自己拥有整个域名的路由逻辑。
然后还有身份验证和状态的问题。这些应用是共享会话,还是彼此隔离的?如果我把/humphrey/*路由到一个完全独立的Laravel实例,它们会给人一种统一连贯的体验,还是像两个应用被生硬地塞在一起?
更大的架构问题
我也在琢磨这到底是不是正确的决定。多个域名确实在SEO上更分散,没错,但它们同时也表明这些是各自独立的项目。统一到一个域名下,可能会让作品集显得更连贯,也可能只是让人困惑:"等等,为什么这个Laravel管理面板会嵌套在humfurie.org底下?"
另一方面,统一的域名正是真正的SaaS平台会采用的做法。如果我能把这件事做得顺畅,就说明我理解如何在不制造技术债的前提下,架构域名级别的路由。
当作一次实验来看
我老实说也不确定这值不值得做,但探索一下挺有意思的。我实际上能学到什么?怎么在不破坏客户端导航的前提下,处理基于前缀的应用路由。怎么让两个完全不同的后端感觉像是同一个系统的一部分。整合的这番功夫,是否值得换来那份更干净的外观。
这一切底下真正的问题是,我的作品集应该讲一个故事,还是讲多个故事。一个域名说的是"我构建了这个连贯的东西"。多个域名说的是"我可以独立构建多个东西"。两者都是真的。
我倾向于去尝试一下,主要是想看看这是否可能在不让两个应用都变得维护地狱的前提下实现。但我更想先把这些取舍好好想清楚。