Search code examples
ruby-on-railsweb-servicesmobile-websiteweb-architecture

How to design/organize/architect the development of mobile web within a Rails application?

I'm going to do my best to phrase this as an answerable question and less as the start of a discussion.

The essence of my question is, in your experience, is it better to develop a mobile web version of your website as a separate app that uses your website as an API or to develop from within the same Rails app that serves up your website?

I'm currently planning how we're going to implement it and here are the upsides/downsides for each as I seem them.

Separate application for mobile web

  • Upsides
    • Performance: less overhead from existing website = better performance
    • Smaller footprint: easier to organize and cleaner app to work/develop on
    • De-coupled: would force us to architect services for desktop/mobile
  • Downsides
    • Subdomain: would have to use m.thredup.com so mobile traffic could be routed to the separate app
    • Session management: would have to deal with authentication on multiple apps/domains
    • Local development is harder: another service to maintain for developing locally
    • Branch management: new code requires separate branches for web app + mobile app

Same application for mobile web

  • Upsides
    • URL Scheming: able to use same URLs for desktop + mobile (easier for sharing)
    • Session management: able to use existing user sessions
    • Quicker implementation: shorter project timeline as all back-end logic is already in place
  • Downside
    • Code bloat: more code for our already large Rails web app

If we were to develop mobile web within our existing app, here's the approach we would take for rendering mobile views - http://scottwb.com/blog/2012/02/23/a-better-way-to-add-mobile-pages-to-a-rails-site/

Any insights would be greatly appreciated.

Solution

  • You will 9 times out of 10 be better off if you design the site so that you can use the same codebase for any device, so that it adapts intelligently to your device, and so that it renders the most important/useful content/functionality for each device based on stylesheets or runtime choices of rendering/non-rendering. Remember that, unlike 6 years ago, your primary concern with mobile devices today isn't lack of processing power, but rather a different screen size and different input.

    Generally, mobile users do not want to be seeing a crippled or stripped version of your site. They want to see a usable version of your site. What Usable means varies, but it often means that the most frequent functions are very easy to access, while the more obscure options are buried a little bit lower or perhaps not quite as optimized. Usable might mean that you give them exactly the same functionality as on a desktop, but styled to present better on the mobile. Or that you cut out things that make no sense on a mobile. But you'll be making it much harder for yourself if you set it up so that you have to maintain two code streams, or one code stream that branches very early on, or a fundamentally different application. It's a lot more testing, a lot more coding, and a lot more likelihood of breakage.

    We follow this approach, and it works well for our very small development team -- we've successfully used it so that we can use the same codebase to run two different implementations for different customers -- one a very complex desktop-first UI as well as a very streamlined mobile-first app:

    • assume that all devices will access the same URL
    • assume that 90% of device optimizations will be done using CSS media queries, 7% will be done using jQuery hacks, and 3% will be done using browser detection very early on
    • build your application so that the individual UI components or modules can be easily enabled/disabled through code (logic in ApplicationController? Rack Midleware?). We do this by putting our individual "widgets" in partials that are wrapped with checks for enablement of the widget (either in Rails.config or as an instance variable in side ApplicationController) so that we can turn off whether we return the corresponding HTML back to the browser
    • use CSS media queries not only to style fonts and widths but also to rearrange menus/functions and other UI items so that they work on the different form factors you require

    Generally, the API-for-mobile approach will be of most use to you if you're going to be building a compiled app for a mobile device and are going to be doing the heavy lifting on the UI using the device's UI libraries rather than HTML generated on the server. Then again, if you choose to use an approach such as Backbone.js or Angular.js to handle your front-end display, then going with an API-only approach MIGHT be also a good architecture for you to follow. But then you're stepping outside of Rails a lot more.