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?

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.

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.

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.

> 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

[1]: https://github.com/ankane/strong_migrations

[2]: https://github.com/ilyakatz/data-migrate