Generators
Personally I don’t think we should get rid of generators - they are a convenience far more than they are a learning tool Imo. I used them all the time in Rails, particularly for generating Models, Controllers and Migrations. I think I stopped using them as a learning tool (i.e to generate a Resource) after a few weeks.
But why not have a system where you can decide what kind of application you want to build and the generators reflect that? So on app creation a --simple flag for one (which would also be ideal as a learning tool) and then either have a default to reflect the direction you want to push people, or just more flags: --microservices etc? I think this would be an industry first 
and a way to cater to the needs of the most common approaches to app development in Elixir… while at the same time allow you to spearhead what the community thinks is the smartest way to develop applications*. There could even be an --experimental flag 
*Something I think would elevate Elixir & Phoenix even higher above everything else out there.
Microservices - same database, or not?
With regards to Microservices using the same DB, from my understanding this is an option:
There are a few different ways to keep a service’s persistent data private. You do not need to provision a database server for each service. For example, if you are using a relational database then the options are:
- Private-tables-per-service – each service owns a set of tables that must only be accessed by that service
- Schema-per-service – each service has a database schema that’s private to that service
- Database-server-per-service – each service has it’s own database server.
With regards to why use separate DBs (which I actually like the sound of when I picture the kind of apps I want to create and the scale at which they might operate) here’s what doing that enforces:
Services must be loosely coupled so that they can be developed, deployed and scaled independently
Some business transactions must enforce invariants that span multiple services. For example, the Place Order use case must verify that a new Order will not exceed the customer’s credit limit. Other business transactions, must update data owned by multiple services.
Some business transactions need to query data that is owned by multiple services. For example, the View Available Credit use must query the Customer to find the creditLimit and Orders to calculate the total amount of the open orders.
Some queries must join data that is owned by multiple services. For example, finding customers in a particular region and their recent orders requires a join between customers and orders.
Databases must sometimes be replicated and sharded in order to scale. See the Scale Cube.
Different services have different data storage requirements. For some services, a relational database is the best choice. Other services might need a NoSQL database such as MongoDB, which is good at storing complex, unstructured data, or Neo4J, which is designed to efficiently store and query graph data.
Source: Database per service
