As already stated in the text, it is a defensive choice. Will you end up with the best possible and most efficient solution? Most likely not. But you will create a solution that works. Also, if you tell someone that your application uses a standard JEE stack, then that person will already know a whole lot about the code without ever having seen it. It's not perfect, but it has a lot of merits.
Yes, I'm fine with opinionated architectures. However, I just felt many of the claims in the articles are exaggerated.
In addition, the landscape is different from 10 years ago. JVM devs are spoilt for choice of frameworks or stack that just works, so I don't see how this is a key differentiator.
Let's use Spring as a baseline. It's a good framework and Spring Boot had made it effortless to get a project up and running and plugging new functionalities.
In the same breath, I do like Ninja Framework and their focused approach. Reminds me of the Java-based Play 1.x with their hot reload.
If it's simply services you're after (no web UI), a lot of Java shops are really happy with DropWizard.
But of course, they are all servlet-based. Those who seek better performance (throughput and stability under load) would usually go for Netty-based frameworks. It a step up from the servlet's thread-per-request model.
Spring has support for both servlet (Web MVC) and Netty (WebFlux), I've never used WebFlux so I can't really comment on it yet.
With those in mind, I'd go for those akka-http based. Either akka-http for service only or Play Framework for full web framework.
Another framework worthy of mention is vert.x. I haven't used it but I know of people who had a lot of success with it.
Okay, thanks! I've heard about the play framework - mostly rants though. Still, I'll have to check those technologies out to see what they do and how they work. Thank you for the input!
No worries, hope you'll have fun learning about these different approaches. I sure did :)
Apart from frameworks or stacks, another completely different paradigm that I think you might find interesting is eventually consistent systems using EventSourcing + CQRS (Command Query Responsibility Segregation).
It's completely different (and overkill for most use cases), but it shifts your mindset from behaviours of an object to event-driven... Which, I think how things happens in real life, ie. we respond to events.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As already stated in the text, it is a defensive choice. Will you end up with the best possible and most efficient solution? Most likely not. But you will create a solution that works. Also, if you tell someone that your application uses a standard JEE stack, then that person will already know a whole lot about the code without ever having seen it. It's not perfect, but it has a lot of merits.
Yes, I'm fine with opinionated architectures. However, I just felt many of the claims in the articles are exaggerated.
In addition, the landscape is different from 10 years ago. JVM devs are spoilt for choice of frameworks or stack that just works, so I don't see how this is a key differentiator.
Feel free to suggest alternatives then :) I'm not aware of anything comparable on the JVM.
Sure :)
Let's use Spring as a baseline. It's a good framework and Spring Boot had made it effortless to get a project up and running and plugging new functionalities.
In the same breath, I do like Ninja Framework and their focused approach. Reminds me of the Java-based Play 1.x with their hot reload.
If it's simply services you're after (no web UI), a lot of Java shops are really happy with DropWizard.
But of course, they are all servlet-based. Those who seek better performance (throughput and stability under load) would usually go for Netty-based frameworks. It a step up from the servlet's thread-per-request model.
Spring has support for both servlet (Web MVC) and Netty (WebFlux), I've never used WebFlux so I can't really comment on it yet.
With those in mind, I'd go for those akka-http based. Either akka-http for service only or Play Framework for full web framework.
Another framework worthy of mention is vert.x. I haven't used it but I know of people who had a lot of success with it.
Okay, thanks! I've heard about the play framework - mostly rants though. Still, I'll have to check those technologies out to see what they do and how they work. Thank you for the input!
No worries, hope you'll have fun learning about these different approaches. I sure did :)
Apart from frameworks or stacks, another completely different paradigm that I think you might find interesting is eventually consistent systems using EventSourcing + CQRS (Command Query Responsibility Segregation).
It's completely different (and overkill for most use cases), but it shifts your mindset from behaviours of an object to event-driven... Which, I think how things happens in real life, ie. we respond to events.