Advanced generator

[MatteoDiPaolo]

Description

This PR is a huge one but not a so difficult one. The idea is to have and advanced version of the generator apart from the default one that can let the user generate a systemic microservice with a couple of extra componentes.

• default version: yo systemic
• advanced version: yo systemic:advanced

Why

• The default generator is good as it is because it highlights the un-opinionated approach of systemic about how to create microservices. We give the users a base and they define which type of business logic they want to implement (rest + DB / bus + DB / bus + blob / rest + third integration / etc.)
• The advanced generator is good to let the user understand how to get the most out of a systemic based microservice.
• The advanced generator fosters the implementation of an Hexagon Architecture for the microservice.
• The advanced generator gives an hint of how to manage multiple business logic workflows in the same microservice.
• The advanced generator gives an hint of how to manage versioning of components.
• The advanced generator gives an hint of how to manage integration testing.
• The advanced generator gives an hint of how to manage the infrastructure for a given microservice with docker-compose.
• The advanced generator gives an hint of how big the systemic ecosystem is when it comes to already available npm systemic components (systemic-rabbitmq, systemic-mongodb).

How to review this PR

Please have a look at the 3 README.md files and you'll have a better idea of how the generator will look like after this PR:

• generator-systemic readme: README.md
• default generated microservice readme: generators/app/templates/root/_README.md
• default advanced microservice readme: generators/advanced/templates/root/_README.md

Related issues:

• 25

• 17

• 14

• 11

• 14

• 6

  Maybe not all the above issues can be fully closed with this PR but still a lot of them are at least partially addressed.

Notes:

The PR #41 may be obsolete after this PR

[feliun]

@MatteoDiPaolo for future occasions it's probably better to discuss first the approach before spending some time in case the direction is wrong.

My opinion based on experience: back in the day I tried to implement the generator very flexible. That led to a lot of complexity because maintaining all versions is hard, so IMO keeping the default version (more complete and mature) as the only one would be my preferred approach.

For me the advanced looks like a "model to follow", but it won't be able to be promoted as a template ever (how many services will be using rabbit and mongo?). So I think it'd be better to have the outcome as a separate repo as example, and link that example from this generator. Let's keep things simple - otherwise more people will keep offering new "advanced 2 templates with Postgres and Kafka because that's what I use".

I think we need to distinguish between templating and "potential architectures". Two different things

[MatteoDiPaolo]

@feliun I see your point and that's actually why I said that the the default generator should remain as lean and un-opinionated as possible without polluting it with the possibility to create any extra component.

On the other hand the idea of the advanced one is not to give out any model to follow nor potential architecture. As stated the idea is to have it to give hints of how to manage:

• versioning of components
• integration testing
• infrastructure
• etc. All the above things cannot be introduced in the default generator without polluting it and that is when the advanced one come in handy.

We are not aiming for flexibility, we are not giving out an advanced generator for the users that want rabbit and mongo, we are giving out an advanced generator for the users that wants to understand better the possibilities of the systemic ecosystem (the above points).

I know that the advanced generator is not so useful in 'generating' terms since the outcome is useless per-se and only valuable as a demo / learning microservice but still having a demo repo for it somewhere else is not the solution. We have plenty of repos based on systemic in the GS github org and all of them have become obsolete as demo projects because the generator-systemic has changed or because their business logic made them drift away from the best practices path, etc.

Having the default and the advanced generator in the same place will avoid the above mentioned drifting of the example. Any time a new handy library comes out (like the error-handler-module) if is an interesting extra that does not fit the default generator it can become part of the advanced version. The only drawback that I see in having the default and the advanced ones is the fact that we have to maintain both but as I said is both a drawback and an advantage.

There will be no other advanced versions of the generator the idea is to have only two of them:

• default: lean and un-opinionated.
• advanced: demo / showcase of all the features that cannot be showcased in the default version otherwise they will make the default not lean and opinionated.

Here goes the actual description about what the advanced version does:

Generate your new systemic project with extra components: 
a not so white canvas with a given business logic already in place 
to help you better understand how to handle components (and sub-components):
- versioning.
- workflows.
- testing.
- systemic ecosystem npm handy modules

[MatteoDiPaolo]

@feliun following a conversation with @UlisesGascon we believe that there may be a compromise in order to have the extra capabilities showcased using the advanced generator but avoiding to have to maintain 2 generators. The solution would be to have a unique generator heavily using if else statements from yeoman in order to maintain the double output microservice:

• default: lean and un-opinionated
• advanced: with extra-components showcasing things that we cannot showcase in the default in order to not polluting it.

This tradeoff is tracked here #57 along with other minor issues that we would like to address in batch against the newly generated branch v.2.3.x. the idea is following the development of these issues / features in this branch in a un-blocking way and once we are happy with the outcome merging it against master.