8 ms·

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,

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 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 8y 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.
- jkarneges 8y ago
  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.
  - jimktrains2 8y ago
    I'm not familar with Erlang, but applications like HAProxy don't upgrade the process in use, but only new connections.
    - lazyloop 8y ago
      That's what Perl/Mojolicious does too.
    - wlll 8y ago
      May be of interest: https://news.ycombinator.com/item?id=10669131 https://news.ycombinator.com/item?id=10669131
  - jeremyjh 8y ago
    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.
bowild 8y 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.

qaq 8y 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.

jkarneges 8y ago
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.
- jimktrains2 8y ago
  I'm not familar with Erlang, but applications like HAProxy don't upgrade the process in use, but only new connections.
  - lazyloop 8y ago
    That's what Perl/Mojolicious does too.
  - wlll 8y ago
    May be of interest: https://news.ycombinator.com/item?id=10669131 https://news.ycombinator.com/item?id=10669131
- jeremyjh 8y ago
  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.

bowild 8y 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.