Controller / view code isn’t really this way though. I definitely agree with you that "model" code definitely doesn’t belong to a specific controller. However for controller / view stuff there’s a decent argument for favoring a “pod” structure.

While not exactly the same, LiveView definitely takes more of a “page” oriented structure since with a given live view + leex / heex template you generally have a bunch of functionality all right next to each other.

I use that approach in my app and I’m pretty happy with it! I don’t use generators though. I even have two separate “myapp_web.ex” files - one for the SSR app and one for the API:

- lib
  - foo
    - ...
  - foo_web
    - app
      - session
        - new.html.heex
        - session_controller.ex (use FooWeb.App, :controller)
        - session_view.ex
      - ...
    - mobile_api
      - message
        - message_controller.ex (use FooWeb.MobileApi, :controller)
        - message_view.ex
      - ...
    - app.ex
    - mobile_api.ex

In practice, it’s never about the extremes though. As there is a ‘data’ App and a separate ‘web’ AppWeb both styles can be used together.

If we look at how the phx generator creates the data app, we see vertical slicing as far as I can remember. Except for migrations which are all in one folder*. It’s the web app that (historically) uses horizontal slicing and although it can be beneficial, I rather use vertical slicing there too.

LiveView seems to move towards vertical slicing, with the template files next to the rest of the code for a page/view.

*Django puts migrations within the ‘feature’. Con: touch two features at once and you have two separated migration files.