Good example of plug based web application

@wojtekmach’s repository of single-file apps might be very helpful to you:

https://github.com/wojtekmach/mix_install_examples/blob/727e0a70aeb194593eac913afc224c5c0e0f09ea/plug_cowboy.exs

It was for me.

Yeah, same here. I admire the work of the Phoenix team, I simply wish we had PhoenixLite or something.

This is mentioned often and I wonder if simply highlighting the --no-* options in the getting started guide would help, because a lot of Phoenix is optional:

• --no-assets - equivalent to --no-esbuild and --no-tailwind
• --no-dashboard - do not include Phoenix.LiveDashboard
• --no-ecto - do not generate Ecto files
• --no-esbuild - do not include esbuild dependencies and assets. We do not recommend setting this option, unless for API only applications, as doing so requires you to manually add and track JavaScript dependencies
• --no-gettext - do not generate gettext files
• --no-html - do not generate HTML views
• --no-live - comment out LiveView socket setup in assets/js/app.js. Automatically disabled if --no-html is given
• --no-mailer - do not generate Swoosh mailer files
• --no-tailwind - do not include tailwind dependencies and assets. The generated markup will still include Tailwind CSS classes, those are left-in as reference for the subsequent styling of your layout and components

Edit: these are the files created when you use all those flags:

mix phx.new phoenix_lite_example --no-assets --no-dashboard --no-ecto --no-gettext --no-html --no-mailer
* creating phoenix_lite_example/lib/phoenix_lite_example/application.ex
* creating phoenix_lite_example/lib/phoenix_lite_example.ex
* creating phoenix_lite_example/lib/phoenix_lite_example_web/controllers/error_json.ex
* creating phoenix_lite_example/lib/phoenix_lite_example_web/endpoint.ex
* creating phoenix_lite_example/lib/phoenix_lite_example_web/router.ex
* creating phoenix_lite_example/lib/phoenix_lite_example_web/telemetry.ex
* creating phoenix_lite_example/lib/phoenix_lite_example_web.ex
* creating phoenix_lite_example/mix.exs
* creating phoenix_lite_example/README.md
* creating phoenix_lite_example/.formatter.exs
* creating phoenix_lite_example/.gitignore
* creating phoenix_lite_example/test/support/conn_case.ex
* creating phoenix_lite_example/test/test_helper.exs
* creating phoenix_lite_example/test/phoenix_lite_example_web/controllers/error_json_test.exs
* creating phoenix_lite_example/priv/static/robots.txt
* creating phoenix_lite_example/priv/static/favicon.ico

Edit 2: These are the dependencies included:

• phoenix
• telemetry_metrics
• telemetry_poller
• jason
• dns_cluster
• bandit

And the extra dependencies in lockfile:

• castore
• hpax
• mime
• phoenix_pubsub
• phoenix_template
• plug
• plug_crypto
• telemetry
• thousand_island
• websock
• websock_adapter

So apart from adding a --no-telemetry flag I’m not sure how much lighter it could reasonably get while still being sensible?

This sentiment surely comes up regularly, but having seen people attempt this over the years I‘m not sure skipping phoenix (the library) is worth it.

Plug for simple stuff can be quite simple code and less files, but on the other hand any more advanced stuff will need you to write more code than you‘d need to write with phoenix around. Like doing a redirect needs you to manually deal with location headers and also will be missing the security validation phoenix does for local paths. I‘ve seen similar things quite a bit over the years where people ask how to do a thing they know is simple from phoenix in a bare plug app, where it turns out having phoenix would‘ve been the simpler answer.

Phoenix can be stripped down quite a lot, you can use a plug router on a phoenix endpoint without issues (if you‘re not using router mounted LVs) and you‘ll still have most of the functionality of phoenix around.

I am strictly focusing on amount of files, not the removal of features, some of which are critical for most commercial projects (like HTML/templating and DBs/Ecto). Phoenix projects have way too many files IMO.

I know that people who constantly work on Phoenix apps have gotten used to it but as a guy who is leaning on the backend side of things, Phoenix’s generated files relating to UI are confusing.

F.ex. I fail to see point of views to this day. Surely for a lot of projects you can always rely on the defaults that are injected in your code by the generator but these view files are just kind of… sitting there. They are basically an artifact of the framework’s chosen abstractions that leak into your project’s source code.

I’d try to do without them as a start and see how far I can take it.

I agree. Even though the amount of files to me seem too much I’ve also experienced first-hand how extremely useful Phoenix is the moment your needs start growing.

100% agree.

I went ahead with a simple PR: clarify what's optional in phx.new by mayel · Pull Request #5783 · phoenixframework/phoenix · GitHub

My point is that with Phoenix I feel that the framework becomes your application. If I’m not mistaken Dave Thomas has talked a lot about this. Phoenix for me is the outer layer of an application, it’s the API or how it communicates with the outside world.

I‘d suggest differentiating phoenix the library from code, which is generated by phoenix generators. Because most of what the latter provides is not set in stone as all.

It‘s one way of doing things, which caters best to the usecase of powering crud generators for people trying to quickly scaffold apps. You‘re free if not encouraged to adjust those things to fit whatever else you need.

Sounds like a good opportunity to upstream some more generators for other cases, then.