两种不同的移动构架
假设对于移动开发，你的知识还只限制于响应式设计。那么这是远远不够的。
作为一个开发人员不得不去处理一些老旧的框架，同一时候加入一些新功能。为了不不过更好的适应需求，有时也是为了方便更好的扩展。
分享一下。今年来玩的两个不同站点的移动扩展之路，一个是自己的站点，一个则是与女友建设中的一个寻找有趣的人、事、物的站点——寻ta驿站。
一次传统站点的移动开发
对于一个传统的站点来说，不过Responsive是远远不够的。对于使用手机、平台的用户来说。刷新是一种不好的体验。
这里以自己站点(Phodal——Geek's life)的框架作一个演示样例，而自己重构时的思路是来自于某大型站点的框架。
例如以下图所看到的。
博客使用的是基于Django的CMS-Mezzanine，数据库用的是MySQL，而在后面的某个时期已经换成了SQLite3。受限于server的性能。简单地来说，这就相似于一个传统站点的框架。有简单的后台和前台，能够方便地扩展，加入新的功能。
对于一般的用户来说。他们能够习惯于在自己的电脑上的刷新，甚至于假设没有刷新的话，他们可能认为他们什么也没做。而对于移动端来说。刷新是一种不好的体验。不仅会带来额外的流量，当然还有漫长的等待。这能够非常好的解释为Responsive什么在今天Angularjs、Mustache等等的JS库这么流行。由于AJAX带来的长处实现是太多了。
对于移动端採用JS来说
- Javascript的程序猿非常easy找到(似乎对于一个后台程序猿来说，JS也是要掌握的)。
- 须要的不过构建RESTful API
- 不用刷新是多么美妙
尽管他的缺点也相当的多，其它的有如
- 调试上的不便
- 学习曲线
- 有时候你没有办法处理一些与操作系统相关的事件(如select)。
在这里对于我们构建我们的API来说。我们所要做的便是生成一个RESTful接口，对于我们用的是如何的构架已经无所谓了。Nodejs与RESTify的作用便是相当于一个微服务。具有与之相关的特性，如:
- 服务本身是非常简单的，每一个服务側重于做好一件事;
- 可在这个位置使用最佳和最合适的工具来构建每一个服务;
- 建在这样的系统本质上是松耦合;
- 多个开发人员和团队能够彼此相对独立的提供这样的模式下;
- 他们是一支伟大推动者连续输送。让频繁的公布，同一时候保持系统的其余部分可用的和稳定的。
我们能够选用不同的框架来做这些事情。而不须要去考虑其它因素，所要做的是便是独立开发。
而在这时。负责移动UI的程序猿也能够非常愉快地开发了他们的开发之旅，而不是等待。
移动开发与微信
在构建寻ta驿站的时候，一開始我想要的不过一个博客。能够方便地写博客。同一时候能够扩展。除了Wordpress没有想到其它的博客系统。于是，非常愉快地先选了个WP Super Cache以加快站点的打开速度。作为缓存来说性能还是相当优异的。
由于要开发一个微信公众的查询功能。于是用上了WP-API，以及一个微信公众平台——weChat-backend。而weChat-backend则是基于Ruby上的Sinatra框架开发的。当我们发起一次查询的时候:
如上图所看到的，当我们搜索的是极客爱情，会将请求发给微信后台，而后台去请求WP-API。从数据库查询完后再返回。
接着我们便能够在手机client上看到我们所要查询的内容。
对于一个查询不到的结果时，返回的便是博客的RSS的解析结果，返回最新的URL。能够用在微信公众上搜索:hongzhishushe，或者能够直接用二维码扫描。
然而，这会带来非常多问题，当中之中的一个便是Wordpress与MySQL的性能问题。然而相比于自己动手构建一个微信平台来说，利用现有的框架优化也是一个不错的选择。
后记
对于由传统的站点、应用开发来说，移动应用的开发是一种挑战，我们须要去考虑很多其它的东西，而对于移动平台来说，Javascript是一种更好的选择。
须要去综合考虑不同的因素，与传统开发不同的是前后台分离的趋势越来越明显，后台对于前台来说不过一种服务的存在。
不管是站点的手机版。还是相应于微信平台，后台对于前台不过一种服务的存在。
而这样的服务不再不过传统的宏服务，很多其它的是微服务。
由一个个微小的服务来构成整个系统，为整个系统提供更强力的支持，当然他还有非常多问题——《微服务架构——不是免费的午餐 》。
