我将尽力将此作为一个可回答的问题,而不是作为讨论的开始.

根据您的经验,我的问题的实质是,将您的网站的移动网络版本开发为一个单独的应用程序,将您的网站用作API或在同一个为您的网站提供服务的Rails应用程序中进行开发更好吗？

我目前正在计划如何实施它,而且正如我所看到的那样,每个人都有好处.

单独的移动网络申请

>上升空间

>性能：减少现有网站的开销=更好的性能
>更小的占用空间：更易于组织和更清洁的应用程序工作/开发
>解耦：会迫使我们为桌面/移动设备构建服务

>下行

>子域名：必须使用m.thredup.com,因此移动流量可以路由到单独的应用程序
>会话管理：必须处理多个应用/域上的身份验证
>本地发展更难：维持本地发展的另一项服务
>分支管理：新代码需要针对Web应用移动应用的单独分支

移动网络的相同应用程序

>上升空间

> URL Scheming：能够为桌面移动使用相同的URL(更容易共享)
>会话管理：能够使用现有的用户会话
>更快的实施：更短的项目时间表,因为所有后端逻辑已经到位

>下行

>代码膨胀：我们已经很大的Rails Web应用程序的更多代码

如果我们要在现有应用程序中开发移动网络,我们将采用这种方法来呈现移动视图 – http://scottwb.com/blog/2012/02/23/a-better-way-to-add-mobile-pages-to-a-rails-site/

任何见解将不胜感激.

最佳答案 如果您设计网站以便为任何设备使用相同的代码库,那么您将有9次中有10次会变得更好,以便它可以智能地适应您的设备,从而呈现最重要/最有用的内容/功能每个设备基于样式表或渲染/非渲染的运行时选择.请记住,与6年前不同,您今天对移动设备的主要关注不是缺乏处理能力,而是不同的屏幕尺寸和不同的输入.

通常,移动用户不希望看到您网站的残缺或剥离版本.他们希望看到您网站的可用版本.可用的含义各不相同,但它通常意味着最常用的功能非常容易访问,而更隐蔽的选项被隐藏得更低或者可能没有那么优化.
可用可能意味着您为它们提供与桌面上完全相同的功能,但可以在移动设备上更好地呈现.或者你删除了在移动设备上没有意义的东西.但是,如果你设置它,你将不得不为自己做更多的事情,以便你必须维护两个代码流,或者一个早期分支的代码流,或者一个根本不同的应用程序.这是一个更多的测试,更多的编码,以及更多的破损可能性.

我们遵循这种方法,它适用于我们非常小的开发团队 – 我们已成功使用它,以便我们可以使用相同的代码库为不同的客户运行两个不同的实现 – 一个非常复杂的桌面优先UI以及一个非常简化的移动优先应用程序：

>假设所有设备都将访问相同的URL
>假设90％的设备优化将使用CSS媒体查询完成,7％将使用jQuery黑客完成,3％将在早期使用浏览器检测完成
>构建您的应用程序,以便通过代码(ApplicationController中的逻辑？Rack Midleware？)轻松启用/禁用各个UI组件或模块.我们通过将我们各自的“小部件”放在部分中来实现这一点,这些部分包含用于启用小部件的检查(在Rails.config中或作为ApplicationController中的实例变量),以便我们可以关闭是否返回相应的HTML到浏览器
>使用CSS媒体查询不仅可以设置字体和宽度的样式,还可以重新排列菜单/功能和其他UI项目,以便它们可以处理您需要的不同外形

通常,如果您要为移动设备构建已编译的应用程序并且将使用设备的UI库在UI上进行繁重的工作,而不是使用移动API方法对您最有用.在服务器上生成的HTML.再说一次,如果您选择使用Backbone.js或Angular.js等方法来处理前端显示,那么使用仅限API的方法可能也是一个很好的架构供您遵循.但是接下来你会越走越多Rails.