在 Supabase 與 Cloudflare 上打造專用 Web 應用程式的經過

大家好，我是 Liberogic 的 CTO 大塚。

近來針對企業網站與系統的網路攻擊接連發生，前天 PHP 的重大漏洞也成為話題。

本次要談的 Web 應用程式開發，可以說是盡可能減輕這類資安對策與營運負擔的架構，不過資安的話題我想另外找機會再談。

申請與審核、會員專屬頁面、供合作夥伴使用的入口網站、工時管理等，依照各家公司的業務量身打造的客製化 Web 應用程式，我們常用的組合就是 Supabase 與 Cloudflare。

過去需要在 AWS 上個別建置 EC2、RDS、S3、Cognito 等元件，或是架設 Linux 伺服器，再自行安裝 Web 伺服器、中介軟體與框架，資料庫 / 驗證 / API / 檔案儲存各自都要耗費建置與營運的心力。
使用 Supabase 與 Cloudflare 後，這些基礎部分交由服務端處理，就能專注於開發該應用程式真正需要的功能。

本文將簡要介紹，結合 Supabase 與 Cloudflare 可以打造出什麼樣的專用 Web 應用程式。

什麼是專用 Web 應用程式

這裡所說的「專用 Web 應用程式」，指的是依照公司與業務需求量身打造的 Web 應用程式。
例如像這樣的系統。

• 內部申請與審核系統
• 會員專屬頁面
• 供貨商專用入口網站
• 工時與出勤管理
• 專案管理
• 諮詢管理
• 門市與據點適用的管理系統
• 檔案共享與審核系統
• 問卷與診斷結果管理
• 各類業務用的管理畫面

當您向我們諮詢這類需求時，我們會先確認現有的 SaaS 或套裝產品能否實現。一般業務而言，採用既有產品往往更快速、成本也更低。

不過實際把需求逐一列出後，就會發現真正符合「正是我們想要的功能」的產品其實不容易找到。
例如公司專屬的審核流程、各部門或據點需顯示的資訊不同，或是需要與既有系統串接等情況。

這麼一來，與其configure業務流程去配合SaaS、靠日常維運來彌補落差，往往更好的提案是打造一套貼合業務的專用Web應用程式，讓客戶的業務運作更順暢。實際上，我們判斷這樣做的案例相當多。

Supabase 可一次提供 Web 應用程式所需的資料基礎

Supabase 是一項服務，可一次整合運用 Web 應用程式所需的後端功能。

這項服務在全球也頗具成長動能，使用的開發者已超過 1,000 萬人。據美國知名新創加速器 Y Combinator 公布，其最近一期的批次中有 55% 採用了 Supabase，正逐漸成為新服務後端的標準選擇。

這些實績主要來自擁有大量 B2C 使用者的服務，但我們認為此機制同樣適用於公司內部或合作夥伴使用的「內部型業務 Web 應用程式」，因此予以採用。

主要功能包括：

• Database（託管的 PostgreSQL 資料庫）
• Auth（使用者驗證與登入）
• 自動生成 API（定義資料表後，即可直接使用 REST API）
• RLS（Row Level Security：列級權限控制）
• Storage（檔案儲存）
• Realtime（即時通訊）
• Edge Functions（無伺服器運行的 API 處理）

等功能。

若是企業應用程式，可以在 Supabase 的資料庫中管理使用者資訊、專案資訊、申請資料與操作紀錄等內容。

此外，只要使用 Supabase Auth，就能直接加入登入功能。這套 Auth 之所以適合企業應用程式，是因為它支援以 Microsoft 帳戶或 Google 帳戶登入。

若公司已在使用 Microsoft 365 或 Google Workspace，員工就能直接以平時使用的帳戶登入。無需另外發放應用程式專用的 ID 與密碼，入職與離職時的帳戶管理也能沿用既有的機制。

過去，將資料庫與驗證分別建置、再加以串接的架構並不少見。而使用 Supabase，則能將資料與驗證整合在同一個基礎上。

透過 RLS（Row Level Security），

• 即可只顯示使用者本人的資料
• 只顯示同一據點的資料
• 管理員可以檢視所有資料

這類權限控制也可以在資料庫端進行。

在業務應用程式中，這類權限控制相當重要。

使用 Cloudflare 發布前端

不過，光靠 Supabase 無法完成一件事，那就是「網站（前端）的託管」。
資料庫與 API 可以交由 Supabase 負責，但使用者透過瀏覽器存取的畫面本身，則必須由其他地方發布。

其中最具代表性的前端發布平台是 Vercel 與 Cloudflare。我們選擇了 Cloudflare，理由有以下幾點。

• 可在 Cloudflare 上統一管理從 DNS、CDN、WAF 到應用程式發布的所有項目
• 透過 Cloudflare Workers，不僅能發布前端，還能整合 API 處理與外部服務連接
• 提供 R2（儲存空間）與 Access（存取限制）等周邊服務，與業務應用程式十分契合
• 計費方式以流量為準，概念簡單，預算也容易掌握。

提到 Cloudflare，多數人可能會先聯想到 CDN 或 DNS，但如今它也已經是足以用來執行 Web 應用程式的完善平台。

從製作公司的角度來看 Cloudflare

換句話說，在這個架構中，Cloudflare 負責接收使用者的存取請求，並回傳畫面與 API；而其背後的資料、驗證與權限控管則由 Supabase 負責，兩者各司其職。

結合 Supabase 與 Cloudflare

例如可以採用以下架構。

運行於 Cloudflare Workers 上的應用程式接收使用者的存取請求，回傳畫面與 API；其後端則由 Supabase 負責資料與驗證。

視需要，還可以透過 SendGrid 寄送郵件、將檔案儲存至 Box 等外部儲存空間，或與其他業務系統進行 API 整合。

這個架構的優點在於，整體皆由標準技術組合而成，且不侷限於特定的整合對象。
只要支援 API 整合，無論是既有的核心系統，還是目前已在使用的 SaaS，都能自由串接。不會像一般套裝產品那樣，出現「此產品只能與○○連接」之類的限制。

例如可以打造以下這類業務應用程式

內部申請・審核應用程式

可讓各據點與負責人員登錄申請，再由主管或管理者進行審核的應用程式。
依登入使用者的不同，

• 僅顯示自己的申請
• 顯示據點內的申請
• 管理者可檢視全部申請

等權限控管也能實現。
簡單來說，就是把原本透過電子郵件與 Excel 處理的業務，直接轉為網頁應用程式。

客戶專用入口網站

為每位客戶發放登入 ID，

• 檔案瀏覽
• 檔案上傳
• 進度確認
• 聯絡我們
• 確認合約資訊

也能建置可進行等操作的入口網站。
依合作對象調整顯示內容等控制方式，也相對容易實作。

工時與出勤管理

讓員工逐一輸入工時與工作量，並依專案、負責人彙總的應用程式。
若有一般考勤 SaaS 難以處理的獨特規則，或公司專屬的彙總方式，專用的 Web 應用程式會更加適合。

這類業務若硬要套用現成產品，反而常常變得更麻煩。

據點管理系統

也很適合由全國各門市或營業所登錄資訊、由總部統一管理的 Web 應用程式。

從只有幾人使用的內部工具，到跨多個據點使用的業務應用程式，都能應對。
並不是說「因為使用 Supabase 所以只適合小規模」。
視設計而定，可以用於相當廣泛的用途。

例如，本公司協助開發的應用程式如下。

豐田汽車 SNS 營運管理系統「TOYOTA Social Hub」UI/UX 設計與系統開發

判斷應採用 SaaS 還是客製網頁應用程式的標準

前面介紹了許多客製網頁應用程式的優點，但客製網頁應用程式並非永遠都是正確解答。
那麼，該在什麼時候判斷「應該自行開發比較好」呢？以下根據實際接到的諮詢經驗，列出一些參考依據。

• 長期依賴人工補足作業
  審核流程因部門而異、例外處理很多等，業務流程已偏離 SaaS 的設計假設，光靠設定無法完全吸收
• 權限與顯示內容的控管需要非常細緻
  希望依部門、據點或交易對象變更顯示的資訊，但 SaaS 的權限功能粒度不足
• 業務需要在多個工具之間來回切換
  在 Excel、電子郵件與多個 SaaS 之間往返，重複手動輸入與複製貼上已成為日常
• 自訂管理項目與彙總規則眾多
  硬把公司獨有的資料塞進 SaaS 的通用欄位中
• 現場覺得功能過多或不足
  因為是通用型 SaaS，畫面複雜而無人使用，或是真正需要的功能反而缺少

若只符合一、兩項，通常透過調整 SaaS 的設定或作業方式就能解決。
但如果符合多項，且日常中「一點小麻煩」不斷累積，我們認為就是考慮配合業務量身打造客製網頁應用程式的時機。

事實上，「想把用 Excel 管理的資訊網頁化」「想把透過電子郵件處理的申請系統化」「想把在多個 SaaS 之間往返的業務整合為一個」這類客製網頁應用程式的討論，往往就是從這樣的諮詢開始的。

小規模開始製作，邊使用邊逐步成長

說明到目前為止的技術架構，最後想跟您分享的，與其說是 Supabase 或 Cloudflare 本身的功能，不如說是專案的推進方式。

「該做什麼」，其實很難從需求定義書中看出來

一般的軟體開發通常從需求定義開始。先將現有業務整理成文件，再據此設計能滿足需求的系統，這是常見的推進方式。

不過，這種方式也有其弱點。文件上雖然已經涵蓋了業務內容，但往往缺少「實際使用起來順不順手」以及「這個功能真的需要嗎」這樣的檢視，需求就這樣一項項累積下來。
尤其是對負責推動 DX、但並非系統開發專家的人來說，光靠文字和表格來判斷需求是否合理，相當困難。

因此，Liberogic 並不是先花大量時間完成厚厚的需求定義書，而是使用 Figma、v0、Claude Code 等工具製作原型（可實際操作的畫面草稿），邊讓客戶實際操作邊推進討論。

與純文字的需求定義不同，實際操作畫面時，能以極高的真實感體驗「用起來會怎樣」。有趣的是，客戶的關注點往往會從「確認文件」轉向「改善業務」，例如「如果有這個畫面，業務的某個部分會輕鬆很多」、「說到這個，另外進行的那項作業是不是也能自動化？」。

在專用 Web 應用程式開發中，真正重要的往往正是「該做什麼」這個部分。我們認為，這並不是在文件中決定的，而是在透過原型共享想像的過程中逐漸浮現的。

先實作基本功能並率先上線

我們不會一開始就決定所有需求、一次性做完，也就是所謂的瀑布式開發。待原型確定方向後，會先實作登入、資料登錄、清單顯示、管理畫面等基本功能，然後率先上線。

上線後，一邊讓您實際使用，一邊確認使用感受與現場的回饋，再逐步新增審核功能、郵件通知、檔案管理、外部 API 串接等。
Supabase 與 Cloudflare 的架構，與這種循序漸進的推進方式非常契合。

依預算與業務價值逐步擴充

「小規模開發，再依需求擴充」也關乎預算層面。舉例來說，

• 依照每年預先編列的預算，逐步開發功能
• 先小規模上線，待業務價值逐漸顯現後，再追加投資擴充應用程式

等方式都可行。不必一開始就一次編列大筆開發費用，也能擁有並逐步培養業務應用程式。我們認為，業務應用程式與其一開始就把需求定得十全十美，不如邊使用邊改善，通常效果更好。

總結

結合Supabase與Cloudflare，即可以相對精簡的架構，打造具備身分驗證、資料庫、權限控管、API 與檔案發佈功能的專用 Web 應用程式。從公司內部的小型業務工具，到面向合作夥伴的入口網站，以及跨多個據點使用的業務系統，都能依用途逐步擴展。

不過，真正重要的並非Supabase或Cloudflare等工具本身，而是推進的方式。

• 先透過原型圖分享「實際使用的情境」，找出真正應該開發的功能
• 先只開發基本功能，盡快上線
• 邊使用、邊依預算與業務價值逐步擴充

這樣的推進方式過去並不切實際。因為軟體實作的成本與基礎設施建置的成本都很高，必須在事前把所有細節都定案，才能開始動手製作。

如今，藉由 Supabase 與 Cloudflare 等現代技術堆疊，以及運用 AI 代理的開發與原型製作，我們已能以更接近理想的方式推進專案：先做出可以實際操作的東西，再一邊使用、一邊持續培育。Liberogic 最擅長的，正是這樣的推進方式。

「這項業務目前用 Excel 和郵件處理，能不能改成網頁版？」「試過 SaaS，但總覺得不太符合我們的業務」，即使是這樣的初步諮詢也沒問題。我們會和您一起思考符合業務需求的架構，歡迎您隨時與我們聯繫。