3 ms·

For people in a similar situation, I'd strongly suggest giving Phoenix (on Elixir) a look. It's a "boring" Rails style server side rendered web framework, but w

For people in a similar situation, I'd strongly suggest giving Phoenix (on Elixir) a look. It's a "boring" Rails style server side rendered web framework, but with a few extra powers: * Elixir is a great functional programming language * When your backend needs to do more complex or longer running work it's just more Elixir rather than complicated architecture involving task queues etc. (because you have the concurrency of the BEAM to manage it) * You have options like LiveView for your frontend. You don't have to use it, but it's there. I agree with what you said about testability for Lambda style architectures. How do you spin up an offline version of some or all of that to see if it works? The BEAM world is nice for me because you can run a similar architecture of separate things (albeit all in one language), but have a much better testing setup.

bdcravens 6y ago
> You have options like LiveView for your frontend Worth noting Stimulus Reflex uses the same approach as LiveView (most stacks have similar options)
- rkangel 6y ago
  The Phoenix framework was created by Chris McCord. He was a long time Rails developer who tried to create a LiveView equivalent in Ruby/Rails but concluded that the concurrency capabilities just resulted in too many edge cases that didn't work well. That process led to him working more with Erlang and Elixir, then creating Phoenix. I have never used Stimulus or Stimulus Reflex, but based on his output Chris is a smart guy and an excellent developer who's opinion I therefore give some weight to.
  - jaredcwhite 6y ago
    No doubt, but there are some pretty awesome wizards working on StimulusReflex (and CableReady which it sits atop) as well, so I think it mostly depends on if you're keen to program in Elixr or Ruby.
heipei 6y ago
I'm curious, and I know this is a random thread to post this question, but how do you handle the fact that the Elixir process might be shut down with regards to necessary persistence of any message queues? Put differently: I consider both message queues and databases in my system to be part of the stateful workloads and the web app part of the stateless workloads (can-be-killed-at-any-time). How do you handle the case where your stateful workload (queueing) now lives within your Elixir process which might be killed at any instance?
- jgautsch 6y ago
  You can add a kill/shutdown message handler and move your state somewhere else before the process dies.
- rkangel 6y ago
  The terminology is a bit ambiguous here with the word 'process' so I'm not 100% sure precisely what you're asking. The BEAM (Elixir VM) uses the the term 'process' to describe its green threads/fibres. The BEAM runs as one OS process, with a thread per core of your machine and schedules each of the application green threads onto one of those threads. BEAM processes are cheap and quick to create and come and go regularly. The BEAM itself is very stable and will stay up permanently (potentially even through SW upgrade if you want). Whenever I say process below I mean a BEAM process. When you use Phoenix, the Web framework creates a process to handle the specific request. By default everything you do happens in that process (give or take some database stuff). If you make a programming error that process will 'crash' (again a BEAM term that is more like an exception) and the user will get an error. No other processes will be affected, regardless of whether they are to do with other requests or anything else. If you want a work queue, you would create a separate set of BEAM processes (or maybe just one), probably at startup. In your request handling you would send a message to that work queue process asking it to do things. Your request can block (not affecting any other requests) waiting for it if necessary, or it can return so you can get the result later. If the Web request times out or crashes or whatever, that will kill the handler process, but will leave the work queue process alone. One other note - under the hood it's all message passing between processes, but to the programmer each process is probably just a Gen Server (an abstraction) and the message send and reply is just a function call. But normal Phoenix stuff doesn't even have that because the Web server does the 'process machinery' for handling requests.

bdcravens 6y ago

> You have options like LiveView for your frontend Worth noting Stimulus Reflex uses the same approach as LiveView (most stacks have similar options)

rkangel 6y ago
The Phoenix framework was created by Chris McCord. He was a long time Rails developer who tried to create a LiveView equivalent in Ruby/Rails but concluded that the concurrency capabilities just resulted in too many edge cases that didn't work well. That process led to him working more with Erlang and Elixir, then creating Phoenix. I have never used Stimulus or Stimulus Reflex, but based on his output Chris is a smart guy and an excellent developer who's opinion I therefore give some weight to.
- jaredcwhite 6y ago
  No doubt, but there are some pretty awesome wizards working on StimulusReflex (and CableReady which it sits atop) as well, so I think it mostly depends on if you're keen to program in Elixr or Ruby.

heipei 6y ago

I'm curious, and I know this is a random thread to post this question, but how do you handle the fact that the Elixir process might be shut down with regards to necessary persistence of any message queues? Put differently: I consider both message queues and databases in my system to be part of the stateful workloads and the web app part of the stateless workloads (can-be-killed-at-any-time). How do you handle the case where your stateful workload (queueing) now lives within your Elixir process which might be killed at any instance?

jgautsch 6y ago
You can add a kill/shutdown message handler and move your state somewhere else before the process dies.
rkangel 6y ago
The terminology is a bit ambiguous here with the word 'process' so I'm not 100% sure precisely what you're asking. The BEAM (Elixir VM) uses the the term 'process' to describe its green threads/fibres. The BEAM runs as one OS process, with a thread per core of your machine and schedules each of the application green threads onto one of those threads. BEAM processes are cheap and quick to create and come and go regularly. The BEAM itself is very stable and will stay up permanently (potentially even through SW upgrade if you want). Whenever I say process below I mean a BEAM process. When you use Phoenix, the Web framework creates a process to handle the specific request. By default everything you do happens in that process (give or take some database stuff). If you make a programming error that process will 'crash' (again a BEAM term that is more like an exception) and the user will get an error. No other processes will be affected, regardless of whether they are to do with other requests or anything else. If you want a work queue, you would create a separate set of BEAM processes (or maybe just one), probably at startup. In your request handling you would send a message to that work queue process asking it to do things. Your request can block (not affecting any other requests) waiting for it if necessary, or it can return so you can get the result later. If the Web request times out or crashes or whatever, that will kill the handler process, but will leave the work queue process alone. One other note - under the hood it's all message passing between processes, but to the programmer each process is probably just a Gen Server (an abstraction) and the message send and reply is just a function call. But normal Phoenix stuff doesn't even have that because the Web server does the 'process machinery' for handling requests.