Project Structure - Reorganize in favor of JavaDSL and Reactive support

[markusherbert]

Currently, this project looks like a project that has lots of examples. Underlying these examples are mostly XML-based, which is super unreadable for new users. I think this project should be reorganized and instead of dirs like intermediate, applications, advanced, basic, dsl, there's should be:

• xml
  • basic
  • intermediate
  • advanced
• java
  • reactive
    • basic
    • intermediate
    • advanced
  • non-reactive
    • basic
    • intermediate
    • advanced
• specific-applications
  • xml
  • java
    • reactive
    • non-reactive

Notice that if a sample is JavaDSL based, it is super unreadable to use inside of its parts of another XML-based POJOs.

Another horrible thing is that there are samples whose names are not based on the libraries, but some random names like "Loanshark". The purpose of samples is to make it clear how the usage looks. The application purpose is irrelevant and confusing.

I don't know what is applications place in the world. I'm also not sure if basic, intermediate, and advanced separation is needed. People would be fine if there would all sit together.

This really doesn't require a lot of work and can be super helpful to people. Even if you open an empty folder for reactive, or very thin folders for java in general, it would let people comfortably contribute.

[artembilan]

I probably agree with you and we really need to dedicate some time to improve this repo.
Your suggestion fully make sense at a glance.

The Loanshark is a part of well-known Loan Broker EIP use-case: https://www.enterpriseintegrationpatterns.com/SystemManagementExample.html

[markusherbert]

@artembilan That's awesome! Sorry for not doing the full homework before the post. I've edited the suggested project structure for your review. If you approve, I can create a PR for the implementation.

[markusherbert]

@artembilan What do you think?

[artembilan]

I'm not ready to answer yet, but I disagree for reactive and non-reactive dividing: some modules has both of them, some don't (or cannot).
As well as xml and java separation also doesn't make too much sense.

We may just move away from those confusing basic, intermediate, advanced and applications and just keep all the sample in the root directory.
The XML and Java DSL could be as a part of the same sample: as alternative for the configuration choice demonstrating exactly the same goal in the end.

There are might be some new samples like jms-kotlin-dsl or r2dbc-groovy-dsl fuly without any xml or even Java DSL.

Still need to come up with some working plan...

[markusherbert]

I think separation like xml and java is super necessary. Personally, it took me a lot of time to figure out that there is an example that is not based on XML (for more than a year of being a user I didn't know there was a javaDSL example here). If there would be kotlin samples, we can open the kotlin library. If there are examples that have both XML and Java (I don't see the point but maybe), then we can create some mix folder. Personally, it would be super helpful to me if there was a separation for reactive and non-reactive. Or maybe fully reactive and all the rest. Currently, it is super hard to go to the internet and say "I want to find an example of a Spring Integration app in Java". It is super hard to find an example of the "Reactive Spring Integration app". I truly don't see any other useful option than what I've suggested. Otherwise, it will be impossible of finding (and hard to contribute) examples, like in the situation of today.

Another alternative might be to specify for each example ${tech}-${lang}-${engine} like jms-java-reactive, elasticsearch-xml-synchronous, grpc-xml-mix. I think the mix option doesn't really need to be encouraged since it doesn't make a lot of sense anyway (this makes applications blocking still and lose the whole point)

[artembilan]

Yeah... All of these just sound like your own preferences. It doesn't mean that the way you see it is going to helpful for other people.

It is great that we have such a conversion, but right now it is just my opinion against yours.
Would be great if we have more people joining here to express their vision and ideas.

@garyrussell ?

[markusherbert]

@artembilan you really prefer all of the samples to be at the same level? This will be pretty hard to view

[artembilan]

In my feeling that is going to be the more intuitive and neutral way. In most cases people are looking for some specific protocol or use cases like AMQP to JDBC Or split-aggregate. I still cannot understand how reactive separation could be useful as rsocket, webflux, R2DBC are reactive by definition. The jdbc, jms are not for the same definition reasons. We even don’t need dsl, xml separation since it is not so important for target sample use-case.

many other ideas?

[156640677]

@markusherbert I have the same confusion when looking at these examples, especially in the beginning, it is too difficult to understand a complete process. The cost of learning is high. I also wish I had a DSL implementation example to look at. Thanks for your support. @artembilan

[Aravind1998]

@artembilan Are there any plans for introducing Java DSL based examples in the near future?

[artembilan]

I cannot promise anything since we are here short-handed and have other priorities.
Perhaps if you ask for specific use-case sample, I'll try to find it or come up with an immediate piece of code to help you.
There are just resources at the moment to dedicate to this samples project to make an thorough overhaul.
Thanks for understanding.

[Aravind1998]

Thanks for the update @artembilan