Realtime updates in Rails from mobile API

[Chris McCann]

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

[Nicholas Shook]

I have used Pusher and dug it. The article you shared about React looks pretty awesome though I just used it w/ jQuery. AFAIK, you can get up to speed with Pusher first before delving into a client-side JS framework if you wanted to punt that decision.

[Alex Egg]

Chris,

A simple in-place upgrade to you system would be to use long-polling instead of traditional polling. This would give you near real-time input response and not the complexity of a web socket solution. It's hard to get a true real time system using traditional request/response lifecycle (rails) unless you have some type of evented server a la node, event machine.  Also, I'm pretty sure the planning center solution you posted will (the after_commit) callback will only work in a single-threaded environment. 

Unless you really want to go w/ web sockets, I would suggest MessageBus (the messaging system used in Discuss) and long polling. Has worked great for me.

— 

Thanks,
Alex Egg

켜짐 2015년 3월 13일 에서 오후 5:58:16, Chris McCann (testf...@gmail.com) 작성됨:

--
--
SD Ruby mailing list
sdr...@googlegroups.com
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 sdruby+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ylan Segal]

Chris,

I came across this the other day while trying to solve the same problem:

https://github.com/chrismccord/sync

I only tested a quick POC, nothing in production. It looked promising. 

I would consider something like that if you are trying to avoid a full-fledged client JS solution. 

 --  

Ylan Segal

--

[bradleyland]

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.

[Ylan Segal]

Thanks for taking the time to write that. It's a well thought out argument!

 -- 

Ylan Segal

--

[Chris McCann]

Thanks for the suggestion of long polling.  I'm definitely going to look into that as an option.

--

--
SD Ruby mailing list
sdr...@googlegroups.com
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 sdruby+un...@googlegroups.com.

[Chris McCann]

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

[Etienne de Bruin]

Taking a moment to thank everyone on this thread!  Good stuff!

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 sdruby+un...@googlegroups.com.