Thanks for taking the time to write that. It's a well thought out argument!
-- Ylan Segal > On Mar 14, 2015, at 6:51 PM, bradleyland <[email protected]> wrote: > > 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. -- -- 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.
