At the end of the first part of this CDK series, we promised to demonstrate how to programmatically manage the S3 bucket created as a part of our stack. Let's see it now.
Begin a series examining CDK as a high-level object-oriented abstraction, defining cloud infrastructure by leveraging the power of programming languages.
Jakarta EE Security (formerly JSR 375) introduces the notion of identity stores. Here, learn how they are implemented by Jakarta EE platforms like Payara.
Discover why Jakarta EE, with the industry-wide adoption of microservices-based architectures, has become one of the most popular Java server-side frameworks.
In Parts 1 and 2, you've seen how to run microservices as Quarkus local processes. Let's now look at some K8s-based deployments, starting with Minikube.
This post proposes a microservices deployment model based on Camel, using a Java development stack, Quarkus as a runtime, and K8s as a cloud-native platform.
Readers will learn about Spring Boot and Eclipse MicroProfile, including a comparison of the essential metrics in the same web application and guide code.
Learn about SAM (superset of CloudFormation) including some special commands and shortcuts to ease Java serverless code development, testing, and deployment.
A demonstration of an archetype that generates a Jakarta EE 10 web applications skeleton and its associated artifacts to be deployed on a Payara 6 server.
Arquillian is a classical integration test framework for JVM- based applications. Explore testing with the Payara server using the Arquillian Cube extension.
Demonstrating how to instrumentalize and monitor Spring Boot Services on the behalf of a large set of tools. Check out this entry for our Computer Science Fair!
This is really a great post demonstrating how to simplify cross cutting concerns representing more than 70% of the enterprise grade applications code. Thanks for sharing Martina.
"I'm not against interfaces". Well, you seem to be since you're recommending to remove them, as far as they don't have several implementations. You prefer to refactor your code whenever a new concrete implementation of a service is provided, instead of having a default implementation ruled by an interface. But how a new implementation of a service might be provided, given that the service doesn't have an interface and, hence , it isn't even a service ?
As I said, this is really poor design because it lacks abstraction, it lacks the possibility to provide several concrete implementations of the same service and, finally, it lacks extensibility. And since you're recommending to use design patterns, I would be curious to understand how do you think to use the template one, without interfaces ? For memory, a template is an abstract definition of a service, potentially having several concrete implementations.
But just to make sure I correctly understand your point: how do you deal with functional interfaces ? Since you recommend not having single implementation interfaces, you're probably recommending even more not having interfaces without implementations at all. So, how would you write Lambda functions in this case ? Or you're recommending not using Lambda functions neither ?
"If a solitary implementation of an interface exists, then consider removal". This is a highly questionable point. You're neglecting the functional interfaces which don't have implementations at all and which instances are represented by Lambda functions.
Additionally, your point isn't correct as having only one implementation at a given moment doesn't mean that other new implementations can't be provided later and removing the interface would lead to a poor design. Think at SPI (Service Provider Interface) pattern which, often, has only a default implementation, allowing other providers to suply their. Think also at CDI alternatives which couldn't exist without initial single implementation interfaces.
Lacking or removing intrrfaces is a very bad practice.
One of the fundamental theorem in software design, forged by David Wheeler, says: "Any problem in computer science can be solved by an additional abstraction layer". And abstraction layers are contracts, i.e. interfaces.
Another well known OO principle says: "code against interfaces, not against implementations".
Suppressing interfaces, as shown in the post, and coding against classes, i.e. against implementations, might prevent all the callers from working as soon as the implementation changes.
Another OO rule recommends to never expose implementations and this is, among others, the role of interfaces.
Last but not least, don't forget functional interfaces which are interfaces that specify exactly one one abstract method.
Having unnecessary interfaces isn't good neither but this is not really the problem. The real problem is, more often than not, the lack of interfaces, which leads to a lack of the code abstraction and, consequently, to the infringement of the Liskov principle.
Not sure what this comment is meant to. If you want to write your own article, then please do, be my guest, no need to do it as a comment to the mine. Given that you're not asking any question and you're not bringing any new point in the discussion, I don't know what kind of reaction do you expect from my part.
Since you don't seem to remember any more what exactly did you ask, please let me refresh your memory.
A quick glance at the exchanges above shows that you've asked "Aren't you comparing Spring Boot vs Quarkus and not Eclipse MP ?". This was your question.
And I'm answering that Eclipse MP is just a specification and, accordingly, when it comes to test it, one could only test a specific implementation of it, as testing Eclipse MP itself wouldn't be possible, since is just a specification. :-)
However, while testing a specific implementation, I'm testing standard Eclipse MP features that all the existent implementations support. I'm not testing any specific Quarkus feature which wouldn't exist in Eclipse MP. In this sense, I'm saying that I'm comparing Spring Boot with Eclipe MP.
Hoping that, this time, I managed to answer your question, such that we could get it to closed.
"The only case where you could care about TFR is if you are using lambda". I take it that by "lambda" you mean here "serverless", as there is no reason to isolate the discussion to only AWS. And no, you're wrong, as this is not the only case when TFR is a significant metric. While it might not be a central concern in monolithic applications, for micro-services, in general, not only serverless based micro-services, TFR impacts the cost and the availability of the running applications.
Since the example project doesn't use any Quarkus specific feature, only standard Eclipse MP ones, I'm comparing Spring Boot with Eclipse MP. And yes, Eclipse MP is a standard with multiple implementations, like Quarkus, Helidon, Wildfly, Payara, OpenLiberty and others, while Spring, in general, including Spring Boot, Spring Cloud, etc., is just a Java library which isn't aligned to any standard. Hence, it doesn't make sense to talk about implementations as far as Spring is concerned, because there is noting to implement. Spring provides whatever features and functions its owner thinks as being useful.
Hoping to have clarified the point. Thank you for your comments.
Thnaks for your comment.
1. This archetype doesn't aim at demonstrating neither JSP, nor Jakarta Faces with Facelets. It includes a pure HTML page that might be useful in order to test the effectiveness of the WAR deployment.
2. It is not necessary to use Linux shell, you only need to run 2 Maven commands and a Docker one. And since these commands might be too long to be typed in each time, it's preferable to include them in shell scripts. Why Linux scripts ? Because it happens that I'm a Linux user. What should Windows users do ? Given that the Maven and Docker commands are the same whatever the OS is, Windows users can just run the same Maven and Docker commands or slightly ammend the given scripts such that to be Windows compliant.
CORE
Comments
May 22, 2024 · Nicolas Duminil
Thanks for your comments.
Apr 10, 2024 · Martyna Szczepanska
This is really a great post demonstrating how to simplify cross cutting concerns representing more than 70% of the enterprise grade applications code. Thanks for sharing Martina.
Dec 20, 2023 · Otavio Santana
I'll let you with your own contradictions and won't insist any more but, for me, what you're saying, doesn't make sense.
Dec 20, 2023 · Otavio Santana
"I'm not against interfaces". Well, you seem to be since you're recommending to remove them, as far as they don't have several implementations. You prefer to refactor your code whenever a new concrete implementation of a service is provided, instead of having a default implementation ruled by an interface. But how a new implementation of a service might be provided, given that the service doesn't have an interface and, hence , it isn't even a service ?
As I said, this is really poor design because it lacks abstraction, it lacks the possibility to provide several concrete implementations of the same service and, finally, it lacks extensibility. And since you're recommending to use design patterns, I would be curious to understand how do you think to use the template one, without interfaces ? For memory, a template is an abstract definition of a service, potentially having several concrete implementations.
But just to make sure I correctly understand your point: how do you deal with functional interfaces ? Since you recommend not having single implementation interfaces, you're probably recommending even more not having interfaces without implementations at all. So, how would you write Lambda functions in this case ? Or you're recommending not using Lambda functions neither ?
Dec 20, 2023 · Otavio Santana
"If a solitary implementation of an interface exists, then consider removal". This is a highly questionable point. You're neglecting the functional interfaces which don't have implementations at all and which instances are represented by Lambda functions.
Additionally, your point isn't correct as having only one implementation at a given moment doesn't mean that other new implementations can't be provided later and removing the interface would lead to a poor design. Think at SPI (Service Provider Interface) pattern which, often, has only a default implementation, allowing other providers to suply their. Think also at CDI alternatives which couldn't exist without initial single implementation interfaces.
Lacking or removing intrrfaces is a very bad practice.
Dec 03, 2023 · Otavio Santana
One of the fundamental theorem in software design, forged by David Wheeler, says: "Any problem in computer science can be solved by an additional abstraction layer". And abstraction layers are contracts, i.e. interfaces.
Another well known OO principle says: "code against interfaces, not against implementations".
Suppressing interfaces, as shown in the post, and coding against classes, i.e. against implementations, might prevent all the callers from working as soon as the implementation changes.
Another OO rule recommends to never expose implementations and this is, among others, the role of interfaces.
Last but not least, don't forget functional interfaces which are interfaces that specify exactly one one abstract method.
Having unnecessary interfaces isn't good neither but this is not really the problem. The real problem is, more often than not, the lack of interfaces, which leads to a lack of the code abstraction and, consequently, to the infringement of the Liskov principle.
May 17, 2023 · Nicolas Duminil
Many thanks for your comments.
May 09, 2023 · Nicolas Duminil
Not sure what this comment is meant to. If you want to write your own article, then please do, be my guest, no need to do it as a comment to the mine. Given that you're not asking any question and you're not bringing any new point in the discussion, I don't know what kind of reaction do you expect from my part.
Apr 18, 2023 · Nicolas Duminil
Since you don't seem to remember any more what exactly did you ask, please let me refresh your memory.
A quick glance at the exchanges above shows that you've asked "Aren't you comparing Spring Boot vs Quarkus and not Eclipse MP ?". This was your question.
And I'm answering that Eclipse MP is just a specification and, accordingly, when it comes to test it, one could only test a specific implementation of it, as testing Eclipse MP itself wouldn't be possible, since is just a specification. :-)
However, while testing a specific implementation, I'm testing standard Eclipse MP features that all the existent implementations support. I'm not testing any specific Quarkus feature which wouldn't exist in Eclipse MP. In this sense, I'm saying that I'm comparing Spring Boot with Eclipe MP.
Hoping that, this time, I managed to answer your question, such that we could get it to closed.
Mar 24, 2023 · Nicolas Duminil
Why don't you write your own article to explain all that instead of tire me with these questions ?
Mar 21, 2023 · Nicolas Duminil
"The only case where you could care about TFR is if you are using lambda". I take it that by "lambda" you mean here "serverless", as there is no reason to isolate the discussion to only AWS. And no, you're wrong, as this is not the only case when TFR is a significant metric. While it might not be a central concern in monolithic applications, for micro-services, in general, not only serverless based micro-services, TFR impacts the cost and the availability of the running applications.
Mar 20, 2023 · Nicolas Duminil
Who cares about TFR ? Those who care abour content delivery and latency.
Mar 17, 2023 · Nicolas Duminil
Since the example project doesn't use any Quarkus specific feature, only standard Eclipse MP ones, I'm comparing Spring Boot with Eclipse MP. And yes, Eclipse MP is a standard with multiple implementations, like Quarkus, Helidon, Wildfly, Payara, OpenLiberty and others, while Spring, in general, including Spring Boot, Spring Cloud, etc., is just a Java library which isn't aligned to any standard. Hence, it doesn't make sense to talk about implementations as far as Spring is concerned, because there is noting to implement. Spring provides whatever features and functions its owner thinks as being useful.
Hoping to have clarified the point. Thank you for your comments.
Dec 08, 2022 · Nicolas Duminil
Thnaks for your comment.
1. This archetype doesn't aim at demonstrating neither JSP, nor Jakarta Faces with Facelets. It includes a pure HTML page that might be useful in order to test the effectiveness of the WAR deployment.
2. It is not necessary to use Linux shell, you only need to run 2 Maven commands and a Docker one. And since these commands might be too long to be typed in each time, it's preferable to include them in shell scripts. Why Linux scripts ? Because it happens that I'm a Linux user. What should Windows users do ? Given that the Maven and Docker commands are the same whatever the OS is, Windows users can just run the same Maven and Docker commands or slightly ammend the given scripts such that to be Windows compliant.