個人のブログレンダリングシステム、SSR、プリレンダー、またはその他のものを構築するための好ましい方法は何ですか？
個人ブログシステムを構築しています。このシステムは、プラットフォームに似ています。つまり、管理者だけでなく、すべての登録ユーザーがブログを投稿できます。
ブログの記述言語としてマークダウンを使用することを決定したので、フロントエンドにマークダウンエディターを提供し、ユーザーが何らかの書き込みを行うとエディターがリアルタイムで更新されます。クライアント側では、マークダウンをレンダリングする機能を提供する必要があります。
それはブログシステムであるため、SEOは考慮しなければならないものです。Googleがスパイダージョブを実行するときにJavascriptコードを実行できることを知っています。ただし、他の一部の検索エンジンでは、そのような機能がありません。したがって、クライアント側のレンダリング戦略全体（ブログページの場合、/blogs/:some-idとして識別される可能性があります）は実行できません。
前に述べたように、フロントエンドにはマークダウンレンダリング能力（コード）があります。これをバックエンドで繰り返したくありません（そうでなければ、2つの異なるマークダウンレンダー構成を維持し、サーバー側のレンダーがクライアント側エディターと同じ出力になることを保証するために、もろい仕事をする必要があるかもしれません）。
そこで、事前レンダリングとSSRに目を向けます。
SSRでは、いくつかの理由により、Javaでバックエンドサーバーを構築することがポイントです。つまり、レンダリングジョブを実行するために、フロントエンドとバックエンドの間に新しい中間JS（ノードまたは...）レイヤーを追加する必要があるかもしれません。このようにして、中間層のすべての要求をインターセプトするなど、中間層とバックエンド層の間で職務を分離する方法、中間層は/blogs/:some-idレンダリング要求を処理し、他のすべての要求を背面に転送するエンドサーバー？
たとえば、事前レンダリングを使用すると、すべての/blogs/:some-idを事前レンダリングされたページにルーティングできます。いくつかの問題もあります。まず、ブログページは静的コンテンツだけでなく、他のユーザーのコメントのような動的コンテンツで構成されています。次に、ブログの変更を処理するために、バックエンドにフックを追加する必要がある場合があります。ブログのコンテンツが更新（追加/削除/変更）されるたびに、一部のページを再コンパイルする必要があります。これは少し奇妙に思えます（しかし、理由はわかりません）。事前レンダリングコンポーネントには、静的な増分コンパイル機能が必要です。コンテナ。
または、他のアーキテクチャがより良い選択かもしれませんか？
サーバーサイドレンダリングは間違いなく良い選択です。
私が関与したプロジェクトの1つでは、SPAフレームワークがサポートしていないため、SSRはオプションではありませんでした。したがって、私たちは解決策を用意しましたこれは決して設計ガイドラインではありませんが、代わりに検討したい興味深いオプションです。
私たちのプロジェクトはリバースプロキシ（Nginx）によって隠されていました。つまり、リクエストがクローラーからのものかどうかを検出しました。このようにして、puppeteerを介して動的コンテンツを評価し、クローラーに提供しました。それ以外の場合は、サイトのオリジナルバージョンをクライアントに提供しました。