快捷搜索:  汽车  科技

nuxt反向代理教程(全栈终结者-把nuxt扔进垃圾桶)

nuxt反向代理教程(全栈终结者-把nuxt扔进垃圾桶)Blazor Server在 ASP.NET Core 应用中支持在服务器上托管 Razor 组件。 可通过 SignalR 连接处理 UI 更新使用 .NET 进行客户端 Web 开发可提供以下优势:另外工具网站也参考了一部分之前有看到过antd有出过一个Blazor相关的组件,但没有具体去细看 最终的一个技术验证让我柳暗花明, 最开始可能和你们想法一样,觉得是技术考古,看了几天都觉得网上很多帖子都没完整的说明白 为什么Blazor更棒Blazor 是一个使用 Blazor 生成交互式客户端 Web UI 的框架:

#头号周刊#

目标

实现一个包含BBS、博客、工具、常用工具类整合型网站 自己运营

技术考量要点
  • 结合其传播特点 需要整体考量SEO
  • 服务因涉及到工具挂接特性、类App集市特点 在加上SSR服务端渲染 需考虑并发扩容问题 考虑Nacos集成netcore集成微服务架构形式
  • 博客、社交从业务复杂性上并不复杂 但另外一个维度的问题是以人为中心、关系、生产数据会随着运营巨量化 之前有调研基础 考虑过一种骨骼特性化(即 个体的特征数据结构化 具体的细节以皮肤纹理去补充)
  • 数据库层级考量 通过分库分表的方式破坏性强 人力成本太高 暂时考虑的模式为mysql仅管理网站显示内容 用户的相关个体生产数据及关系存储到mongo 骨骼特性话存储 需要时再抓取
技术调研
  • Seo Ssr考量 最优先想到的时nuxt 经过2周反复的考量 最终放弃了这种处理

找到了一个开源的vue nuxt仿掘金的、vue单页无SEO的做的都很好 但是服务端渲染貌似只能用node,如果换成其他服务端成本太大 我调研了2周 找了好几个 从部署和服务扩展性上彻底放弃了这个方案

nuxt反向代理教程(全栈终结者-把nuxt扔进垃圾桶)(1)

nuxtcontent也反复看了一下 觉得就是前端线路的解决方案

nuxt反向代理教程(全栈终结者-把nuxt扔进垃圾桶)(2)

另外工具网站也参考了一部分

nuxt反向代理教程(全栈终结者-把nuxt扔进垃圾桶)(3)

  • 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 更新

nuxt反向代理教程(全栈终结者-把nuxt扔进垃圾桶)(4)

Blazor WebAssembly

Blazor WebAssembly 是Blazor WebAssembly,用于使用 .NET 生成交互式客户端 Web 应用。 Blazor WebAssembly 使用无插件或将代码重新编译为其他语言的开放式 Web 标准。 Blazor WebAssembly 适用于所有新式 Web 浏览器,包括移动浏览器

nuxt反向代理教程(全栈终结者-把nuxt扔进垃圾桶)(5)

Blazor Hybrid

混合应用混合使用本机和 Web 技术。 Blazor Hybrid 应用在本机客户端应用中使用 Blazor。 Razor 组件在 .NET 进程中本机运行,并使用本地互操作通道将 Web UI 呈现到嵌入式 Web View 控件。

结果导向

-从特性上说 确实发展性可以 而且性能没得说 生态也比较丰富

nuxt反向代理教程(全栈终结者-把nuxt扔进垃圾桶)(6)

  1. 从组件化习惯来说 也趋近于react、vue(起码一定程度上扩展性没有问题)

nuxt反向代理教程(全栈终结者-把nuxt扔进垃圾桶)(7)

nuxt反向代理教程(全栈终结者-把nuxt扔进垃圾桶)(8)

  1. 对于后期部署及负载均衡来说 简直不要太契合 整体对前后端做负载均衡及分布部署不详嘛 而且一体化的vs开发环境 体验效果不要太好

nuxt反向代理教程(全栈终结者-把nuxt扔进垃圾桶)(9)

nuxt反向代理教程(全栈终结者-把nuxt扔进垃圾桶)(10)

nuxt反向代理教程(全栈终结者-把nuxt扔进垃圾桶)(11)

后续
  1. 重点无脑吹了波Blazor 后续关于"骨骼特性化"特性设计放在后续的大篇幅陈述
  2. 至少是bbs显示部分会考虑用blazor进行尝试 最终会补充成品及过程 至于管理端会视情况而定,初步还是会用vue去处理,因为不必考虑seo 又有整套验证过的crud 会节省花销一些
  3. 关于nacos和netcore相关过程 留待验证更新 netcore linux随后就会更新
  4. BBS服务端设计也会紧接着进行
PS

如果觉得后续有所裨益 对你有所帮助或启发 关注留言 一起交流参与!!!

猜您喜欢: