Taking a moment to thank everyone on this thread! Good stuff! On Sun, Mar 15, 2015 at 11:13 AM, Chris McCann <[email protected]> wrote:
> I came across this StackOverflow post regarding the different options for > realtime or near-realtime data updates in a web app, all of which are > applicable to Rails: > > > http://stackoverflow.com/questions/11077857/what-are-long-polling-websockets-server-sent-events-sse-and-comet?rq=1 > > Chris > > On Sun, Mar 15, 2015 at 11:08 AM, Chris McCann <[email protected]> > wrote: > >> Thanks for the suggestion of long polling. I'm definitely going to look >> into that as an option. >> >> On Sat, 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 a topic in the >>> Google Groups "SD Ruby" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/sdruby/sBP7M1n4j1U/unsubscribe. >>> To unsubscribe from this group and all its topics, 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. > -- -- 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.
