本文記錄我從我的同事，Spartacus SSR 專家 kris 那裡學到的一些心得。

我們可以使用 Angular `HTTP_INTERCEPTOR ` 攔截器來記錄超時請求。

但是我們使用時需要小心，只將它用於除錯目的，以找到出現 SSR hangs 的 root cause。 太過激進的日誌記錄策略（尤其是在透過 console.log/error 與輸出流同步完成時）可能會降低 Node Express 應用程式的效能。

如果我們還想透過使用 rxjs 運算子 timeout() 終止攔截器中長期未決的 API 呼叫，那麼 rxjs 流將發出錯誤。

此外，我們希望避免在 SSR 響應中返回格式錯誤的 HTML。 可能有多種方法可以將渲染標記為格式錯誤。

無論標記技術如何，在 SSR 層（ExpressJS 應用程式）我們需要識別格式錯誤渲染的標記，然後傳送 CSR index.html（所謂的 CSR fallback，帶有無快取的 http 標頭）而不是傳送 呈現的 HTML。

以下是一些將渲染標記為格式錯誤的可能方法：

(1) 呼叫一些 Angular API 終止應用程式的掛起渲染並返回一個可以被平臺伺服器和 ngExpressEngine 捕獲的錯誤——如果只存在這樣一個 Angular API. 理想情況下，這樣的 Angular API 還應該安全地拆除掛起的渲染（銷燬元件、服務和模組，這將允許釋放資源）。

(2) 讓渲染完成，但 Angular 應用程式以某種方式將渲染“標記”為格式錯誤，因此我們稍後可以在 SSR（Express js 應用程式）層中決定忽略此 html 並回退到 CSR。

目前尚未確認有任何行業標準方法可以將渲染結果標記為格式錯誤，因此中介軟體可能會忽略它。

可以想象 Angular 應用程式可以透過兩種方式在 SSR 層中留下標記以供之後識別：

- 新增一些特殊的標記 html 元素，例如頁面 `` 中的 `<meta>` 標記。 然後要在 SSR 層中識別它，我們需要在原始呈現的 html 字串上執行正規表示式。 或者

- 在 RESPONSE 物件中設定一些特殊的標記屬性（可以在 Angular APP 中注入，最好使用裝飾器 @Optional() 來避免 CSR 中的錯誤。可以從 @nguniversal/express-engine/tokens' 匯入 RESPONSE。

然後，獨立地可能有 2 個潛在的地方我們可以攔截渲染結果，識別標記並在響應中傳送 CSR 回退：

- 在 OptimizedSsrEngine 內部，在我們獲得原始 html 之後，但在將其傳遞給響應回撥 (callback(err, html)) 之前。 或者
- 編寫自定義的、獨立的 Express.js 中介軟體並透過 app.use(myMiddleware) 將其插入 server.ts

使用 Angular HTTP_INTERCEPTOR 攔截器來記錄超時請求的一些思考

相關文章