5 ms·
Phoenix shares many features with Ruby on Rails, e.g. a strong MVC model, an integrated ORM, a routing system, etc. What Phoenix on Elixir excels at is concurre
by ghayes 11y ago
Phoenix shares many features with Ruby on Rails, e.g. a strong MVC model, an integrated ORM, a routing system, etc. What Phoenix on Elixir excels at is concurrency and distributed computing. For applications, this means you can have many active web sockets, for instance, where Rails applications tend to break down when you have too many active connections. Phoenix uses erlang processes for these tasks, which are lightweight and can number millions on a single machine.
As an example, Heroku uses cowboy (the erlang web server that Phoenix uses) for load-balancing incoming connections to all Heroku applications. The erlang VM (BEAM) is great for these types of highly concurrent, highly available, distributed tasks. The original use case for erlang was highly available phone switching for Ericsson.
- agopaul 11y agoThis is very interesting as Phoenix could become the next Rails. I loved Rails and ruby, for the most part, but ruby MRI still lack 'Native Threading', and Jruby isn't viable if you are using external C extensions. To overcome the lack, I've used Resque (or beanstalkd in PHP, which has the exact same problem) as a background job manager, but then I had to write my own layer and rely on the database to handle the 'job' result. Which parts of the framework leverage the concurrency model, other than the routing/request handling part?
- oomkiller 11y agoThe best example is probably channels. The framework doesn't really have to provide you anything for you to be able to use concurrency. For a personal example, I was able to use RethinkDB changefeeds easily with channels: https://github.com/bbhoss/elixir_friends/blob/master/web/channels/tweets_channel.ex#L17 https://github.com/bbhoss/elixir_friends/blob/master/web/cha... I just start another process when you join a channel, and that process sets up the changefeed and pushes changes to the client in the form of HTML, allowing messages to be received and processed by the channel. You can watch the full presentation here: https://www.youtube.com/watch?v=aWaleoYD1Ro https://www.youtube.com/watch?v=aWaleoYD1Ro Slides: http://www.slideshare.net/bbhoss/otp-phoenix-channels-rethinkdb http://www.slideshare.net/bbhoss/otp-phoenix-channels-rethin... Another example is sending email. In Rails, you need to have something like Sidekiq (or now Activejob) to be able to background the job so it doesn't block the response to the client. In Phoenix, you can simply spawn a process to do the work and move on. Sure, you might want a system like exq to keep track of things a bit better, but ultimately the concurrency primitives provides by Erlang/Elixir allow you to do everything you need.
- agopaul 11y ago@oomkiller: again, so interesting, especially when used in combination with RethinkDB. I'll have a look at the slides
- nathan_long 11y agoAnother example: I work on a Rails app where the user submits a request to us, and we have to talk to an API to respond. We can't afford to leave the connection open with the user, so we make them poll for results. My understanding is that the cheap processes of Elixir would mean we could just keep a connection open to that user if we wanted to. Similarly, no need for a background processing framework like ActiveJob; just use processes.
- nfm 11y agoWhat webserver are you using? Running puma in threaded mode, even on MRI, should allow your external API calls to run in parallel - this might simplify things a bit :)
- nathan_long 11y agoMaybe so, but the fact that Rails includes Active Job shows that this is a common problem.
- jake_morrison 11y agoThat's right. Because Elixir is 10x faster than Rails, we don't need to worry about caching so much. And because it supports cheap concurrency, we don't need to offload long running tasks to a background task. So the overall structure is simpler. And this works across the whole architecture. One of our projects right now is a mobile medical application for medical where caregivers communicate in real time with a number of patients. We have the mobile app talking to the server using a REST API and real time messaging for chat. The caregivers can communicate with the server using a web application with integrated web chat or via an XMPP client. And we have the normal public web and admin CRUD. All via a single server process in a single language. This is what Elixir/Phoenix was made for, it enables a new generation of modern apps.