6 ms·

What are people finding as the real sweet spots for Phoenix? I have used Erlang very successfully in a semi-embedded context, but that's quite different from a

by davidw 6y ago

What are people finding as the real sweet spots for Phoenix? I have used Erlang very successfully in a semi-embedded context, but that's quite different from a web server that can usually be scaled horizontally pretty easily. One obvious one is if you have to hold open a lot of concurrent connections like web sockets. It'd be great for that. Others?

ch4s3 6y ago
It's pretty great anywhere that you might use Rails or Django, but if you expect spike in traffic that are hard to predict you get nice stable worst case latency. I think it's also really good if you need to hold state server side for any reason.
- davidw 6y ago
  Rails has a ton of high quality code available for it. It looks to me like Phoenix is certainly 'good enough' for a lot of tasks, but it just hasn't been around as long. I'm looking for those use cases where someone picked Phoenix and it was just clearly a better tool than, say, Rails because of X, Y, and Z, despite maybe being inferior for one or two other things.
  - ch4s3 6y ago
    Having done both, I think Rails has a ton of baggage around ActiveSupport and ActiveRecord that are full of gotchas. Ecto prevents N+1 queries by default, which I think is clearly better. I also think that the lack of lifecycle hooks in Ecto is a better decision than the pile of foot guns in ActiveRecord hooks. I would also argue that Plug is a large improvement over Rack, and the idea of explicitly passing a single context map all the way through the request is just a better way to build http responses. I also think that the Fallback controller is obviously a better way to handle common errors. Anything related to web sockets will be leagues better in Elixir, because the BEAM is built to do a thing like that. SSR html as a compiled linked list is a better idea than runtime string interpolation. Sure, Rails has libraries for everything, but some of the core parts just aren't a nice. So if you don't need all of that breadth of ecosystem then Phoenix is a better choice IMHO having worked professionally with both for a number of years.
    - aantix 6y ago
      >Ecto prevents N+1 queries by default, which I think is clearly better How does it know what associations to eagerly load without knowing about the views? It can't eagerly load all of the data on complex objects.
      - AlchemistCamp 6y ago
        It doesn't eagerly load anything. It preloads exactly what you tell it to. Ecto Repo vs Active Record: https://youtu.be/IFKG4Hgt-zM https://youtu.be/IFKG4Hgt-zM
        aantix 6y ago
        So you have to be explicit in what to "preload"? How does that differ from specifying an includes on associations for eager loading? It's not saving you any mental energy; you still have to discern what should and shouldn't be loaded up front.
        dmpk2k 6y ago
        The question was regarding N+1. If you're not careful with ActiveRecord, you get that. With Ecto, it's impossible. Ecto has its own drawbacks, but its strong suit is predictability.
        aantix 6y ago
        N+1 is because lazy loading is by default in ActiveRecord. Because it doesn't know anything about your object graph and what associations are needed, so it just loads data as it's encountered. That's a reasonable default. You add includes as you know more about your data and what associations are needed in specific contexts. Eager loading is an optimization, not a prerequisite.
    - nickjj 6y ago
      > Ecto prevents N+1 queries by default, which I think is clearly better. To be fair... If you want to protect yourself from these with Rails you can install Bullet[0] and get protection through in your face notifications, and you have the option to let it slide because you're taking advantage of caching with Rails and in this case you know what you're getting into and the N+1 query with caching ends up being better because you understand your domain. Rails also has the strong migrations[1] gem which is a huge help for not shooting yourself in the foot for running migrations in production by helping you avoid table locks and other issues / errors. But AFAIK there's no Ecto equivalent, but strong migrations is really really useful. Rails also has the data-migrate[2] gem which is a nice little abstraction for splitting out your schema changes and backfilling data in an automated way. There's nothing like this with Ecto. This one isn't as useful as strong migrations IMO but it's still very handy to have this problem taken care of for you without having to re-invent a new strategy in every project or copy code over. Basically all 3 of these things are something I'd use in every Rails project but with Phoenix I wouldn't have these things except for N+1 query protection. I'm pretty sure you could technically create strong migrations and data-migrate for Ecto but the reality of the situation is today neither of them are available and there's no sign of them coming anytime soon. Meanwhile strong migrations has had ~6 years worth of real world testing at this point. [0]: https://github.com/flyerhzm/bullet https://github.com/flyerhzm/bullet [1]: https://github.com/ankane/strong_migrations https://github.com/ankane/strong_migrations [2]: https://github.com/ilyakatz/data-migrate https://github.com/ilyakatz/data-migrate
  - cancan 6y ago
    I can add a bit of my experience. I used Rails here and there since 2.3 and have followed Elixir since its inception. - Channels in Phoenix are just a joy to use compared to ActionCable. This is partly due to the language (pattern matching, especially) but not having to deal with a Redis instance (and/or AnyCable) is also appealing. It just works out of the box and is ridiculously performant. - I find the Repository pattern much easier to wrap my head around than ActiveRecord. I feel like with Rails, I always have to know the state of an object whereas w/ Ecto, things are more explicit. I know some people prefer AR here, but I prefer not making an accidental query. - I feel like I am lost every time I'm in a Rails project with so many abstractions now. Maybe this is me being a curmudgeon, but I remember being able to trace request all the way from where it hits the machine (say, Nginx) to the HTML rendering even with Rack. Now, if I had to do something similar, there are so many layers to peel. This is again partly due to the language, and partly to Rails' age.
news_to_me 6y ago
In terms of language, Phoenix is a complete replacement for Rails for me. I feel more comfortable growing a functional codebase, and the BEAM means I don't have to worry about scaling as soon as I would with Rails. I think it's a good fit for when you want to do more with a small, experienced team. I would reach for Rails when I'm concerned about finding developers (Elixir devs are fewer and more expensive, generally), or if there are Ruby libraries I want that aren't available in Elixir.
- blunte 6y ago
  I fear it would be difficult to hire Elixir people as well, but now I realize it's actually also hard to hire decent Ruby/Rails people. Honestly I think we should just accept anyone who can demonstrate thinking and programming skills of any language and then plan for 2-3 months of ramp-up time to get them into our language of choice.
  - news_to_me 6y ago
    I agree, and to be clear I've never really been in a position to worry about hiring anyway. But I would imagine building a medium/large team with varying experience levels (including juniors) would be easier with a more established framework like Rails.
  - danjac 6y ago
    I'd be happy (if I were job-hunting) to be able to try out a different language/platform every so often. Now and again I'll play with, say, Ruby or Elixir or whatever. But I know that I'll never get a job working with these languages because I don't have the n years experience with them. The tech hiring process is gruelling enough with languages and frameworks we are familiar with, your resume won't even get a glance if you apply for jobs where you don't have that experience. But I think that narrow thinking is to everyone's detriment.
    - mercer 6y ago
      I've seen at least a few Elixir jobs where they explicitly specify that you don't need to have experience specifically with Elixir. Don't know how common it is though, and it's true that finding Elixir work can be difficult to begin with.
toolz 6y ago
I find elixir and supporting libraries to be the best general web-dev experience of any language. Optional typing, first class documentation, ecto as a library for validations is far more successful at encouraging separation of concerns than I've seen in other CRUD webdev ecosystems. The performance for typical stateless webapps is great, but honestly the thing I love is the amazing tooling and libraries. Elixir libraries are often very high quality.
- news_to_me 6y ago
  +1 for Ecto, really a game-changing library.
- nickjj 6y ago
  > ecto as a library for validations is far more successful at encouraging separation of concerns than I've seen in other CRUD webdev ecosystems. Which other ecosystems have you tried? Just asking because with Python and WTForms they've kept validations separate from your model for the last ~10 years. You could for example create "sign up", "sign in" and "profile" forms based off a single user model and each form has its own fields that you can define with their own validations. Very similar to how you can create separate changesets with Ecto and use a single user schema.
blunte 6y ago
Looking purely at webapps, Liveview is the killer feature of Phoenix. Other than that, I would say that any place with a complex service oriented environment where you could leverage the Erlang VM would be an obvious place to use Phoenix for doing your webapps.
dnautics 6y ago
> I have used Erlang very successfully in a semi-embedded context Elixir is really quite good in the semi-embedded space with several successful companies having their IOT bread and butter in Elixir Nerves platform. The deployment story is getting really mature in Elixir. The article has some really salient points: Testing and Documentation and really amazing in Elixir. Concurrent tests are amazing. So for example normally a "database" would be a global resource and running concurrent tests against the database is really tricky. It's basically turnkey in Elixir (need to set up two settings). With a bit of work, it's not terribly hard to write concurrent tests that exit the VM and come back into the vm and use a test-shard of a global resource. So, for example, you write a test that issues an HTTP request to itself, and the request is instrumented with parameters to connect it back to the test process and use the correct "temporary shard" of the database. (In the case of the database it's a transaction, I use the phrase "temporary shard" because the same mechanism can extended to other concepts too, like module mocks, ets tables, process registries, etc, which all use the same mechanism, you only have to set it up once).
- davidw 6y ago
  > Elixir is really quite good in the semi-embedded space Yeah, I don't need any convincing there. Erlang was a perfect fit for the device I worked on. High level enough to get things done quickly, but with a really solid, predictable runtime.
lostcolony 6y ago
>> but that's quite different from a web server that can usually be scaled horizontally pretty easily So a lot of the other responses are comparing it against Rails and the like, but it sounds like you may be asking specifically around scaling. Erlang (and by extension, Elixir), is nice even when scaling because the actor model will scale to I/O or CPU bound workers simply, without having to tweak threadpools or worry about thread starvation or etc. Other languages that provide n:m concurrency here have the same benefit though (i.e., Golang). Where it shines in comparison to those is in its fault tolerance and memory model. Immutable non-shared data + supervisor hierarchy gives you tools to tackle state that are less error prone than most other languages. And the fact it has a Rails like environment in Phoenix (and Plug, and Ecto, and the whole ecosystem) means you get the same quick-to-build app functionality, without giving up the performance and state management. It's basically having all of these that make it desirable on this front; you can write code as quickly and simply as in Rails, getting the braindead simple scaling behavior of any actor/CSP based model, with the state management of an immutable language, and the fault tolerance of Erlang.
- davidw 6y ago
  Not that concerned about scaling - I think it's going to beat Rails there, but for a larger web app growing quickly, the difference between going to N web servers from 1 might not be that many months.
  - lostcolony 6y ago
    Oh, sure, Erlang isn't going to save you from going multi-node...in fact, it shouldn't; just basic resiliency should mean you're starting multi-node. But the actual number of concurrents per instance, and the effect on latency, is quite another thing. And it also provides you a better story around shared state within the instance, and better controls around its access.
te_chris 6y ago
Fast templates are a superpower for our CMS. Combine it with LiveView to eliminate react and we deliver a really good site quickly.
bluesnowmonkey 6y ago
We used Elixir to implement a columnar database and Phoenix for the web front end, which was about 20% of the code. It’s very convenient having all the tests run together, including end to end integration tests. Elixir (with NIFs) has the necessary performance for the database layer, and Phoenix has the necessary productivity for the web layer, and we don’t have to switch languages to work on both.
- jfim 6y ago
  Pretty curious about this, are there more details that are publicly available? The only thing I can find about this is some meetup from 2018 with a speaker from Pinterest.
  - dnautics 6y ago
    I, too, want to hear about this mythical columnar database in Elixir (or databases!!, if there are two!).
    - jfim 6y ago
      If not we'll have to write our own by duct taping multiple instances of DuckDB. :)
ipnon 6y ago
Elixir with Phoenix feels like programming with simple and straightforward abstractions around HTTP server, HTML generation and DB querying. Ruby on Rails feels like some sort of divine incantation. Rails has a lot of magic and hand waving, and there are recipes for doing everything that you would ignore at your own peril. I don't get the "hold on to your butts" feeling with Elixir.

by davidw 6y ago

ch4s3 6y ago

It's pretty great anywhere that you might use Rails or Django, but if you expect spike in traffic that are hard to predict you get nice stable worst case latency. I think it's also really good if you need to hold state server side for any reason.

davidw 6y ago
Rails has a ton of high quality code available for it. It looks to me like Phoenix is certainly 'good enough' for a lot of tasks, but it just hasn't been around as long. I'm looking for those use cases where someone picked Phoenix and it was just clearly a better tool than, say, Rails because of X, Y, and Z, despite maybe being inferior for one or two other things.
- ch4s3 6y ago
  Having done both, I think Rails has a ton of baggage around ActiveSupport and ActiveRecord that are full of gotchas. Ecto prevents N+1 queries by default, which I think is clearly better. I also think that the lack of lifecycle hooks in Ecto is a better decision than the pile of foot guns in ActiveRecord hooks. I would also argue that Plug is a large improvement over Rack, and the idea of explicitly passing a single context map all the way through the request is just a better way to build http responses. I also think that the Fallback controller is obviously a better way to handle common errors. Anything related to web sockets will be leagues better in Elixir, because the BEAM is built to do a thing like that. SSR html as a compiled linked list is a better idea than runtime string interpolation. Sure, Rails has libraries for everything, but some of the core parts just aren't a nice. So if you don't need all of that breadth of ecosystem then Phoenix is a better choice IMHO having worked professionally with both for a number of years.
  - aantix 6y ago
    >Ecto prevents N+1 queries by default, which I think is clearly better How does it know what associations to eagerly load without knowing about the views? It can't eagerly load all of the data on complex objects.
    - AlchemistCamp 6y ago
      It doesn't eagerly load anything. It preloads exactly what you tell it to. Ecto Repo vs Active Record: https://youtu.be/IFKG4Hgt-zM https://youtu.be/IFKG4Hgt-zM
      - aantix 6y ago
        So you have to be explicit in what to "preload"? How does that differ from specifying an includes on associations for eager loading? It's not saving you any mental energy; you still have to discern what should and shouldn't be loaded up front.
        dmpk2k 6y ago
        The question was regarding N+1. If you're not careful with ActiveRecord, you get that. With Ecto, it's impossible. Ecto has its own drawbacks, but its strong suit is predictability.
        aantix 6y ago
        N+1 is because lazy loading is by default in ActiveRecord. Because it doesn't know anything about your object graph and what associations are needed, so it just loads data as it's encountered. That's a reasonable default. You add includes as you know more about your data and what associations are needed in specific contexts. Eager loading is an optimization, not a prerequisite.
  - nickjj 6y ago
    > Ecto prevents N+1 queries by default, which I think is clearly better. To be fair... If you want to protect yourself from these with Rails you can install Bullet[0] and get protection through in your face notifications, and you have the option to let it slide because you're taking advantage of caching with Rails and in this case you know what you're getting into and the N+1 query with caching ends up being better because you understand your domain. Rails also has the strong migrations[1] gem which is a huge help for not shooting yourself in the foot for running migrations in production by helping you avoid table locks and other issues / errors. But AFAIK there's no Ecto equivalent, but strong migrations is really really useful. Rails also has the data-migrate[2] gem which is a nice little abstraction for splitting out your schema changes and backfilling data in an automated way. There's nothing like this with Ecto. This one isn't as useful as strong migrations IMO but it's still very handy to have this problem taken care of for you without having to re-invent a new strategy in every project or copy code over. Basically all 3 of these things are something I'd use in every Rails project but with Phoenix I wouldn't have these things except for N+1 query protection. I'm pretty sure you could technically create strong migrations and data-migrate for Ecto but the reality of the situation is today neither of them are available and there's no sign of them coming anytime soon. Meanwhile strong migrations has had ~6 years worth of real world testing at this point. [0]: https://github.com/flyerhzm/bullet https://github.com/flyerhzm/bullet [1]: https://github.com/ankane/strong_migrations https://github.com/ankane/strong_migrations [2]: https://github.com/ilyakatz/data-migrate https://github.com/ilyakatz/data-migrate
- cancan 6y ago
  I can add a bit of my experience. I used Rails here and there since 2.3 and have followed Elixir since its inception. - Channels in Phoenix are just a joy to use compared to ActionCable. This is partly due to the language (pattern matching, especially) but not having to deal with a Redis instance (and/or AnyCable) is also appealing. It just works out of the box and is ridiculously performant. - I find the Repository pattern much easier to wrap my head around than ActiveRecord. I feel like with Rails, I always have to know the state of an object whereas w/ Ecto, things are more explicit. I know some people prefer AR here, but I prefer not making an accidental query. - I feel like I am lost every time I'm in a Rails project with so many abstractions now. Maybe this is me being a curmudgeon, but I remember being able to trace request all the way from where it hits the machine (say, Nginx) to the HTML rendering even with Rack. Now, if I had to do something similar, there are so many layers to peel. This is again partly due to the language, and partly to Rails' age.

news_to_me 6y ago

In terms of language, Phoenix is a complete replacement for Rails for me. I feel more comfortable growing a functional codebase, and the BEAM means I don't have to worry about scaling as soon as I would with Rails. I think it's a good fit for when you want to do more with a small, experienced team. I would reach for Rails when I'm concerned about finding developers (Elixir devs are fewer and more expensive, generally), or if there are Ruby libraries I want that aren't available in Elixir.

blunte 6y ago
I fear it would be difficult to hire Elixir people as well, but now I realize it's actually also hard to hire decent Ruby/Rails people. Honestly I think we should just accept anyone who can demonstrate thinking and programming skills of any language and then plan for 2-3 months of ramp-up time to get them into our language of choice.
- news_to_me 6y ago
  I agree, and to be clear I've never really been in a position to worry about hiring anyway. But I would imagine building a medium/large team with varying experience levels (including juniors) would be easier with a more established framework like Rails.
- danjac 6y ago
  I'd be happy (if I were job-hunting) to be able to try out a different language/platform every so often. Now and again I'll play with, say, Ruby or Elixir or whatever. But I know that I'll never get a job working with these languages because I don't have the n years experience with them. The tech hiring process is gruelling enough with languages and frameworks we are familiar with, your resume won't even get a glance if you apply for jobs where you don't have that experience. But I think that narrow thinking is to everyone's detriment.
  - mercer 6y ago
    I've seen at least a few Elixir jobs where they explicitly specify that you don't need to have experience specifically with Elixir. Don't know how common it is though, and it's true that finding Elixir work can be difficult to begin with.

toolz 6y ago

I find elixir and supporting libraries to be the best general web-dev experience of any language. Optional typing, first class documentation, ecto as a library for validations is far more successful at encouraging separation of concerns than I've seen in other CRUD webdev ecosystems. The performance for typical stateless webapps is great, but honestly the thing I love is the amazing tooling and libraries. Elixir libraries are often very high quality.

news_to_me 6y ago
+1 for Ecto, really a game-changing library.
nickjj 6y ago
> ecto as a library for validations is far more successful at encouraging separation of concerns than I've seen in other CRUD webdev ecosystems. Which other ecosystems have you tried? Just asking because with Python and WTForms they've kept validations separate from your model for the last ~10 years. You could for example create "sign up", "sign in" and "profile" forms based off a single user model and each form has its own fields that you can define with their own validations. Very similar to how you can create separate changesets with Ecto and use a single user schema.

blunte 6y ago

Looking purely at webapps, Liveview is the killer feature of Phoenix. Other than that, I would say that any place with a complex service oriented environment where you could leverage the Erlang VM would be an obvious place to use Phoenix for doing your webapps.

dnautics 6y ago

> I have used Erlang very successfully in a semi-embedded context Elixir is really quite good in the semi-embedded space with several successful companies having their IOT bread and butter in Elixir Nerves platform. The deployment story is getting really mature in Elixir. The article has some really salient points: Testing and Documentation and really amazing in Elixir. Concurrent tests are amazing. So for example normally a "database" would be a global resource and running concurrent tests against the database is really tricky. It's basically turnkey in Elixir (need to set up two settings). With a bit of work, it's not terribly hard to write concurrent tests that exit the VM and come back into the vm and use a test-shard of a global resource. So, for example, you write a test that issues an HTTP request to itself, and the request is instrumented with parameters to connect it back to the test process and use the correct "temporary shard" of the database. (In the case of the database it's a transaction, I use the phrase "temporary shard" because the same mechanism can extended to other concepts too, like module mocks, ets tables, process registries, etc, which all use the same mechanism, you only have to set it up once).

davidw 6y ago
> Elixir is really quite good in the semi-embedded space Yeah, I don't need any convincing there. Erlang was a perfect fit for the device I worked on. High level enough to get things done quickly, but with a really solid, predictable runtime.

lostcolony 6y ago

>> but that's quite different from a web server that can usually be scaled horizontally pretty easily So a lot of the other responses are comparing it against Rails and the like, but it sounds like you may be asking specifically around scaling. Erlang (and by extension, Elixir), is nice even when scaling because the actor model will scale to I/O or CPU bound workers simply, without having to tweak threadpools or worry about thread starvation or etc. Other languages that provide n:m concurrency here have the same benefit though (i.e., Golang). Where it shines in comparison to those is in its fault tolerance and memory model. Immutable non-shared data + supervisor hierarchy gives you tools to tackle state that are less error prone than most other languages. And the fact it has a Rails like environment in Phoenix (and Plug, and Ecto, and the whole ecosystem) means you get the same quick-to-build app functionality, without giving up the performance and state management. It's basically having all of these that make it desirable on this front; you can write code as quickly and simply as in Rails, getting the braindead simple scaling behavior of any actor/CSP based model, with the state management of an immutable language, and the fault tolerance of Erlang.

davidw 6y ago
Not that concerned about scaling - I think it's going to beat Rails there, but for a larger web app growing quickly, the difference between going to N web servers from 1 might not be that many months.
- lostcolony 6y ago
  Oh, sure, Erlang isn't going to save you from going multi-node...in fact, it shouldn't; just basic resiliency should mean you're starting multi-node. But the actual number of concurrents per instance, and the effect on latency, is quite another thing. And it also provides you a better story around shared state within the instance, and better controls around its access.

te_chris 6y ago

Fast templates are a superpower for our CMS. Combine it with LiveView to eliminate react and we deliver a really good site quickly.

bluesnowmonkey 6y ago

We used Elixir to implement a columnar database and Phoenix for the web front end, which was about 20% of the code. It’s very convenient having all the tests run together, including end to end integration tests. Elixir (with NIFs) has the necessary performance for the database layer, and Phoenix has the necessary productivity for the web layer, and we don’t have to switch languages to work on both.

jfim 6y ago
Pretty curious about this, are there more details that are publicly available? The only thing I can find about this is some meetup from 2018 with a speaker from Pinterest.
- dnautics 6y ago
  I, too, want to hear about this mythical columnar database in Elixir (or databases!!, if there are two!).
  - jfim 6y ago
    If not we'll have to write our own by duct taping multiple instances of DuckDB. :)

ipnon 6y ago

Elixir with Phoenix feels like programming with simple and straightforward abstractions around HTTP server, HTML generation and DB querying. Ruby on Rails feels like some sort of divine incantation. Rails has a lot of magic and hand waving, and there are recipes for doing everything that you would ignore at your own peril. I don't get the "hold on to your butts" feeling with Elixir.