入门| 实现服务端渲染

简介: 云开发系列课程主要介绍了从入门到精通快速上手Serverless和云开发技术。学习内容涵盖云开发协同、云函数、云数据库、多媒体托管、前后端一体化框架等Serverless Web开发必备知识。希望通过云开发系列课程的学习与实际操作,让大家深入了解Serverless和云开发技术,并加深对阿里云云开发平台和阿里云Serverless产品的理解与认识。本篇内容向大家介绍如何使用函数实现微服务端渲染,主要包含两部分:如何使用Koa及Koa中间件。

1. 什么是Koa? Koa是一个Node.js Web Framework

很多人都了解Java,Java里的Maven的是一个依赖的中心仓库,里面会有非常多的依赖;那么如果大家了解Node.js的话,会发现与Maven对标的叫npm,npm也是Node.js开发者常用的仓库。那么Koa就是npm里面一个非常常用的框架,一个依赖库。

如果大家浏览过Koa的官网,就会发现Koa主要是基于可扩展模型http协议的一个Web框架。Koa的扩展方式是基于最经典的洋葱模型,它的洋葱模型就是它最核心的部分,即Koa中间件。


2. Koa的基础使用

当我们用http做一些请求的时候,总会带着各种各样的path,在程序员的话术里叫router。我们通过不同的router进去,就能帮我路由到不同的方法上面去。我们现在推荐直接使用Koa,因为它已经给我们提供好了router。

在Koa官网上的github里可以找到很多Koa中间件和依赖库。

通过npm install,在本地建一个仓库,这个仓库直接通过Node.js的意外管理工具npm的一个install命令,就可以把Koa装到本地。

首先看一下在原生机器上使用Koa的例子。将Koa官网上的helloworld拷贝,它是通过Node.js的最基础的依赖的加载机制,require把Koa这个模块加载进来之后,它是一个class new一个Koa的实例,然后通过Koa的扩展方式,也就是Koa中间件方式,通过use加载Koa中间件,可以实现在一个非常小的内核上扩展web应用,它的Koa内核是一个非常简单的代码。


1.jpg


Koa中间件其实是一个很简单的Function。这个Function会有一个ctx参数传进来,这个ctx相比原生的Koa http协议更具吸引力的是,Koa它把原生的 http的request对象和response对象全都代理到了ctx对象上可。也就是说它把请求和响应的各种操作的方法全都代理到了ctx上了。

有学过Midway的同学会发现它们的ctx本质上都是Koa。关于Koa的ctx上面具体代理很多东西,大家可以到Koa的官网上查看它的文档。这样一个简单的代码,它应用了一个最小的中间件,这个中间件就是直接拿到ctx,然后 ctx.body我们可以到官方文档上面找到,在官网上ctx.body就是response.body。

Koa router这样一个中间件的使用方式。在Koa group里寻找中间件,装好中间件。我写个hi serverless,这里加了一个路由,我们再加第二个,第二个取名叫api,然后它这种中间件的使用方式也是通过这些中间件,最后要返回一个Function给Koa的APP。(演示成果)我们先访问的是/path,出来的就是hi serverless;再访问/api,出来的就是hi api。


2.jpg


3. 如何在云上写Koa应用?

上面所介绍和演示的都是在本地的Koa基础使用。那么如何在云开发平台上写Koa应用呢?


通常我们在Node.js里面,把不同的path叫做不同的路由,特别是在Koa体系中,Koa和express这两套体系主要的相关的这些衍生产品,他们都喜欢管不同的 http请求的path叫路由。本质上通过一个http请求的时候传了不同的path,然后通过不同的path映射到不同的处理方法上。


我们这边已经有一个已经ready的Koa的应用迁移方案,大家可以像前几天学的去打开这个界面并新建一个应用,在选择解决方案的时候去勾选Koa的应用迁移方案,然后完成新建。


完成新建后,点开发部署并进入云上IDE的界面。云上IDE可以让我们直接在云上写代码,还可以在云上测试。这个整理好的Koa应用里面,使用到了Koa router,这个router已经整理了好几个经典的用法,并且还加了一个body parser中间件。


关于body parser中间件,要给大家提一下http这样一个通信协议它本身是有不同的方法的,这个方法英文单词叫Mess。不同的方法有不同的语意,虽然之前有几个很火的帖子和文章一直在讨论说http请求方法其实本质上没有区别,但是它们本身有不同的语意,这些语意有一些仅仅是获取资源而不做任何修改,有一些动作是会产生新的资源,这些新资源出来的一些http请求,通常是被称之为那种有修改的请求。


body parser是专门用来去解析除了get请求,就是单纯的获取资源外的处理一些put请求,或post修改或是新增内容请求的数据body的解析中间件,这样的中间件其实用法跟我们刚刚的router其实是类似的,它本质上也是会返回一个函数,然后这个函数会传给Koa,然后Koa的 up会把这些body parser的中间件,还有router这些中间件compose到一起,然后让你顺势去使用它。


云上Koa模板跟本地跑的Koa,最大的区别是云上的 APP。我们这个地方因为跟本地稍微有一点区别,所以在云上的Koa的应用是需要把你的APP给通过module.exports给导出来,这样我们的阿里云才能够感知到你的应用,然后才能使用,但是在本地或者是普通的服务器上跑,大家是不需要做这个操作的。了解了区别之后,我们就会知道如把本地的Koa应用迁移到云上的话,最主要的地方是把这个APP通过这样一个方式给导出来就行了。


导出来之后,云端的同学就知道有这样一个APP,它的运行方式跟我们在本地其实是一样的,我们这边的话代码叫APP.js。在云上运行直接是Node APP.js。


4. 什么是Koa中间件?

导出的APP会在后台运行应用时被require。Koa的中间件把自己定义为普通的function,然后每一个部分都有它自己的function,把这些function组合到一起,接连运行下去,这是Koa对中间件的定义。Koa中间件是它自己定义的一个扩展方法。Koa遵循的设计模式是跟Ruby on rails比较像的,它遵循的原则叫约定大于配置。Koa中间件做的约定是一个函数,它有两个参数,一个ctx一个next,然后这样子的一个函数可以作为一个中间件来使用。


由于Koa比较流行,所以在Node里一般讨论中间件就是指Koa中间件。你也可以自己写一个你觉得更好的中间件模型,如果你做的框架流行起来,那么中间件的标准就会变成你的。然后我们在云上跑跟在本地跑区别是差不多的。


比如说我写一个body=hi,然后再写一个,我在上面写一个body=hi,这个约定大于配置是说函数本身的,现在我们开始讨论中间件到底是什么东西,然后我把 ctx.body加等于相当于一个Alan,这里就有两个函数,这两个函数都被Koa给使用了。


3.jpg


这里的加号写成了等号,这两个函数就都被使用了。这两个函数被组合使用,它一开始是body上是一个hi,然后在第二个函数被使用的时候,这个body就变成了一个hi加上Alan。这是一个很简单的把这两个函数组合起来的一个例子。


我们刚刚说了它有一个约定,就是有两个参数一个ctx一个next,要调next,它才会帮你去调下一个函数。


我们尝试调一下,hi Alan就出来了。然后 ctx和 next这两个参数是Koa给你约定的,然后这个next是指向下一个函数,那么一个函数套下一个函数,然后再继续套下一个函数,就会发现我们可以很自由的在一个函数从一个Path。换句话说,比如说我们要实现一个 user register用户注册一个API的时候,在注册之前,我们可以在这个函数数组上面的中间任意一个位置加上一个新的逻辑去过滤进来的请求。


比如说加一个安全的函数,就会发现所写的函数不管在这中间的任何地方,它其实都处于逻辑中间,所以Koa的作者把这种函数叫做中间件。这个顺序的话,谁先被它use就谁先出现在这个数组里面,但是你也可以把APP上面的数组强行拉出来,然后塞到中间任意一个位置,去做逻辑的处理。


当你去写函数的时候,你会发现这个函数可以很轻易的在你的整个逻辑链路的任何位置去做一个扩展,所以它扩展的时候,它就好像一个中间的东西,所以就把这个东西命名成了一个 middleware,是吧?它并不是一个什么software,也不是一个hardware,它是一个middleware。它可以根据业务模块着层处理,而且你可以把一些逻辑单独用一个函数抽出来,然后去复用,在某些需要使用这个逻辑的路由上面,你再去挂这样一个函数。


总结一下,当我们从本地的Koa应用迁移到云上的一个很大的区别,是云上的一个应用需要把APP导出来,然后在云开发平台去把 Node的进程提起来,完成测试预览,再输入你的端口,然后去访问这个端口,才能去预览Koa应用。

相关文章
|
7月前
|
JavaScript 前端开发 API
【第42期】一文了解服务端渲染框架NextJS
【第42期】一文了解服务端渲染框架NextJS
457 0
|
数据采集 前端开发 JavaScript
服务器端渲染(SSR)与客户端渲染(CSR)的比较
服务器端渲染(SSR)与客户端渲染(CSR)的比较
1227 0
|
3月前
|
开发框架 JavaScript 前端开发
服务端渲染框架
服务端渲染框架
|
1月前
|
缓存 JavaScript 搜索推荐
Vue SSR(服务端渲染)预渲染的工作原理
【10月更文挑战第23天】Vue SSR 预渲染通过一系列复杂的步骤和机制,实现了在服务器端生成静态 HTML 页面的目标。它为提升 Vue 应用的性能、SEO 效果以及用户体验提供了有力的支持。随着技术的不断发展,Vue SSR 预渲染技术也将不断完善和创新,以适应不断变化的互联网环境和用户需求。
74 9
|
4月前
|
前端开发 JavaScript 搜索推荐
|
6月前
|
搜索推荐 前端开发 JavaScript
深入理解后端开发中的服务端渲染(SSR)技术
在现代Web开发领域,服务端渲染(Server-Side Rendering, SSR)技术因其独特的性能优化和SEO优势而受到重视。本文将探讨SSR的工作原理、实现方法及其与客户端渲染(CSR)的比较,同时分析SSR在现代Web应用中面临的挑战和解决方案。通过实例分析,我们将深入了解SSR如何提升用户体验和提高搜索引擎排名,以及开发者如何在项目中有效实施SSR。
|
7月前
|
资源调度
在 Next.js 中使用自定义服务器框架进行服务器端渲染
在 Next.js 中使用自定义服务器框架进行服务器端渲染
|
7月前
|
JavaScript 前端开发 搜索推荐
Vue 的服务器端渲染(SSR)和客户端渲染(CSR)在渲染过程、性能、用户体验等方面都存在显著的区别
【5月更文挑战第8天】Vue 的 SSR 和 CSR 在渲染上有明显差异。SSR 服务器端生成 HTML 返回给浏览器,提供更快首屏加载和更好的 SEO,但增加服务器负担。CSR 客户端渲染,首次加载可能较慢,但交互更流畅,开发更简单。两者各有优劣,需根据项目需求权衡选择。
59 2
|
7月前
|
数据采集 JavaScript 前端开发
服务器端渲染(SSR)和客户端渲染(CSR)
服务器端渲染(SSR)和客户端渲染(CSR)
130 1
|
7月前
|
数据采集 前端开发 JavaScript
服务器端渲染(SSR)和客户端渲染(CSR)的比较与选择
服务器端渲染(SSR)和客户端渲染(CSR)是现代 Web 开发中广泛使用的两种渲染方式。本文将从性能、SEO、开发成本等角度对两者进行比较,并提供选择建议。