SPA SSR SSG

花木瑞前端基础日记约 4200 字...

大概不是我第一次看着这些词,但是在我思考字符串,还有游戏的客户端和服务端的时候...虽然我还啥都没做出来,但是有了些理解。

在最古早的 php jsp 时代,使用的就是 SSR ,但这时的 SSR 十分...简陋,只是单纯的内容的单向展示,而没有多少交互。而之后,web 2.0 以 ajax 的出现作为代表,网页、网站的功能开始变得丰富,就像一个应用 SPA,要用户进行更多交互,让用户有更多操作,CSR 也就不可避免。

SSR 与 CSR 都各有优缺点,在具体 bb 那些有的没的之前,要提醒一下,这两者也并不冲突,十分常见的一种做法是,首屏加载使用 SSR ,而之后有后续操作再去搞 CSR,这被叫做同构渲染。SSR 在展示静态文本的速度与搜索引擎 SEO 上的优势,CSR 在提供更多动态交互与复杂操作上的优化,是可以全都要的,只不过可能要多学点东西。

文本 & 检索

在想要做“查询”这个操作的时候,文字、符号,这些东西在现在依旧有着不可替代的作用,虽然拍照识物、听歌识曲,等等依赖机器学习的技术在不断发展(其实他们也是通过往这些东西上打标签的方式实现的,只不过是交给机器去做,省去人记忆、转换的功夫),但文字符号现在依旧是人能把握的最有效的检索方式。

而在这方面 SSR 被请求后给出的就是一个没有太多难以识别的,已经渲染、展开的、文本化的 html。 SPA 像一个应用,一个可以玩可以搞骚操作但也因此难以被检索的小软件,而 SSR 所做的,就是把这个应用展开展平成容易检索的文本。(但我并不觉得 SPA 的 SEO 会是问题...那些搜索引擎的爬虫现在都很厉害的吧,有些只是不想而已..,再另外,就比如百度,你在技术上做 SEO 有用吗,直接买点排名不是更快更容易见效;再再另外,现在会用搜索引擎查资料的...真的,好像,变少了)

SSG 就更不用说了,被请求后渲染都不用渲的,因为人家本来就是纯静态的 html 文件。

服务端做了什么?

这是我在做那个网盘的 demo ,还有想象游戏服务端的时候在思考的问题。

  • 网盘 & 云

    • 说是网盘,其实就是一个,个人的远程计算机,写个小界面然后通过 web 相关的技术在网络上暴露了一个 Linux 的文件系统。
    • 为什么会想要一个远程的文件系统呢?因为我们想要在任何地方,任何设备上,都能够访问到我们的文件,而不是只能在一台电脑上。
    • 本地、私有的储存好处是私有,没有安全、网络传输、权限之类的烦恼,但坏处也是私有;一个远程的储存服务好处是可以多终端访问,这很神奇,之后的共享、协作、当参与的人多起来之后,还有版本控制、权限管理...这就不再仅仅是“储存”这样一个普通的动作了。服务端做的一个很重要的事情,是协调、协作、同步。
  • 游戏

    • 在上面的叙述中我们理解到了服务端的作用,那是一个协调、协作、同步的角色。不知道你们有没有遇到那种...在笔记本(就是纸质的本子)上和别人画东西来玩的玩法,甚至有一个同学专门用一个小本本当做服务器,然后让大家一起在上面玩多人 rpg 的。。

    但在bb之前我还是想提一下游戏完全可以是单人的,也同样可以多人在一台机器上玩,而且单机游戏很多也很好玩。

    • 其实在写动画和那个小的物理模型的时候,也意识到了计算机的暴力...只为实现一个碰撞检测,每一帧就动不动要成千上万次的计算。也因此,这种需要暴力计算的游戏可能也算是最先遇到性能的问题的,而这种游戏想要做成多人游戏,也是最先遇到网络传输的问题的。互联网相关的技术...在这方面其实并不怎么先进。
      • 具体而言,传输、网络协议方面肯定要做的是长连接。
      • 服务、同步的具体实现方面,也有两个选择,一个是均质的帧同步,一个是事件同步。
        • 而在这里,就让我想到了 SSR 和 CSR(SPA) 的区别。事件同步可以将一部分计算处理放到客户端,等计算到特殊事件时再上传,这样可以将服务端的一部分能力与压力转移到客户端——这是个很微妙的抉择: 压力只是转移而不是消除,而压力同时也是能力与权力,将计算下放到客户端...谁知道有没有小机灵鬼会给自己的客户端动点手脚呢。

(越看越觉得这堆玩意就是纯纯的没事找事干,人家打游戏卡个半秒钟是确实能气死,但是这边搞的最多也就点点屏幕刷个视频看个文档,那点差别有必要吗。...不对我用的这个 vuepress 就是个 SSG 。。

其实还有哇,虽然我博客 vuepress 主体的文档部分是 SSG,可评论、搜索功能,都要,有另外接入的后端服务来做的。

2023-01-18

nuxt 踩坑。
我才知道,next nuxt 它们做的并不只是 ssr ...而是把一大坨各自的开发工具自动集成起来......ssr ssg或者单纯的spa啥的都算是特别的一部分。只是需要 ssr 的话...也并不一定要 nuxt,只是 nuxt 比较开箱即用。(但这个箱我不太会开啊...

vue 本身就有支持 ssr 的那堆东西了 [https://cn.vuejs.org/guide/scaling-up/ssr.htmlopen in new window]

nuxt 的项目初始化好像是需要从外网上拉东西...就,可能需要使用一下魔法,或者改 host 之类的。
而且...目前 nuxt3 的初始化模板,好像,有,点,问题,但我也不确定,毕竟我不太会用。

就是用来 vue 写没错,除了常规的组件库,axios 等等,小工具们比较别致的主要有路由、布局,“内容”(这个就是个小的ssg了...能用来做博客或者一些偏静态的东西...),还有些小的像自动导入。
那些 vue 的插件我之前也见过,弄博客的时候md转html也知道...但是突然都混在一起感觉好神奇(?

还有一件事,初始化项目,yarn 用 create,npm 用 init,npx的create是和之后的nuxt直接连在一起的...这堆玩意是真有够混乱的。
还有该死的网络问题...挂梯子反而也有问题...真tm折腾人。
这个nuxt3仓库的一千多个issue,刚发的版本,还有现在隔几个小时就更新...艹。...会让人很怀疑的啊...


原来 next 和 vercel 有好多 py 交易...。next 和 vercel ,让 react 变得开箱即用。
vue 能找谁呢...

这么看 angular 算不算又走在前沿了。。。


cms 内容管理系统。经典的像 wordpress。
我不确定...到底有多方便,手动写后台,差很多吗...
看了看 strapi prismic apollo, 很像,就是那些,像是低代码的东西。...有人说 django ror 这种的也算...吗?

用 github 的 codespace 写东西...


我在想...之前想的三个也许,可以,一块整。
切网页,也要熟悉工具先不是...?
试水。

感觉...拆模块的一个要点...是防火墙,是可以有混乱的代码的,甚至有时混乱复杂也是必要的,(比如动作游戏的“手感”,就是一堆,难以测试难以控制的部分,就是 tmd 玄学,丢那里就好了,别管太多;另一个就是业务流程本身的复杂度,如果不用代码的长度与复杂来体现,那代码可能更难懂)但是不要让这部分混乱影响到别的地方。
然后才是,控制单文件大小,写测试,bulabula。

今天试试搞 demo 。进一步,再是重开网盘的那个坑。再然后是掘金,一起做东西。毕竟我没试过正经做过什么。
至于那个笔记和打卡...日了,不想看。

计划

AST 是什么.... 解析器..parser..compiler..嚯。

测试

[https://juejin.cn/post/6844904194600599560open in new window]

唔...都是,node里的,npm包。具体去做的话,安装命令,配置文件...之类的,都,差不多。

就,有关测试,这应该算是三个粒度的测试了,ESLint和Prettier是很细的,和语言编译器内置的 debug 很近的那种,Jest是一个函数一个对象一个模块这种的,而Cypress上升到一个功能的。
再有一个就是,测试要做的是,保证正确性,以及出现错误时能快速定位。
还有一些,有些错误即使报了我们也不想管,或者压根就不该在某些地方写测试;另一些,关于定位问题,不仅仅是测试...和代码的模块划分的质量也很相关...
呼...就是,这些也没那么神秘。

我也好想有人一起玩...就算漫无目的,有人一起的话...无聊的在街上逛,晒太阳......
说起来我把日记这种东西像随地大小便一样到处放是不是不太好...
以后有机会应该重新整理一下。

2023-01-20

突然好难受好难受...
为什么,为什么,想变强...想要奶子...

2023-01-24

0124也是个好看的数字

[https://github.com/huamurui/nuxt-0120open in new window]
进一步把那些东西又试了试,具体的hello world们在好几个分支上...
见鬼的是我一直在本地调不好,各种各样的报错。之后全程用的github 的 codespace。...。日。

确认了 strapi 就是个低代码 cms,基于koa + sqlite/mysql/postgresql...数据库可选。“无头”指的是不定死 UI、尽量不限制前端的编写,重点在提供数据接口。

另一个,关于如何抄一个网站。
现在的网站大多都不是用原始的三件套写的,都框架写然后打包过的...打包过后的代码通常都乱七八糟,如果搞不到源码,是...挺折磨的。也就只有html文档结构还算能看...js完全没法看,css也没法看,但 css 可以借助浏览器的开发者工具。
我在想有么有那种很 nb 的爬虫直接把网站的代码爬下来,还能自带还原成容易理解的写法的..这个...也得亏我最近又看了点东西,感觉不太可能。。不只是爬虫了...逆向工程,或者编译。字符串匹配、正则表达式能优化的可能不多...,整抽象语法树,谁要为了这种玩意整啊...

所以也就抄一抄 html 和 css ,基本的结构的样式是不太用写。剩下的还是要自己搞。 就是,处理数据...分析一下,抽象一下,爬虫搞样例数据,开始自己写网站了。

再另一个,...一个人真的好无聊。


百度云 + discourse 能不能当个简易的文库去用?

资源储存就完全去用百度云或者其他在线网盘的,一个帖子或者一个别的什么维护一小片资源的信息,介绍、失效更新什么的也完全可以用帖子的方式来做。

具体来说论坛这边,用户,权限管理,分类,推送等等功能做的是比较成熟的,把它和百度云搞一块…我觉得没问题。

或者,百度云和论坛也只是其中一种。

用别的储存服务,捏种子,真不要脸的拿 github 当网盘也可以;用qq微信一个个交流收集消息,等等等等也完全可以。

续:

这里论坛的作用是,选一个不太大的范围,能弄出些有效的信息集中起来。范围太大可能根本弄不到有效信息,而且常规的大众的信息获取也已经有豆瓣知乎微博这种的能满足需求。

论坛方便的是有可能能找一群自来水...但是先别说找不找得到人,就算能找到自来水干活,产出的质量可能也良莠不齐。 我想的是,找能好好干活的苦力,用人力去再去专门搞一个文库的网站。同样也是不提供具体的服务,只给指路或者一些基本信息。但是这里的信息需要经过挑选整理...或者说审核的。

[https://cook.yunyoujun.cnopen in new window]

[http://mtf.wikiopen in new window]


这是今天我在弄 strapi 之后想的东西...实现一个服务更多的,技术层面的问题也没那么多,现有的软件已经提供太多了。复杂度可以更多的投入的产品的特色设计,找用户,或者说,安利一种新的处理事情的方式上。

[https://www.zhihu.com/question/446613186/answer/1819375500open in new window]

低代码不行吗?如果低对了地方,低准了,感觉,很爽。

2023-01-29

这里的一些想法,除了一些技术上的,还是很奇怪的技术... 比如如何以最快速度整一个网站。 wordpress,或者前端抄结构样式+低代码后端

还有更多的,产品上的考虑...

2024-01-25

真是...一年了... 但还是在这里写一下吧...

最近写垃圾,一开始是看见 react-query 和 useswr,然后是看见 react router 6 给数据请求做的一些看起来好炫酷的支持... 再然后又一次看到了 nextjs... 感觉 SEO 现在对很多应用可能倒没什么了,但首屏,性能,骨架屏什么的...好像又有点...

如果是 spa,那用户想要看到内容,是要走两个来回的,并且可能还是俩不能同时进行的请求... user --js css---> server user --data/json/files---> server 但如果是 ssr,那就是一次,只是需要服务端把数据渲染到 html 里。js 文件可能都直接在服务端不用发了。 user --html with rendered data---> server

一个ssr的首屏html也许有200-300kb,一个后台项目的 js 如果依赖太多可能有 10 mb... 一开始看到的什么 js 文件太大什么的可能并不会影响太多,但是这样必须等两回还要现去渲染的话,如果有速度要求确实会是不太合理的操作... 后台那种东西倒是可以根据路由直接去分包,但那些门户,类 app 的网站...就难搞嘞...

然后就看到了一篇 => 反正,搞成这样的前后端分离,除了技术考虑,对人员管理之类的政治因素的考虑也是有的。又莫名想起来许久之前...看到讲互联网用技术迭代去干掉薪资太高又不听话的老技术团队... 可能还有许多许多...

我为什么要写这玩意? 为什么要解决这堆问题? 我不知道...

懒得管那么多了,堆完功能,就先算球吧..
可能也看了挺多东西的,react 那儿一圈东西,埋点 sdk,服务端那边的数据设计和搞消息通知的...和一堆坑... 只是,我依旧感觉自己大概不是这块料...

今思文韬无处用,昔闻武略已成空。 明朝何处寻新日,思行未竟东方白。

评论
  • 按正序
  • 按倒序
  • 按热度
Powered by Waline v2.14.4