Ruby’s Rack Push: Decoupling the real-time web application from the web

https://bowild.wordpress.com/2018/05/01/rubys-rack-push-decoupling-the-real-time-web-application-from-the-web/

by ksec • 8 years ago

140 18 8 years ago

bowild.wordpress.com

33degrees• 8 years ago

Interesting: I wasn't aware of the two servers mentioned in the article, looks like it's time to try out a new stack!

pmontra• 8 years ago

A separate websocket server is a huge pain in any language. A great feature of Phoenix for Elixir is that the webserver and the websocket server are in the same process tree.

I'll try this new approach for Ruby and see how it scales.

jkarneges2• 8 years ago

I agree separate servers can be a pain, especially in a development environment. But I also believe separate servers can be a useful architecture in production, regardless of whether the web framework being used is thread-per-connection or event-driven.

Using separate servers can make it possible to upgrade/restart the backend process without necessarily disconnecting clients. It can allow managing/scaling the front tier separately from the back tier, which can make sense if you already do this for your request/response stuff (e.g. cache tier separately managed/scaled from web service tier). It's also a sane way to manage long-lived connections from a function backend like AWS Lambda, so the function doesn't have to run for the entire duration of a connection.

I created Pushpin (https://pushpin.org) to attempt to standardize this split-process architecture for all languages. It is a bit of a pain in a development environment, but a lot of fun in production. :)

qaq• 8 years ago

You bring up a lot of important points none of which apply to Elixir/Phoenix. In Erlang/Elixir world you can even live upgrade a running system to a new release without restart.

bowild• 8 years ago

You have great points as far as application architecture is concerned.

However, as far as server architecture goes - even if we separate the application into two different processes (HTTP and WebSockets), the current situation is that the WebSocket server in Ruby will run two IO reactors / "servers" internally (unless you use a custom WebSocket enabled server such as iodine).

This post is more about the way WebSocket servers are implemented using Rack than about the question of application architecture.

Kiro• 8 years ago

Is this how it works in Node.js as well?

sametmax• 8 years ago

It does have drawbacks, but having use crossbar.io for python/js/java/php, the benefit is huge if it abstract away the transport and gives you well crafted high level primitives such as routed rpc and pubsub out of the box.

Also, you can switch to microservices later for peanuts.

lazyloop2• 8 years ago

One of the reasons i really like Perl is Mojolicious. Thanks to it we don't need separate servers for websockets and HTTP anymore. https://mojolicious.org

vgy7ujm• 8 years ago

Mojolicious rocks!

diminish• 8 years ago

It's the first time I hear about new web servers in Ruby after thin, passenger, unicorn, puma. Anyone has real life applications with Rails/Sinatra on iodine or agoo?

strzibny• 8 years ago

Also just learned about Agoo. Great to see progress in this area:)

haffla2• 8 years ago

First time I hear about them, too. Googling Rails + Iodine doesn't yield much information. I'm going to try replacing Puma in one of my Rails apps. The benchmarks suggest that this could be a real win.

haffla2• 8 years ago

I'm on third place in Google for "rails iodine" now, lol

Ruby’s Rack Push: Decoupling the real-time web application from the web

Related Stories