Hacker News Reader

Comment by rossenberg79 | Hacker News Reader

Why is Elixir always being paired with Phoenix? Can’t I just have a backend API running on Elixir and a javascript front end to interact with it? I’d prefer a simple React, Postgres, Elixir stack (REP).

View on HN

I have an app like that, but I found it convenient to use Phoenix anyway as it provides test helpers, a nice router, an efficient template (EEx) compiler with escaping, etc. I just ignore the parts I don't need.

Phoenix LiveView looks super interesting for simplifying this further: https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...

Yep! Just use Plug. There’s no need to drag the entire Phoenix stack in.

https://hexdocs.pm/plug/readme.html

Then you'll need to create own version of migrations, routing, configure asset building pipeline etc etc etc. Phoenix have everything in place, without need to re-implement lots and lots of basics

A bit pedantic, but migrations are provided by Ecto [1], not by Phoenix. You don't need Phoenix to use Ecto.

https://hexdocs.pm/ecto/Ecto.html

Well, you'll still need to add Ecto, configure it to use separate configs for prod/dev/test environments etc - so point still stands :)

Because Phoenix is the web framework for Elixir. It's easier to just use phx instead of rolling your own solution around Plug / Cowboy.

Same reason why Ruby web apps are usually written in Rails: familiarity with the tool plus you end up rewriting most of Rails as soon as your app is not a toy (tests, flexible router, associations between models, migrations). After some experiments with Sinatra years ago I always start with Rails now.

Plus it's much easier to remove stuff from Phoenix if all you need is something like Sinatra.

You can use Plug instead of Phoenix if you like, but why do you object to Phoenix? It's quite customizable.

Generate a new Phoenix app. Open up the endpoint file. Don't want routing? Comment it out. Don't want logging? Comment it out. Keep what you want, discard the rest.

If you want something simpler and more building-block, micro-framework style in Elixir, you'll want to take a look at Raxx[0]. You could also just build atop Plug itself, though Phoenix really is just a whole lot of Plug.

[0]: https://github.com/crowdhailer/raxx

You might also be interested in Raxx.Kit, A project generator that gets your project started as quick as if you were using phoenix https://github.com/crowdhailer/raxx_kit

In this specific case it is also because Absinthe/graphQL subscriptions are built upon Phoenix channels so if you plan to use subscriptions, Phoenix is the easiest route.

Phoenix also is pretty minimal layer over Plug, especially if you don't include the html library.

You can have Phoenix serve API endpoints and not include the phoenix html template package in your mix files.

> I’d prefer a simple React, Postgres, Elixir stack (REP).

That's not even a web stack. Web stack for example LAMP include a web server (Apache) or something that is able to response to client request. Elixir is a language it can't serve anything. You need cowboy or something and then build around it. Or you can just use Phoenix.

> You can have Phoenix serve API endpoints and not include the phoenix html template package in your mix files.

Incidentally, that's what I did for the project in the blog post. If you bootstrap with `mix phx.new --no-html --no-webpack` then you get a leaner version of Phoenix that's good for an API, without the HTML and frontend asset parts.

Oh wow I didn't even know there's a command for it. Thanks.

Don't let the history of other languages and frameworks fool you: Phoenix is a very minimal set of helpers over the much more bare Plug/Cowboy setup. And it's very easy to strip away parts you don't need.

The fact that you'll have 4-20 small(ish) boilerplate files on a brand new project isn't the end of the world and it gives you a lot of flexibility later.

Reply on news.ycombinator.com