我們有時會聽到對於 htmx 和超媒體的其中一個反對意見，如下：
嗯，它可能對於小東西來說運作良好，但它無法擴展。
用文章來挑釁我們總是危險的，因此讓我們深入探討一下這個說法，看看是否可以闡明超媒體驅動應用程式 (HDAs) 是否可以擴展。
首先，讓我們定義「擴展性」這個詞，然後定義這個詞在開發中可以使用的語境。在軟體語境中，擴展性通常意味著軟體處理「較大」事物的能力。這些事物可以是：
對於 HDAs 來說，這些「擴展」的含義都需要各自的分析。
雖然這對於個別開發人員在決定自己的應用程式時沒有太大意義，但值得一提的是，作為一個分散式網路系統，網路的擴展非常成功。無論如何，它是我所知最成功的分散式系統。
這不一定與個別應用程式開發人員有關，但它奠定了正確的基調：超媒體可以擴展。
超媒體在效能方面是否能很好地擴展？為了回答這個問題，我們先看看一些具有效能可擴展性的軟體特性。雖然沒有關於這些特性的權威來源，但大多數具有擴展軟體經驗的工程師都會同意，此列表中的大多數項目至少是有幫助的。
令人高興的是，事實證明，妥善設計的超媒體系統可以具備所有這些特性。
無狀態是 Roy Fielding 為了描述網路而創建的 RESTful 架構的約束。在實務中，許多超媒體驅動的應用程式使用會話 cookie 來管理伺服器端少量狀態，但這是一種眾所周知的技術，在擴展應用程式方面尚未被證明是致命的。
水平擴展在超媒體驅動的應用程式中歷史悠久，並且與大多數超媒體驅動的應用程式的無狀態特性相契合：早期的 PAAS 供應商（例如 heroku，值得懷念）提供了 rails 驅動應用程式的簡單水平擴展。
功能獨立性是 HDAs 的另一個優勢。在 HDAs 中，螢幕的端點往往彼此之間解耦，這與一般的 JSON API 不同。這意味著這些端點可以被監控、發展和獨立調整。我們在調整這類端點以建立低於 100 毫秒的響應時間方面有著悠久的歷史（例如，透過 SQL 調整來最小化給定端點的資料庫查詢）。
基於端點的獨立性來支援各種視圖，平台效能易於監控和理解。您擁有為特定視圖建構超媒體的 UI 特定端點，而不是可以在應用程式中以多種方式存取的一般 JSON API。當視圖在伺服器端建構且請求是透過簡單的超媒體交換來驅動時，確定效能問題的原因會變得容易得多。
最後，Web 應用程式在快取方面有著悠久的歷史。HTTP 提供由標頭控制的瀏覽器快取。成熟的伺服器端框架（如 Rails）在控制器層提供複雜的快取。快取對於 HDAs 來說是理所當然的。
所有這些結合起來，使得 HDAs 從效能的角度來看極具可擴展性。當使用者負載增加時，可以採用經過實戰考驗的效能技術來擴展您的 HDA。
HDA 方法是否將更多計算推向伺服器端？在某種程度上，這是事實。但是，給定資源的 JSON 表示形式和 HTML 表示形式之間的差異並不像某些人想像的那麼大，特別是如果您不包括 HTML 請求中的標頭和頁尾資訊，這在基於 htmx 的應用程式中很常見。網路延遲和資料儲存存取通常無論如何都會主導請求時間，而使用 SQL（或類似的伺服器端查詢語言）的能力為您提供了優化請求該方面的機會。
由於在 HDAs 中請求是您的視圖，因此 HDAs 通常自然具有最佳的「每個視圖一個請求」。
由於 HDAs 傾向於具有由 UI 需求驅動的獨立端點，而不是一般的 JSON 資料 API，因此隨著功能數量的擴展通常非常容易。假設伺服器端有合理的模型-視圖-控制器拆分，則控制器和模型往往彼此非常獨立。當功能真正重疊時，在伺服器端開發和測試功能會提供更受控制且可測試的環境。
視圖可以透過幾乎所有伺服器端範本庫中提供的伺服器端包含來實現重複使用，或單獨維護以避免相互依賴。
總而言之，只要有合理的應用程式架構，HDAs 通常在應用程式中的功能數量方面擴展非常好，尤其是當這些功能本質上彼此解耦時。
在某種程度上，隨著功能數量的擴展類似於水平擴展：只要它們相對獨立，它們就會很好地擴展（如果它們不是獨立的，HDAs 通常仍然會像其他選項一樣或更好地擴展）。
但是，深層功能呢：本身很複雜的功能呢？
在這裡，我們必須將深層功能分為兩類：
對於深層伺服器端功能，HDAs 通常是一個很好的選擇。一個很好的例子是像 AI 聊天機器人之類的東西：這是一個非常複雜的伺服器端功能，但它通過簡單的文本介面與使用者互動。許多 AI 聊天機器人都是使用 htmx 構建的，人們評論說它有多麼簡單。
對於深層客戶端功能，HDAs 有時並非一個很好的選擇。我們在關於何時選擇超媒體的文章中概述了詳細資訊。總結一下該文章：如果您的 UI 需要快速響應大量事件（例如，拖動地圖視圖）或具有無法在批量超媒體交換中更新的顯著 UI 間依賴關係（例如，試算表應用程式），則超媒體方法不會很好地工作。
但是，我們想指出兩點：
我們將考慮的最後一種擴展含義是擴展開發團隊的想法。不幸的是，在這裡我們必須依靠更主觀和軼事的衡量標準。
根據我們的經驗（以及其他人的經驗），HDAs 似乎允許您用更少的開發人員完成更多的工作。它們還消除了前端/後端分離以及這種分離的溝通摩擦，因為開發人員負責整個功能。有些人喜歡前端/後端分離，並且認為這可以透過使團隊獨立來更好地擴展團隊。
我們不同意。我們認為大多數 Web 應用程式的前端和後端本質上是耦合的，因此，最好的方法是採用一種接受這種耦合並旨在良好處理變化的架構，而超媒體方法正是如此（透過統一介面）。
HDAs 可以擴展到 100 人或更多的團隊嗎？這個我們無法回答，因為我們還沒見過這種情況。但它肯定可以擴展到 10 多人。我們可以想像該方法擴展到更高（畢竟，它在 Web 1.0 時代做到了），但此時我們只是在推測。
我們仍然偏愛較小的團隊。10 名開發人員應該足以應付任何應用程式。
因此，綜合以上所有內容，我們得出關於擴展超媒體驅動應用程式的以下結論：
HDAs 在效能和功能計數方面可以很好地擴展。它們可以隨著功能複雜度擴展，但有一些注意事項。最後，關於團隊規模的擴展仍在討論中，儘管我們可以說 HDA 方法傾向於保持團隊規模較小並消除團隊間的溝通摩擦。