On Thu, Mar 8, 2012 at 2:30 PM, Zoom.Quiet <
zoom...@gmail.com> wrote:
> 在 2012年3月8日 下午1:12,agentzh <
age...@gmail.com> 写道:
>> On Thu, Mar 8, 2012 at 12:31 PM, Zoom.Quiet <
zoom...@gmail.com> wrote:
>
> - 这句话,非常重要吼,,,
> - 能展开一些介?B嘛 ?
> - 对于高性能 web 应用开发来?f
> - 行为/业务/功能/代码,,, 哪一种模块化才最合理,的确是很难把握的事儿
> - 如果, openresty 中包含有强烈设计思想的使用规约或是函式,就可以减少大量的设计问题了
>
对于 ngx_openresty 这样的基础件,我们不会只提供一种方式和规范。我们把自主权留给“上层建筑”(比如一些上层应用框架)。不用应用场景的用法可能大相径庭。
> - 嗯嗯嗯 ,这是一定的
> - 不过,杀熟不杀生,除非 haskell 这种非冯机制的?Z言,只能放弃以往所有经验之外
> - 命令序列式的?Z言
> - 学习时,肯定是使用旧经验 来对比想象,才快上手的
> - 在手册中,应该强?{这方面容易引发的?`解
>
我不觉得 ngx.redirect 表达 HTTP 1.1 redirection 在命名上存在容易引起误解的地方 :)
我也不可能在 ngx_lua 的文档中罗列 ngx.redirect 与 Python, Perl, Ruby, Java, Nodejs, Haskell, Smalltalk 等所有常见语言的所有常见应用框架中所有叫做"redirect"命字的东西的区别。
>> 1. 可以在客户端 JS 层面来做 AJAX 请求的组合和融合管理,可以使用类似 ExtJS 4.0 这样的客户端 JS 的 MVC 框架。
>>
> - 这肯定不考虑,否则直接 node.js 更加舒服了
> - openresty 最吸引人的,就是前后端不分直接在 httpd 中完成业务逻辑
> - 使用 lua ?y一维护界面
> - 比需要跨?Z言/?求过程的复杂配合/调试 要爽的多
>
Web 2.0 是 ngx_openresty 推荐的应用模型,在这种模式下,是“天然客户端分布式”的。除非那些需要 SEO 的场景,或者客户端融合的代价过高而须在服务器融合。
>> 2. 当然,也可以在 Nginx 层面通过子请求来进行组合(或者说 mashup),从而能组合各种异质的 Nginx
>> location(Lua 的或者非 Lua 的),比如使用 ngx_echo 模块的 echo_subrequest 或者 ngx_lua
>> 的 ngx.location.capture 等接口,或者 nginx SSI.
>>
> - 对! 就是 ngx_echo ,这是以往你的文章中讲的比较多的
> - 只是,这模块是在 nginx 配置文件中的,不是 lua 中的
> - 进行参数/中间数据传递时,没有那么直觉
> 函式和参数都在一屏距离才容易掌握,,,
>
每一种方式都有它最适合的应用场景。我们提供多种方式就是为了满足多种玩法 :) 有得必有失,包括功能上的,也包括性能上的。
>
>> 3. 更一步地,可以自己在 Lua 层面进行 URL 分发和调度管理。类似 Python 和 Ruby 社区的许多独立的 Web 开发框架。
>>
>
> - 这正是俺设想的,不过,跟 RESTful 的理解不深有关系
> - 俺?O想,不同功能的 API 接口,即可以独立?求
> - 也可以加以组合,以便快速兼容全新业务
> - 因为,?f到底,所有 web 应用都只是对相关数据进行 增/删/改/查 而已
>
其实 RESTful 的最大价值并非在 web 应用内部 :) 而是 Web 2.0 乃至 Web 3.0 的场景。
> ps:
> - 类比 py 的修饰器
> - lua 本身是有高端函式?Z言特性的
> - 也可以有类似的函式叠加方式?
> - 以便将相同的处置/判定 可以快速的复用在不同的功能上?
>
在你决定使用高阶函数和 lambda 组合子这样的函数式方式前,需要清楚由此带来的性能开销 :) 过程式的 Lua 代码在 LuaJIT 中通常会跑得更快,甚至快得多。毕竟咱们平常用的 CPU 并不是传说中的“Lambda 芯片” :)
Regards,
-agentzh