Our project generator defaults first and foremost have always optimized for on boarding folks getting into the ecosystem. History and support requests from slack/forums/irc tells us our defaults of including DB integration out of the box are what the vast majority of folks want when getting into Elixir and Phoenix. This same argument is why we include brunch by default – folks want a good story on “where do I place my js/css so I can style and script my web application”. Our defaults are driven by these facts, but as Dave points out in his course, there are switches to customize your new project once you are comfortable in the ecosystem.
With respect to decoupling and thinking in terms of larger application architecture, our --umbrella flag to the phx.new generator follows what dave lays out in his course. You have an apps/my_app_web which is the phoenix server, and a separate apps/my_app, which is your app, and contains Ecto/DB integration by default. There are also new phx.gen.ecto and phx.gen.web project generators for generating isolated applications for existing umbrella apps, so I believe we tick the boxes dave is after if you are using umbrella apps. That said, we don’t generate an umbrella project by default today because it places a larger burden on folks getting started – multiple config files, multiple mix.exs files to place deps in different places, etc. It’s also not clear that all project scopes are best served by umbrellas. What we do in Phoenix 1.3 to bridge this gap is a project structure that more easily lends itself to graduate to an umbrella app, hence the lib/my_app_web and lib/my_app folders with separate aliases.
Dave, can you expand on this point? The push for contexts encourages folks to use discrete APIs exactly to decouple the two. Whether MyApp.Calendar.create_reminder talks to an Ecto repo, or starts a GenServer process with a timeout is an implementation detail from the caller’s perspective so I don’t agree with this point.
