Hacker News Reader

Comment by nightpool | Hacker News Reader

I've tried to get into Phoenix a few different times, but I've always been stymied by the unfamiliarity of Elixir's syntax, especially codebases that made heavy use of composition and guard clauses, meaning that the business logic was scattered across a half-dozen different files which had to be read in sequence to understand a single web request. This was a big let-down from the (to my mind) very straight-forward nature of MVC code and project structure that Rails pioneered. Do you have any tips for structuring Phoenix projects or approaching these kinds of codebases?

View on HN

I'm not sure I follow. Phoenix is also MVC and its request model is far simpler than Rails'. In Rails we have controllers, we have callbacks (or "filters" as they are called now), and we have "middleware". That's three concepts right there! In Phoenix, we have a connection struct that flows through a pipeline of "plugs". Plugs are just functions that transform said connection. Each part of the request pipeline is implemented as a plug. You can create your own plugs and "plug" them in where you see fit. Read more here: https://hexdocs.pm/phoenix/plug.html

Of course, LiveView isn't MVC in the classic sense, but it still uses plugs. Its goal is to simplify the SPA which I'd say it does a particular good job of.

[Edited to fix part of a sentence I deleted by accident]

> Do you have any tips for structuring Phoenix projects or approaching these kinds of codebases?

Ignore the "View" modules. Put nothing in them. You can also eschew the "Context" modules for your database stuff, and just use Ecto functions directly, though, if you do get into the habit of using Context modules, it will make your life easier to have a unified point of view that abstracts away, e.g. caching, or, if you decide to go full CQRS/event-driven, if you need to send a copy of your data to a datalake, etc, etc.

Actually LiveView tends to have less module-indirection than "deadview"s.

If you prefer to have simple apis, you can just drop phoenix altogether and just stick to Plug. This will give you a ruby/sinatra-style experience that may be more your style, and, IMO, a good way to learn elixir. I did this for a long time before finally giving in and learning phoenix. I turned out OK.

This has most likely to do with the codebase itself rather than with Elixir or Phoenix in your case.

And having to go through a few files to understand how a request is handled is not out of the ordinary in an app, especially if it's grown over the years?

Tbh Phoenix has a lot of boilerplate and some... Opinions that make the codepath slightly more complicated (often for good reason... that might not apply to all use cases) in the default project.

For example:. What exactly is the distinction between an endpoint and a router?

Endpoint == instance of phoenix webserver. Changing things in the endpoint gives you WAF-like control and you can do some early footwork here and store useful data in conn[:private] for you to use later in the modules called in your router

You can have multiple routers. I just built a thing where foo.com uses one router for the main site and *.foo.com is something else.

Point is, they are just plugs. You can put routes in an endpoint, it'll work just fine. The distinction is just a -often useful- prescriptive opinion by Phoenix. (Plug does not split between endpoints and routers)

very true, but the abstraction is pretty useful

it's useful if your project gets very large. It is a non-negligible cognitive cost when your project is very small and you are new to Elixir and Phoenix

Reply on news.ycombinator.com