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

Re:Ruby’s Rack Push: Decoupling the real-time web applicatio... by jkarneges on Tuesday May 01, 2018 @07:55PM (#16972863)

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. :)

[ Parent | on HN ]

Re:Ruby’s Rack Push: Decoupling the real-time web applicatio... by qaq on Tuesday May 01, 2018 @07:59PM (#16972886)

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.

[ Parent | on HN ]

Re:Ruby’s Rack Push: Decoupling the real-time web applicatio... by jkarneges on Tuesday May 01, 2018 @09:08PM (#16973264)

Can you really live upgrade an Erlang process without disconnecting TCP connections it is using? If so that's really interesting, would be curious to learn more.

[ Parent | on HN ]

Re:Ruby’s Rack Push: Decoupling the real-time web applicatio... by jeremyjh on Tuesday May 01, 2018 @10:17PM (#16973556)

Yes, you don't actually restart the Erlang VM; it loads your new application code (byte code) and sends the next message/request it receives to the newly loaded module. The default state for any process is to be blocked on receiving a new message. Processes in the middle of an I/O operation for example, will get the new code after it finishes that operation and waits to receive its next message.

[ Parent | on HN ]

Re:Ruby’s Rack Push: Decoupling the real-time web applicatio... by jimktrains2 on Tuesday May 01, 2018 @09:24PM (#16973339)

I'm not familar with Erlang, but applications like HAProxy don't upgrade the process in use, but only new connections.

[ Parent | on HN ]

Re:Ruby’s Rack Push: Decoupling the real-time web applicatio... by wlll on Wednesday May 02, 2018 @10:02AM (#16976936)

May be of interest: https://news.ycombinator.com/item?id=10669131

[ Parent | on HN ]

Re:Ruby’s Rack Push: Decoupling the real-time web applicatio... by lazyloop on Wednesday May 02, 2018 @04:29AM (#16975039)

That's what Perl/Mojolicious does too.

[ Parent | on HN ]

Re:Ruby’s Rack Push: Decoupling the real-time web applicatio... by bowild on Wednesday May 02, 2018 @07:33AM (#16975919)

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.

[ Parent | on HN ]