Our app also has a "real-time" interface. Our app is a procurement app that orchestrates real-time reverse auctions. Many users sit down, log in, and participate in an auction at the same time. There are events that appear to update in real time to the user, but are actually updated by simple polling. We considered going web sockets until we looked at what we'd gain and what we'd lose.
Polling actually scales out really well. With a socket, your users' connection is always consuming a socket, which is considered a resource. Scaling of resources with web sockets is 1:1 with concurrent users. With polling, you're essentially using time division to serve (potentially) many more users with lower actual concurrency. App server concurrency is usually the first bottleneck. If your app requests are served quickly, say 100ms, you can serve 10 requests per second with a single app server process/thread. If users are happy to get updates in one second, you have the ability to serve 10 users with a single app sever process/thread. We use a polling interval of 3 seconds and the illusion of real-time is upheld. People simply expect things to take some time. Once you go web sockets, the server handling the web socket based requests must have a socket available per user. Fortunately, there are Rails app servers that offer better concurrency these days, but that concurrency can still be put to good use with polling. The other option, which it looks like you've already identified, is to use a PaaS provider to outsource that bit. As you can see by Pusher's pricing, concurrency with web sockets gets expensive quickly. Just food for thought. On Friday, March 13, 2015 at 8:58:13 PM UTC-4, Chris McCann wrote: > > I'm trying to put together a design for showing realtime data updates in a > Rails app in response to calls to an API from mobile devices. > > We recently released an Android and iOS version of our first app, Vor > Vision, which allows people to scan images that have an invisible code > embedded in them. Think "invisible QR code", only without the ugly. You > can check it out here: vorvision.com > > I've built a Rails backend app that hosts the API and allows a user to see > scans of their images in realtime. Currently I just do simple Ajax polling > but I want to significantly improve the app via a websockets-type updating > system. > > When a mobile user scans an image, the owner of that image, if they are > looking at the dashboard at that moment, should see the scan count for that > image increment, along with the geolocation of the latest scan, possibly > with a little highlighting or other chrome to call the user's attention to > the update. > > I haven't used React.js, Angular.js or any of the other client-side JS > frameworks, but one of these seems like a good fit for elegantly updating > the client side data elements. The Flux-style architecture (from Facebook) > seems possibly useful, if it's not overkill. > > Using server sent events (SSE) or websockets (via Pusher) seems like a > good fit for the server side. > > Our local Planning Center Online published this: > http://developers.planningcenteronline.com/2014/09/23/live-updating-rails-with-react.js-and-pusher.html > > Has anyone else done this or something similar? If so, what technology > stack did you use? Got any pointers for me? > > Thanks all, > > Chris > -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
