标签 [Web]

14
Flask 基于子域名的蓝图管理
在 Flask 中,蓝图(Blueprint)通常是基于路径进行分派的,因此我们看到典型的注册代码一般类似这样: app.register_blueprint(home_bp, url_prefix='...') 相对少见的另一种用法是,Blueprint 也可以通过子域名来分派,这涉及到程序结构上会有一些改变,同时也会带来一些新的问题(当然都是可以解决的)。使用子域名是大型网站的常规做法,同时也使得 URL 路径更有针对性,比如提供一个 https://api.mydomain.com/... 比起所有页面都堆到 https://mydomain.com/ 下面,看上去也显得更专业一些。我自己也在尝试通过这种方式重构自己的网站,最开始尝试的是每个域名使用一个单独的 app 去管理,但很快发现如果一些比较小的功能也做成独立的网站,会带来比较多额外的管理负担。因此,把这些功能合并到一个app,对外又能通过子域名公开,是不错的做法。因此,我对这种实现做了一些尝试,并对遇到的问题和解决办法做一个记录,以供自己和其他朋友参考。
Solid Project:重新定义 Web?
介绍 Tim Berners-Lee, Web 的奠基人,由于不满互联网日益被少数大公司所垄断的现实,目前致力于开发一个名为 Solid 的新项目,希望能把管理数据和应用的权力重新归还到用户手中。这个消息估计不少人已经听说过了。基于 Web 的开放思想,Solid 项目也一直是在公开与开源的指导原则下进行的,但直到最近,该项目才逐渐从构想转到实现,我们也终于有具体的细节信息可以一探该项目的究竟。
用 C# 自己动手编写一个 Web 服务器,第六部分——用户验证
用户验证和授权 在 上一篇文章中,我们添加了视图引擎支持,可以输出真正的动态页面了。再加上控制器(Controller)的支持,现在应用程序开发者可以自由执行业务逻辑,并输出想要的页面效果,可以说,一个真正的 Web 服务器已经基本成型了。不过,大多数业务系统还需要用户验证(Authentication)和授权(Authorization)的功能,允许用户在系统中登录和注销,并根据用户权限判断他(她)能够执行的操作。
用 C# 自己动手编写一个 Web 服务器,第五部分——视图引擎
视图引擎 在 上一篇文章 中,我们实现了 Session,并在过程中为 HttpListenerContext 提供了更高层的封装。在 Controller 返回的结果中我们可以看到服务器动态执行的结果,不过目前它们是以原始字符串的形式存在的。从基本原理来说,返回字符串并没有什么不妥————互联网早期的 CGI/Servlet 都是这么做的。问题在于这种接口过于底层了。设计者希望看到 HTML 页面,而不是苦哈哈的自己去拼接字符串。这就是视图引擎(View Engine)存在的理由。
用 C# 自己动手编写一个 Web 服务器,第四部分——Session
Session 在 上一篇文章 中,我们实现了 Web 服务器的路由功能,并实现了控制器的基本支持。本来,我们应该高高兴兴的继续向其中添加功能,不过马上就发现一个尴尬的问题————我们还没有 Session。更具体的说,我们一直在使用的 HttpListenerContext 只提供了 Request/Response,却没有 Session 属性。这意味着我们的服务器毫无记性,只能把每次请求都当作新的用户。
用 C# 自己动手编写一个 Web 服务器,第二部分——中间件
在 上一篇文章 我们创建了一个具有基本静态文件服务功能的 Web 服务器,但是还没有动态功能的支持。我们希望在这个程序的基础上进一步扩充,成为具有完整功能的动态 Web 服务器。不过先别忙着写代码,让我们从架构的层次上考虑一下 Web 框架应该是什么样的。
用 C# 自己动手编写一个 Web 服务器,第三部分——路由
路由(Routing) 在 上一篇文章 中,我们将 Web 服务器的功能拆分成一系列较小的中间件(Middleware),建立起一个灵活、可扩展的架构。但目前的中间件只提供了静态文件支持,还没有任何动态功能。 对于绝大多数现代 Web 服务器来说,路由(Routing)都是其中核心的部分。按照企业应用架构模式的分类,路由应该属于其中的“前端控制器”(Front controller),主要目的是将接收到的 HTTP 请求分发到相应的后端业务模块去处理。而分发规则主要是基于请求的信息(路径、HTTP方法、头部信息、Cookie等)。虽然总体思路是相似的,但各个语言或编程框架声明路由的方式还是相差很大。例如,Nodejs 框架 Express 要求你显式声明路由对应的方法:
用 C# 自己动手编写一个 Web 服务器,第一部分——基础
市场上已经有如此之多的 Web 服务器,为什么还要自己写一个?这对真正的黑客来说其实是个无需回答的问题。不过,即便你自认是个小白,也无需被题目吓倒——现代的语言和框架已经为我们提供了非常强大的基础设施,我们用很少的代码就能搭建起一个基础的 Web 服务器。事实上,我们下面要介绍的第一版程序核心代码经过完整的封装、并且提供了静态文件处理,而核心代码也不过 70 行左右,如果你只想要一个静态文件服务器,那么你完全可以把代码压缩到 40 行,而且这些代码非常容易理解。
用 C# 自己动手编写一个 Web 服务器 (索引)
这里是本系列文章的索引。 用 C# 自己动手编写一个 Web 服务器 (索引) 用 C# 自己动手编写一个 Web 服务器,第一部分——基础 用 C# 自己动手编写一个 Web 服务器,第二部分——中间件 用 C# 自己动手编写一个 Web 服务器,第三部分——路由 用 C# 自己动手编写一个 Web 服务器,第四部分——Session 用 C# 自己动手编写一个 Web 服务器,第五部分——视图引擎 用 C# 自己动手编写一个 Web 服务器,第六部分——用户验证
爬虫这个领域,就快要被玩坏了
最近知乎上有几个邀请我的关于网络爬虫的问题。我看到了,但是并没有心情去回答。说实话,我的心情挺糟糕的。爬网站 -》 反爬 -》 反反爬......一直是爬虫界生生不息的主题,但是现在的反爬手段已经变态到这种程度,足以说明:爬虫这个行当,快要被某些人玩坏了。
Firefox Quantum 的确快多了
看到 CnBeta 上的新闻。老实说,因为这几年浏览器厂商都在说自己的产品比上一版快了多少多少,但实际使用中几乎感觉不到,所以我对这类消息本来是不怎么感冒的。但我是 Firefox 的长期用户,所以还是下载了尝试一下。这一试我真的震惊了。甚至用不着测试数据,已经明显发现页面加载速度快了很多,大部分固定页基本上是秒开,翻页、导航、菜单的操作也比以往反应速度更加灵敏。
Nodejs 不适用于大规模服务端开发?
今天看到文章 Node之父Ryan Dahl:我不想被定义。 前面是 Nodejs 之父 Ryan Dahl 的个人经历,耳熟能详,倒也没什么好说的。倒是中间这一段:
用面向对象方法组织 Flask 应用程序 (一)
Flask 是著名的 Python Web 微框架,而 《Flask Web 开发——基于 Python 的 Web 应用开发实战》(OReilly出版社出品,以一只大狗作为封面,所以也有人戏称“狗书”)则是这一框架的经典书籍。特别是该书的第七章,描述如何将网站划分为多个模块,很多 Flask 网站都是参照该例子的形式进行规划的。 我的 个人主页 也用了 Flask 框架来开发,网站结构在很大程度上参考了该书的示例。但在开发过程中,我也感觉到该方式也有一些不够合理的地方,主要表现在:
浏览器是更强大的IDE
虽然我很多时间都在做和 Web 网站相关的开发工作,但很少有机会从另一个角度去看待这件领域。直到有一天,我和设计师沟通需求时,看着他在浏览器里打开开发工具,直接修改线上的网页样式,然后观察效果,这样反复几次,最后效果满意了,再把完成的样式复制到自己的设计稿里。 那一刻我被深深触动了。尽管从技术上说这并不是多么稀奇的事情,甚至我自己也做过好多次类似的事情,但是从旁观者的视角,却让我意识到自己过去一直不太注重的一个事实:浏览器实际上是一个非常强大的IDE,甚至比某些人喜欢挂在嘴边的“宇宙最强”,在某些方面更加强大。