全棧終結者-把nuxt扔進垃圾桶、Blazor與seo的化學反應

語言: CN / TW / HK

目標

實現一個包含BBS、部落格、工具、常用工具類整合型網站,自己運營

技術考量要點

  • 結合其傳播特點,需要整體考量SEO
  • 服務因涉及到工具掛接特性、類App集市特點,在加上SSR服務端渲染,需考慮併發擴容問題,考慮Nacos整合netcore整合微服務架構形式
  • 部落格、社交從業務複雜性上並不複雜,但另外一個維度的問題是以人為中心、關係、生產資料會隨著運營巨量化,之前有調研基礎,考慮過一種骨骼特性化(即,個體的特徵資料結構化,具體的細節以面板紋理去補充)
  • 資料庫層級考量,通過分庫分表的方式破壞性強,人力成本太高,暫時考慮的模式為mysql僅管理網站顯示內容,使用者的相關個體生產資料及關係儲存到mongo,骨骼特性話儲存,需要時再抓取

技術調研

  • Seo Ssr考量,最優先想到的時nuxt,經過2周反覆的考量,最終放棄了這種處理 找到了一個開源的vue,nuxt仿掘金的、vue單頁無SEO的做的都很好,但是服務端渲染貌似只能用node,如果換成其他服務端成本太大,我調研了2周,找了好幾個,從部署和服務擴充套件性上徹底放棄了這個方案 image.png nuxtcontent也反覆看了一下,覺得就是前端線路的解決方案 image.png 另外工具網站也參考了一部分

image.png - Nacos 致力於幫助您發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集,幫助您快速實現動態服務發現、服務配置、服務元資料及流量管理。Nacos 幫助您更敏捷和容易地構建、交付和管理微服務平臺。 Nacos 是構建以“服務”為中心的現代應用架構 (例如微服務正規化、雲原生正規化) 的服務基礎設施。因為netcore之前的微服務方案有點兒不太理想,具體應用一段發現nacos挺理想,也支援netcore服務接入,這會兒算是找到我比較滿意的方案了,(至於為啥不用java,還是一句實在化,部署和除錯維護層級考量) - 服務端問題因為之前有做聊天軟體的朋友有諮詢,給他提過相關的優化方案,他的實際問題就是app使用者量上來之後導致效能很差,只能不停的補窟窿,當時我就過骨骼特性化設計的思考,還有常規的分庫分表 - mysql資料庫層級實踐後發現,服務分部署部署,要補的窟窿有點兒多,單純個人的力量成本太大,雪花ID生成規則、表自動建立擴充套件、複雜的排序擴充套件查詢,主從備份,讀寫分離等等問題,也就自然而然的放棄了,因為達不到預期。

技術定型-柳暗花明

前因

之前有看到過antd有出過一個Blazor相關的元件,但沒有具體去細看,最終的一個技術驗證讓我柳暗花明, 最開始可能和你們想法一樣,覺得是技術考古,看了幾天都覺得網上很多帖子都沒完整的說明白,為什麼Blazor更棒 1. 不管是asp、jsp、mvc那一套東西其實走的線路一直是ssr,本來就是老本行職業,所以seo這塊的東西毋庸置疑。 2. asp、jsp、mvc技術被淘汰的本質原因是顯示層級的效果,單頁面渲染的訴求,另外就是ssr資源載入卡白屏、前後端只能清晰、前端框架性元件井噴等綜合性考量導致的結果,另外就是特性式的寫法很讓人詬病 3. C#的沒落主要是,不能跨平臺、笨重,後兩年的netcore系列雖然支援了跨平臺部署,但又頻繁的更新了2年,直到net5,net6才算穩定成型,jsp就不用說了,算是放棄狀態,歷史殘留物。 4. 原本asp,其實也有元件化寫法,但怎麼說,弊病太嚴重,根本無法有效的相容js、css等內容,而且不利於長期的運維

後果

Blazor 是一個使用 Blazor 生成互動式客戶端 Web UI 的框架: - 使用 C# 代替 JavaScript 來建立資訊豐富的互動式 UI。 - 共享使用 .NET 編寫的伺服器端和客戶端應用邏輯。 - 將 UI 呈現為 HTML 和 CSS,以支援眾多瀏覽器,其中包括移動瀏覽器。 - 與新式託管平臺(如 Docker)整合。 - 使用 .NET 和 Blazor 生成混合桌面和移動應用。 使用 .NET 進行客戶端 Web 開發可提供以下優勢: - 使用 C# 代替 JavaScript 來編寫程式碼。 - 利用現有的 .NET 庫生態系統。 - 在伺服器和客戶端之間共享應用邏輯。 - 受益於 .NET 的效能、可靠性和安全性。 - 使用開發環境(例如 Visual Studio 或 Visual Studio Code)保持 Windows、Linux 或 macOS 上的工作效率。 - 以一組穩定、功能豐富且易用的通用語言、框架和工具為基礎來進行生成

重點

Blazor Server

Blazor Server在 ASP.NET Core 應用中支援在伺服器上託管 Razor 元件。 可通過 SignalR 連線處理 UI 更新 image.png

Blazor WebAssembly

Blazor WebAssembly 是Blazor WebAssembly,用於使用 .NET 生成互動式客戶端 Web 應用。 Blazor WebAssembly 使用無外掛或將程式碼重新編譯為其他語言的開放式 Web 標準。 Blazor WebAssembly 適用於所有新式 Web 瀏覽器,包括移動瀏覽器 image.png

Blazor Hybrid

混合應用混合使用本機和 Web 技術。 Blazor Hybrid 應用在本機客戶端應用中使用 Blazor。 Razor 元件在 .NET 程序中本機執行,並使用本地互操作通道將 Web UI 呈現到嵌入式 Web View 控制元件。

結果導向

  • 從特性上說,確實發展性可以,而且效能沒得說,生態也比較豐富 image.png
  • 從元件化習慣來說,也趨近於react、vue(起碼一定程度上擴充套件性沒有問題) image.png image.png
  • 從後期部署及負載均衡來說,簡直不要太契合 整體對前後端做負載均衡及分部署部署不香嘛,而且一體化的vs開發環境,體驗效果不要太好 image.png image.png image.png

後續

  1. 重點無腦吹了波Blazor,後續關於"骨骼特性化"特性設計放在後續的大篇幅陳述
  2. 至少是bbs顯示部分會考慮用blazor進行嘗試,最終會補充成品及過程,至於管理端會視情況而定,初步還是會用vue去處理,因為不必考慮seo,又有整套驗證過的crud,會節省花銷一些
  3. 關於nacos和netcore相關過程,留待驗證更新,netcore linux隨後就會更新
  4. BBS服務端設計也會緊接著進行

PS

如果覺得後續有所裨益,對你有所幫助或啟發,關注留言,一起交流參與!!!