当我起这个标题时，其实我已经很久没更新（翻看）过笔记了，甚至我都不记得我的博客还有笔记这个东西。

当我翻阅 git 记录，寻找上一次在笔记文件夹的 commit 提交记录，还是在去年的 10 月 1 号。

![image_U0EDw0PkAf1](https://img.kuizuo.cn/image_U0EDw0PkAf1.png)

然而并不是我的技术栈没更新，而是我实实在在没去为这些技术栈编写过笔记。仅有的只是博文来记录自己所用的过程。

因此我想思考下我为何不记录笔记。



## 笔记的意义

首先不妨回答一下我所认为的笔记意义。

### 检索高效

当我需要回忆我曾经学习过的某个知识点时，笔记可以说是最直接有效的办法。与其再次使用搜索引擎搜寻答案，不妨直接从答案中找答案。

> 正如我笔记简介所述：**做到即查即用，能复制粘贴解决的，就绝不百度。**

### 巩固理解

相比绝大多数笔记内容都是初学者去记录自己所学，在这个阶段，你对知识的掌握程度是比较浅显的，而笔记无非能加快你的理解，同时也是是成本最低的，翻看自己的内容远比理解他人的内容来的简单。

## 学习方式

很多初学者除了通过视频教程来学习，当然不乏有些人是通过别人的学习经验（即笔记）来进行学习，包括我一开始也是通过刷别人的笔记来学习某个知识。

不过相对于视频而言，视频通常很啰嗦且时长感人（动辄可能数天的时长）。很多人不喜欢铺垫，不喜欢废话，就想知道某个知识点怎么用，结果如何。同时视频没有搜索功能，如果视频创作者没有对视频进行分集，当你需要回看的时候时，你往往需要从数十分钟的视频中不断的拖动，甚至到最后才发现原来我看的不是这个视频。

而文档则不会，那你可以通过 Ctrl + F 搜索你想要的关键字，相比视频而言，检索的效率将会大大提升。

这也是我为何从视频学习转成文档学习很重要的原因。我也很推荐如今的学习者从文档学习，而不是视频学习。

## 为何不写笔记

### 笔记应该记录哪些知识点？

笔记无疑是耗时的，你可能会花费数个小时的时间，去总结一个可能你职业生涯中都用不到几次的知识。

为什么这么说，因为我发现我有很多笔记就是这种情况，你也可以回想一下你所记录的笔记，有多少是经常使用到的。

尤其是当你使用的足够多的情况下，你甚至都无需翻阅笔记。脑海中自然就会复现出你需要的东西，此时为何还需要看笔记。为了验证脑海中的正确性吗？

想想看你会为怎样的知识点大费周章的记录，是一个自己都不怎么用的知识点，还是用到滚瓜烂熟的知识点？

当我们经常使用某些知识点时，自然而然就会记住它们，这时笔记就没有太大的意义了；而对于使用频率较低的知识点，记录下来的意义也不是很大。

### 搜索大于记录

究其原因，还是因为我翻看笔记的频率变少了许多。如今的搜索引擎很智能，只要你用的不是百度，就能很快速的搜寻到答案，为何还需要记录一下，换成自己熟悉的口吻，到最后就变成上面所说的那样。而在 ChatGPT ，new bing 的诞生下，更加剧了我这一行为。

**当搜索大于记录时，笔记就显得弱不禁风。**

### 官方文档与学习笔记

说实话，当你看到别人的笔记的时候，你会认真的从头到尾看一遍吗？我想不会，更多情况我们只利用搜索功能去获取我们想要的知识点。

但如果此时有两份文档，一份是官方的技术文档，一份是他人的学习笔记文档。你会选择哪一份？是我肯定毫不犹豫的选择前者，他人的学习笔记并不会及时更新，但官方文档只要还在维护，那么必定处于常更新的状态。假设我照着他人的学习笔记学习，此时正好有个函数的使用方法更新了，那么我必定会踩坑，导致不必要的 bug。而官方文档则不会，官方一旦有破坏性更新，通常会有显眼的提示，和 changelog 可供我参考，这就能及时有效的帮我排除不必要的坑。

这也是我为什么会宁愿去看官方文档，哪怕是英文的，也绝不愿去看第三方中文翻译后的文档，我有太多的坑就是因为更新不及时，存在信息差导致的。所以无论如何，能获取一手的信息，就别用二手的，甚至你也不知道人家会加工成什么样子。

## 最后

综上，我想我已经把我为何不写笔记的原因讲述的比较清楚了。

当然我并不是说笔记就一无是处，因为每个人，每个阶段的学习方式不同。曾经我也是笔记学习的追崇者，但如今的我能够不借助视频教程，不借助笔记来进行独立学习，所以为何不选择一个对我而言更高效的方式。

距离我上篇笔记还是在?

Typescript 全栈最值得学习的技术栈 TRPC

对于想快速实现一个产品而言，如果使用传统开发，又要兼顾前端开发，同时又要花费时间构建后端服务。然而有这么一个平台（Baas Backend as a service）后端即服务，能够让开发人员可以专注于前端开发，而无需花费大量时间和精力来构建和维护后端基础设施。

对于只会前端的人来说，这是一个非常好的选择。后端即服务的平台使得开发人员能够快速构建应用程序，更快地将其推向市场。当然了，你可以将你的后端应用接入 Baas，这样你就无需配置数据库，编写复杂的身份效验。

如果你想了解 Baas，我想这篇文章或许对你有所帮助。



## 什么是 [Supabase](https://supabase.com/ 'Supabase')?

在摘要部分也介绍到名词 BaaS (Backend as a Service) ，意思为**后端即服务**。这个概念是在我接触 Serverless 的时候了解到的，更准确来说是腾讯云开发。当时在编写小程序的时候，只需要专注与应用业务逻辑，而不用编写数据存储，身份验证，文件存储等后端服务，这些统统由 BaaS 平台所提供。 通常会配合 Serverless 函数使用，通常也叫 FaaS（Function as a Service）。通常来说，FaaS 会依赖于 BaaS 平台。

而 Supabase 便是 BaaS 的平台之一。Supabase 是一个开源的 Firebase 替代品。使用 Postgres 数据库、身份验证、即时 API、边缘函数、实时订阅和存储启动项目。

你也许听过 Firebase，由 Google 提供的私有云服务，但开发者无法修改和扩展其底层代码。而 Supabase 是开源的，提供了类似 Firebase 的功能，且定价灵活，并且官方自称为 [Firebase](https://link.juejin.cn/?target=https://firebase.google.com/ 'Firebase')的替代品。

## BaaS 与 CMS 有何不同？

BaaS 通常只专注于应用的后端服务，而 CMS 则是专注与内容管理。不过 BaaS 比较依赖云服务，而 CMS 通常只依赖于 web 后端技术。如果你想搭建一个内容站点（视频，音频，文章），并且作为网站管理员，那么 CMS 就是一个很好的选择，并且有相当多的主题模板。反之，不想搭建后端服务，减少运营程序，那么毫不犹豫的选择 BaaS。

## 注册 Supabase

进入 [supabase 登录界面](https://app.supabase.com/sign-in) 选择 Continue With Github

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_2yiQ9NHv21.png)

输入 Github 账号密码进入[主页面](https://app.supabase.com/projects '主页面')，新建一个项目

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_0eoOyP8DM2.png)

为该项目起名，设置数据库密码，以及分配地区。

:::warning

创建 supabase 项目对密码要求非常严格，像 a123456 这种根本无法通过，像 ●●●●●●●●●● 密码就可以。

地区方面优先就近原则，而最近的也就是日本与韩国，很无奈 supabase 在大陆和港澳台并未设立服务器。

:::

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_N5CQnx8cnU.png)

等待片刻，你将拥有一个免费的后端服务！

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_Z33n9aUOC7.png)

supabase 会提供一个二级域名供开发者访问，也就是这里 Project Configuration 的 URL，对应的这个二级域名 azlbliyjwcxxxxx 也就是你这个项目的唯一标识 Reference ID（下文称 项目 id）。你可以到 [https://app.supabase.com/project/你的项目 id/settings/api](https://app.supabase.com/project/azlbliyjwcemojkwazto/settings/api 'https://app.supabase.com/project/你的项目id/settings/api') 中查看相关配置。

## 体验一下

这里参考到了官方文档 [Serverless APIs](https://supabase.com/docs/guides/database/api 'Serverless APIs')。

首先，创建一个 todos 表，并新增字段（列）task 为 varchar 类型，Save 保存。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_Do9LHoUsYo.png)

Insert row 添加一行记录，id 为 1，task 为 code。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_R9PEyH-spd.png)

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_MLm6_i1Pb-.png)

现在有了数据后，正常来说我们应该做什么？请求一下数据看看？不不不，应该是设置数据的权限。

打开到下图界面，我们要为 todos 数据新增一个 policy 策略。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_MEKk1-qQFl.png)

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_W-C-pGNh1o.png)

supabase 针对不同的场景提供了相应的策略方案模板，你也可以根据你的需求进行设置，这里作为演示不考虑太复杂，选择第一个允许任何人都可以请求到 todos 数据。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_Oa_424N4gz.png)

接着下一步即可

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_wV_MqXQXcK.png)

此时就新增了一个所有用户都可查询的 todo 的策略，同样的你还可以添加只有授权用户才能够创建更新删除 todo，更新与删除只能操作属于自己的 todo 资源。

这时候设置好了数据的权限后，就可以尝试去请求了，打开下图页面，将 URL 与 apikey 复制下来。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_GDEeyFCI2E.png)

选择你一个 http 请求工具，这里我选用 [hoppscotch](https://hoppscotch.io/ 'hoppscotch')，将信息填写上去，请求将会得到一开始所创建的 todo 数据。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_aSbRfmlwb9.png)

除了 restful api 风格，还支持 graphql 风格，可查阅文档 [Using the API](https://supabase.com/docs/guides/database/api#using-the-api 'Using the API')

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_R0HtkYmznS.png)

### 使用类库

正常情况肯定不会像上面那样去使用，而是通过代码的方式进行登录，CRUD。这里使用 [Javascript Client Library](https://supabase.com/docs/reference/javascript/installing 'Javascript Client Library')，替我们封装好了 supabase 的功能。

首先，安装依赖

```bash
npm install @supabase/supabase-js
```

创建 客户端实例

```typescript
import { createClient } from '@supabase/supabase-js'
```

此时准备好上述的 URL 与 apikey，用于创建 supabase 实例，不过 supabase 还提供 [type 类型支持](https://supabase.com/docs/reference/javascript/typescript-support)，可以将生成的 `database.types.ts` 导入到实例中，如

```typescript
import { createClient } from '@supabase/supabase-js'
import { Database } from 'lib/database.types'

const supabase = createClient<Database>(process.env.SUPABASE_URL, process.env.SUPABASE_ANON_KEY)
```

此时有了 supabse 对象后，就能够请求数据了，像上述通过 http 的方式获取 todos 数据，在这里对应的代码为

```typescript
const { data, error } = await supabase.from('todos').select()
```

[官方的演示例子](https://supabase.com/docs/reference/javascript/select) 非常清晰，这里就不在演示新增更新等示例。

![image-20230218182910913](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image-20230218182910913.png)

## [Supabase 主要功能](https://supabase.com/docs)

### Database 数据库

supabase 基于 PostgreSQL 数据库，因此当你创建完项目后，就自动为你分配好了一个可访问的 PostgreSQL 数据库，你完全可以将其当做一个远程的 PostgreSQL 数据主机。

可以在如下页面中查看到有关数据库连接的信息，当然你看不到密码。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_6uCHh3qrlE.png)

测试连接，结果如下，并无问题

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_8-JOTiLI0G.png)

### Authentication 身份验证

[Auth | Supabase Docs](https://supabase.com/docs/guides/auth/overview 'Auth | Supabase Docs')

supabase 令我感兴趣的是 [Row Level Security](https://supabase.com/docs/learn/auth-deep-dive/auth-row-level-security 'Row Level Security')，supabase 使用 Postgres 的 Row-Level-Security（行级安全）策略，可以限制不同用户对同一张表的不同数据行的访问权限。这种安全机制可以确保只有授权用户才能访问其所需要的数据行，保护敏感数据免受未授权的访问和操作。

在传统的访问控制模型中，用户通常只有对整个表的访问权限，无法限制他们对表中特定数据行的访问。而行级安全技术则通过将访问权限授予到特定的数据行，从而让不同的用户只能访问他们被授权的行。这种行级安全有一个很经典应用场景-多租户系统：允许不同的客户在同一张表中存储数据，但每个客户只能访问其自己的数据行。

这对于传统后端开发而言，如果不借用一些安全框架，实现起来十分棘手，要么业务代码与安全代码逻辑混杂不堪。

权限细分方面，无需担心，supabase 已经为你做好了准备，就等你来进行开发。

#### 第三方登录

对于想要提供第三方登录，supabse 集成多数平台（除了国内），只需要提供 Clinet ID, Client Secret, Redirect URL 便可完成第三方登录。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_OvBRJ_elZR.png)

这里演示下如何使用 Github，首先到打开[New OAuth Application (github.com)](https://github.com/settings/applications/new 'New OAuth Application (github.com)') 创建一个 Oauth Apps，其中 Authorization callback URL 由 supabase 提供，如下图。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_QVspy-oxQK.png)

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_jyaUMSDed2.png)

当你创建完后，会提供 Client ID，与 Client secret，将这两个值填写到 supabase 中，并启用。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_QpRRxpR5o5.png)

此时打开如下页面，将 Site URL 替换成开发环境，或是线上环境，在 Github 登录后将会跳转到这个地址上

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_zmfXC85ayC.png)

此时 supabase 支持 github 登录就已经配置完毕，当你在前端触发登录按钮后，借助[supabase 的 js 库](https://supabase.com/docs/reference/javascript/auth-signinwithoauth 'supabase 的js库')，如

```typescript
const { data, error } = await supabase.auth.signInWithOAuth({
  provider: 'github',
})
```

便可完成 Github 第三方登录。

### Bucket 存储桶

接触过对象存储的开发者对 Bucket 应该不陌生，相当于给你一个云盘，这里演示如何使用。

打开如下界面，这里选择公开存储桶，比如说用于图床。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_2Is4Bfwf8f.png)

点击右上角的 upload files，选择你要上传的图片。你可以为此生成一个访问 URL

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_vkuzeZZVJ_.png)

你可以访问 [1.png](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/publilc/1.png) 来查看这张图片。如果是公开的话 一般都是类似https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/new-bucket/1.png

而私有的为 https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/sign/new-bucket/1.png?token=eyJhbGciOiJIUzI1NiIsInR5cCIxxxxxxxxxxxxxxxxx 路径稍微变化了下，还有就是多了个 token，如果不携带 token 则访问不了图片。

你可以到[Supabase Storage API](https://supabase.github.io/storage-api/ 'Supabase Storage API') 查看 storage 相关 api。

:::tip 现学现用

本文中的所有图片数据都来源于 supabase bucket。

:::

### Edge Functions 边缘函数

边缘函数可以分布在全球的接近您的用户各个地方，类似与 CDN，但 CDN 主要服务于静态资源，而 Edge Functions 可以将你的后端应用接口，像 CDN 那样部署到全球各地。

有兴趣可自行了解。

## **使用 Supabase 编写一个简易图床**

如果只单纯看看 supabase 文档，不去动手实践接入一下，总觉得还是差点意思。于是我准备使用 Nuxt 作为前端框架接入 supabase，官方模块 [Nuxt Supabase](https://supabase.nuxtjs.org/ 'Nuxt Supabase') 去编写一个应用。

原本我是打算写个 Todo List 的（恼，怎么又是 Todo List），但是看到 [官方示例](https://supabase.com/docs/guides/resources/examples#official-examples '官方示例')（一堆 Todo List）后我瞬间就没了兴致 🥀。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_1polvJf0q0.png)

思来想去，不妨就简单做个图床吧。项目地址：[https://image.kuizuo.cn](https://image.kuizuo.cn) 有兴趣可自行阅读[源码](https://github.com/kuizuo/image-hosting)。（**写的相对匆忙，仅作为演示，随时有可能删除，请勿将此站作为永久图床！**）

## 一些你可能比较好奇的问题

### 资源

可以到 https://app.supabase.com/project/项目id/settings/billing/usage 中查看相关资源使用情况，这里我就将截图放出来了。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_Bllhp6XlFz.png)

说实话，对于个人独立开发者的项目都绰绰有余了。

### 费用

在 [资费标准](https://supabase.com/pricing '资费标准') 中可以看到，免费版**最多 2 个项目**，不过在上述的资源，其实已经非常香了，毕竟只需要一个 GIthub 账号就能免费使用，还要啥自行车。

![](https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_MNtdzsdJ2t.png)

### 网速

国内因为没有 supabase 的服务器节点，然后且有防火墙的存在，所以请求速度偏慢。不过体验下来至少不用梯子，速度慢点但也还在可接受范围。

### 域名

用过 vercel 的你应该会想是不是也能自定义域名呢? 当然，不过这是 supabase pro 版才支持，一个月$25(美刀)，算了算了，再一眼 azlbliyjwcxxxxx.supabase.co~~就会爆炸~~感觉也蛮好记的。

## 结语

说句实话，真心感觉 supabase 不错，尤其是对个人/独立开发者而言，没必要自行去购买服务器，去搭建后端服务，很多时候我们只想专注于应用程序的开发和功能实现，而不是花费大量时间和精力在服务器和后端服务的部署和管理上。

将 Supabase 作为下一个后端服务

这篇文章将使用 deno 的 web 框架 Fresh，一个简单的 Web 应用 [Link Maker](https://link-maker.deno.dev/ 'Link Maker')，一个用于将链接转换成卡片样式的预览效果。

这个项目也放在了 fresh 的 [Showcase](https://fresh.deno.dev/showcase 'Showcase')，感兴趣的可以查看一番。



## 什么是 fresh？

[fresh](https://fresh.deno.dev/) 自称是下一代 web 开发框架（这句话怎么这么熟悉?），是一个基于 Deno 的 Web 框架。它提供了许多用于构建 Web 应用程序和 API 的工具和功能。Fresh 框架特别强调简单性和灵活性，并着重于提供最佳的性能和开发体验。它支持 TypeScript，并且不需要任何配置或构建步骤。这些特性使得 Fresh 框架成为构建高效和现代 Web 应用程序的理想选择。

:::warning Fresh 的前端渲染层由 Preact 完成，包括 Islands 架构的实现也是基于 Preact。如果你想在 Fresh 中使用其他主流前端框架，目前来说有点无能为力。

:::

## 创建 fresh 项目

[Create a project | fresh docs](https://fresh.deno.dev/docs/getting-started/create-a-project 'Create a project | fresh docs')

deno 提供了非常友好的创建 fresh 项目的命令，运行:

```bash
deno run -A -r https://fresh.deno.dev my-project
cd my-project
deno task start
```

根据你的喜好进行配置，如下

![](https://img.kuizuo.cn/image_jSRfPu966v.png)

此时会创建如下文件

```bash
my-project
├── components        # 组件
│   └── Button.tsx    # 按钮组件
├── deno.json         # deno配置文件
├── dev.ts            #
├── fresh.gen.ts      #
├── import_map.json   # 依赖导入映射
├── islands           # 群岛(组件群岛)
│   └── Counter.tsx
├── main.ts           # 入口文件
├── routes            # 路由
│   ├── [name].tsx
│   ├── api
│   │   └── joke.ts
│   └── index.tsx
├── static            # 静态资源
│   ├── favicon.ico
│   └── logo.svg
└── twind.config.ts   # twind配置文件
```

介绍几个文件：

- **`dev.ts`**: 项目开发模式的匹配文件，假设你需要区分生产环境和开发环境，就可以通过 dev.ts，prod.ts 命令来指明入口
- **`main.ts`**: 入口文件，会用于链接 [Deno Deploy](https://deno.com/deploy)。
- **`fresh.gen.ts`**: 这个清单文件会基于`routes/` 和 `islands/` 文件夹自动生成。包含项目的 route 和 island 信息。
- **`import_map.json`**: 这是用于管理项目的依赖项的导入映射。这允许轻松地导入和更新依赖项。

其中最主要的两个目录，这里会细说。

### routes

**`routes/`**: 存放项目中的所有路由。文件即路由，每个文件的名称对应于访问该页的路径。注：此文件夹中的代码永远不会直接发送到客户端.

其中 routes/api 通常存放一些 api 接口，这这里你完全可以将其当做一个 deno 的服务端，可以做后端能做的事情，通常来说就是提供一个可请求的 api 接口。

而其他文件就相当于一个可访问的页面组件，同样是文件路由系统，也可以在这里进行 SSR、中间件操作。

### islands

**`Islands/`**: 群岛，Fresh 中我并未看到对这一词的解释，你可以到 [astro 群岛](https://docs.astro.build/zh-cn/concepts/islands/) 看看新的 Web 架构模式，主要作用就是用于存放交互式组件（服务端组件），可以在客户端和服务端运行。有点类似与 next.js 的服务端组件，同样有两种状态（服务端，浏览器端）。

这一部分会有点难理解，你只要知道 IsLands 存放的组件有两种状态（服务端，浏览器端），下文称服务端组件，不同于 components 下的组件，服务端组件有一些优势，例如说

- 可以直接访问服务端相关资源
- 避免了不必要的客户端和服务端之间的交互，因此性能更快
- 允许一些类库可以直接运行在服务端，因此减小了客户端包文件的大小

**想要真正理解服务端组件，就不得不将其与 SSR 拿来对比了。**

SSR 通常是将数据通过服务端的前端框架渲染成 HTML，直接将 HTML 返回给客户端就可以省去 xhr/fetch 请求的过程，只需要首次请求就能得到数据。此时页面交互，数据更新与传统的前端应用没有任何区别，**通俗点说 SSR 就是省去 xhr/fetch 请求的过程**。

而服务端组件会在服务端完成渲染，然后通过自定义的协议发送到客户端。前端应用会将新的 UI 整体（服务端组件）的合并到客户端 UI 树里面（也有叫 hydration 水合），此过程不会对客户端其他状态产生影响，还能达到保持客户端状态的目的，极大的增强了用户体验。

如果你仔细查看控制面板的网络请求输出，可以看到服务器端组件是可以请求的。（这里用的后面实战的截图作为展示）

![](https://img.kuizuo.cn/image_v73eXB47yI.png)

不过既然服务端组件也有很多限制，就比如说服务端状态下，是无法使用 Web 相关 Api 的，数据传输（通过 props）是有前提的，要 JSON 可序列化，也就是说只能传递基本类型、基本对象、数组，像 Date，自定义类，函数等复制对象是无法传递的。

## 实战

项目还是相对比较简单的，将链接转化为一个卡片样式的预览效果（包含链接的标题，图片，描述）。

核心代码在 [`routes\api\link.ts`](https://github.com/kuizuo/link-maker/blob/main/routes/api/link.ts) 下，将会生成 `/api/link` 接口，例如访问 [https://link-maker.deno.dev/api/link?q=https://kuizuo.cn](https://link-maker.deno.dev/api/link?q=https://kuizuo.cn 'https://link-maker.deno.dev/api/link?q=https://kuizuo.cn') 你就可以得到如下 json 数据

```json
{
  "title": "愧怍的小站",
  "description": "Blog",
  "image": "https://kuizuo.cn/img/logo.png",
  "url": "https://kuizuo.cn"
}
```

原理就是通过 fetch 请求目标 url，通常来说得到的是一个 html 页面，这时使用 [deno-dom](https://deno.land/x/deno_dom@v0.1.36-alpha/deno-dom-wasm.ts 'deno-dom') 解析成 Dom 对象，通过 css 选择器选取所要的数据，并整合返回给调用方。

有了这个接口，剩下的前端工作就相对比较轻松了，主要也就是细节话的问题。

## 坑点/不足

下面我会说说,在我编写该应用的时候，有哪些开发体验上的不足之处，如果你恰好有使用 Fresh 框架编写 Web 应用的话，最好需要注意下。

### vscode 下对 deno 项目重构并不友好

当我移动项目 .ts/.tsx 文件的时候，vscode 会将该文件与其他引用该文件的路径更改为 .js/.jsx，这就比较蛋疼了，所以每当要移动文件的时候都要尤为小心。

还有就是文件的依赖关系不是那么准确，尤其是在首次进入项目工程的时候，比如说在 routes/test.tsx 中 导入了 `components/Button.tsx` 组件，当你在 tsx 中写了`<Button></Button>` ，vscode 并不会有任何的引入提示，当你打开 `components/Button.tsx` 文件后就又有了，搞得我都怀疑是不是没有该组件。

### 无法直接通过上下文获取 query 参数

fresh 的 handler 提供两个参数，一般来都会写成下面这种形式，可以区分 Get，Post 请求

```typescript
export const handler = {
  async GET(req: Request, ctx: HandlerContext): Promise<Response> {},
  async POST(req: Request, ctx: HandlerContext): Promise<Response> {},
}
```

假设当前的请求是 /api/test?q=123，我想要获取 query 参数的 q，我得这么做

```typescript
const url = new URL(req.url)
const q = url.searchParams.get('q')
```

当时我尝试用 ctx.query 和 req.query 来获取 q 参数，然而 ctx 与 req 并没有 query 属性，在翻阅文档与源码，才得知 fresh 并没有将 query 参数解析到 req 或 ctx 下。

至于说为何要用 query 而不是用 param，主要是因为 url 的缘故，比如说 `/api/link/https://kuizuo.cn` 这个链接，这时 param 是解析不出 `https://kuizuo.cn` 完整 url 的，除非 url 编码，但这对使用者来说就不是很好，于是就舍弃了 param 参数的方案。

### 有些 npm 包在 fresh 无法正常使用

在这个应用中我所使用到了 [html2canvas](https://www.npmjs.com/package/html2canvas 'html2canvas') 库用于将页面的 div 元素转成 canvas，以便转成图片的形式并下载。然后在我导入的时候，要么提示找不到该包（大概率是因为 Commonjs），要么就是 html2canvas 不存在，最终无奈我只好将 html2canvas.min.js 存放在 static 下，并在页面中通过 `<script src="/js/html2canvas.min.js"></script>` 方式导入，这样全局有了 html2canvas 就可使用。

### islands 下的组件要时刻注意 Web Api 调用

我在 islands 下的组件中用到了 localStorage 用于持久化数据，然而在我尝试部署到服务器上的时候发现网站无法访问，并在错误日志中提示 localStorage is not defined。

其实这在很多 hydration 框架中都有这一个问题，在 islands 下的组件有两种状态（浏览器端，服务端），后文就称为客户端组件和服务端组件。也正是如此，服务端组件是没有客户端的运行时环境，就比如说你想要在组件中使用 localStorage 对象用来持久化数据，在两种状态下，首先会在服务端执行一遍，然而服务端并没有 localStorage 对象，此时就会提示 localStorage is not defined。

通常的做法是判断组件当前的状态，可以用如下方式来判断是否为浏览器环境。

```typescript
import { IS_BROWSER } from '$fresh/runtime.ts'
```

然后将 localStorage 等 Web 相关 API 的调用放在 IS_BROWSER 的判断中。

有篇相关文件非常值得阅读，或许对组件的 hydration 有更好的理解

[💧 Hydration and Server-side Rendering – somewhat abstract](https://blog.somewhatabstract.com/2020/03/16/hydration-and-server-side-rendering/ '💧 Hydration and Server-side Rendering – somewhat abstract')

## 前端框架比较局限

在前面也说过，Fresh 的前端渲染层由 Preact 完成。如果用户要用 React/Vue 那为何不选择生态更好的 next.js/nuxt.js 呢？所以目前来看，Fresh 还是有些无能为力。但可以肯定的是，fresh 的方向与 next.js/nuxt.js 的一致。

## 部署

[deno Deploy](https://dash.deno.com/ 'deno Deploy') 可以非常轻松的部署 fresh 应用，使用 Github 账号登录后，[New Project](https://dash.deno.com/new 'New Project')，从 github 仓库中拉取项目点击 Link 即可部署完毕。

![](https://img.kuizuo.cn/image_CYOAgv6IGe.png)

这里的项目名为 link-maker，那么就会生成 专属访问链接 [https://link-maker.deno.dev](https://link-maker.deno.dev/ 'https://link-maker.deno.dev')（也许要梯子才能访问）

## 结语

最后，在我编写完该应用后，我对其做一个评价吧。收回一开始的一句话，~~fresh 自称是下一代 web 开发框架~~。

如果要让我在 next.js 和 fresh 两个相似的产品中做个选择的话，我肯定毫不犹豫的选择 next.js。一个以一己之力推动了前端的发展，到至今已有越来越多的项目使用 next.js ，我想作为任何一个前端学习者肯定会毫不犹豫的选择 next.js 去编写 web 应用。

就从用户的开发体验而言，就已经很难让我再次选择 fresh，更何况还有像 next.js/nuxt.js 这样的全栈框架。作为一个开发体验（Developer experience）优先的程序员角度来看，如果一个框架想要让别人广泛使用，一定要满足其开发过程，只有沉浸于此，才能不断思考，编写出高质量代码。即便无负担的配置，高性能编译，轻便的部署，这些在他人看来可选择的点（也是 fresh 的点），在我看来却显得很微不足道。

而为什么我会选择尝试 fresh，其实也就想看看能不能找到一个令我眼前一亮的一个全栈 Web 框架，然而目前来看，fresh 还有很长一段距离。