如何在Rails应用程序中设计/组织/架构移动web的开发？

Question

我将尽我最大的努力把这句话说成是一个可以回答的问题，而不是一个讨论的开始。

我问题的本质是，在您的经验中，是更好地开发一个移动web版本的您的网站作为一个单独的应用程序，使用您的网站作为API，还是开发在同一个Rails应用程序服务您的网站。

我目前正在计划如何实现它，下面是我所看到的每一个方面的优点/缺点。

移动web的单独应用程序

• 正面
  • 性能:减少来自现有网站的开销=更好的性能
  • 更小的足迹:更容易组织和更清洁的应用程序的工作/开发
  • 解耦合:将迫使我们为桌面/移动设备设计服务。

​

• 缺点
  • 子域:必须使用m.thredup.com，以便移动通信可以路由到单独的应用程序。
  • 会话管理:必须处理多个应用程序/域上的身份验证。
  • 地方发展更加困难:另一项为本地发展而维护的服务
  • 分支管理:对于web应用程序+移动应用程序，新代码需要单独的分支

​

移动web的相同应用程序

• 正面
  • URL计划:能够在桌面+移动设备上使用相同的URL(更容易共享)
  • 会话管理:能够使用现有的用户会话
  • 更快的实现:缩短项目时间表，因为所有后端逻辑都已经到位。

​

• 下行
  • 代码膨胀:我们已经很大的Rails web应用程序的更多代码

​

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

任何见解都将不胜感激。

Answer 1

如果您设计站点，使您可以对任何设备使用相同的代码基，以便它能够智能地适应您的设备，并且根据样式表或呈现/非呈现的运行时选择来呈现每个设备最重要/有用的内容/功能，那么您将有9次更好的选择。请记住，与6年前不同的是，如今移动设备的主要关注点不是缺乏处理能力，而是屏幕大小和输入的不同。

一般情况下，移动用户不想看到你网站的残废或被剥去的版本。他们希望看到一个可用的版本的网站。可用的含义各不相同，但这通常意味着最频繁的函数很容易访问，而更晦涩的选项被隐藏得稍微低一点，或者可能没有优化得那么好。可用可能意味着您提供了与桌面完全相同的功能，但在移动平台上呈现得更好。或者你删掉了那些在手机上没有意义的东西。但是，如果您将其设置为必须维护两个代码流，或一个很早就分支的代码流，或者一个根本不同的应用程序，您就会变得更加困难。这是更多的测试，更多的编码，更多的破坏可能性。

我们遵循这种方法，它对我们规模非常小的开发团队非常有效--我们成功地使用了它，这样我们就可以使用相同的代码库为不同的客户运行两种不同的实现--一个是非常复杂的桌面用户界面，另一个是非常精简的移动第一应用程序：

• 假设所有设备都将访问同一个URL
• 假设90%的设备优化将使用CSS媒体查询，7%将使用jQuery hack，3%将使用早期浏览器检测。
• 构建应用程序，以便可以通过代码( ApplicationController中的逻辑)轻松地启用/禁用单个UI组件或模块。衣架餐具？)。为此，我们将单独的“小部件”放在带有小部件启用检查的部分中(无论是在Rails.config中还是作为侧ApplicationController中的实例变量)，这样我们就可以关闭是否将相应的HTML返回浏览器。
• 使用CSS媒体查询不仅可以为字体和宽度设置样式，还可以重新排列菜单/函数和其他UI项，使它们能够处理所需的不同形式的因素。

一般来说，如果您要为移动设备构建一个编译过的应用程序，并且要使用设备的UI库而不是服务器上的HTML来完成UI的繁重工作，那么API对移动设备的方法将是最有用的。然后，如果您选择使用Backbone.js或Angular.js之类的方法来处理前端显示，那么只使用API的方法可能也是您需要遵循的一个好架构。但是接下来你会走出更多的铁轨。

Answer 2

在我看来，最基本的信息之一就是“为什么？”你需要考虑你的预算，时间表和工作的最后期限。

如果您使用类似于马修·詹姆斯·泰勒的令人敬畏的布局的液体布局，它将根据可用的屏幕大小调整大小，我看到需要移动特定模板的唯一原因是为了提供特定的css样式，使您的视图看起来更像移动应用程序。

我不认为表演是个问题。如果您有一个现有网站的性能开销，而您正在为移动设计这些性能问题，那么为什么不也为非移动设计这些问题。例如，设计一个具有液体布局的移动站点，并使其能够用于桌面/平板查看。这可能是一个很好的机会来重新设计整个网站，使之更有表现力。

我发现你真的有两种选择，取决于预算和时间尺度

1)同时设计一组全新的模板，同时使用液体布局设计性能问题，以便随着时间的推移将现有布局转换为新布局。

2)重新设计现有的模板和功能，使之成为一个移动友好网站。

无论哪种方式，您的桌面和平板电脑用户都会得到好处，但这取决于您的最后期限和预算，在短期内，选项1是越来越便宜、更快的方式，而选项2则是更便宜、更快的方法。在我看来，如果没有为移动用户和桌面/平板电脑用户提供相同的模板，就会使某人处于不利地位，从而为所有用户提供尽可能好的体验。

这真的是你的项目经理的决定。

基于注释的更新--

在这种情况下，我会开发一个单独的移动应用程序。我甚至会考虑使用替代技术来直播更新的数据。Rails实况流和Node.js之间有一个很好的比较。

无论你是否选择引进新技术，通过为移动用户提供一个单独的应用程序，你将提供最终的移动体验，并能够完全专注于此。

我不认为不同的域名是太大的问题与SEO。你应该能够利用现有的可见性从主要网站和一个单独的领域为移动，你可以很好地提高你的SEO排名，而不必做很多额外的推广。

我想你已经对最好的前进方式得出了自己的结论，我能给你的最好的建议就是告诉你给自己多一点思考的时间，让你选择的解决方案更加坚定，我相信如果这是正确的，它只会让你“感觉”对你正确。

没有人比你更了解你的业务，如果不参与项目和业务，就不可能说出最终的最佳选择。