Arnošt Havelka

Well, this represents the contract last approach. It has so many issue it's not worth to go with. Even so it's easy, I must admit it. IMHO the best way is to use the contract last approach -> starting the generation from YAML file.

Name just couple issues from top of my head:

- missing HTTP headers -> which are usefull for the clients for the correct calls

- method name conflicts when you want single YAML file (for GUI) from several BE modules

- pagination -> YAML is not generated properly

It's a pretty good article, I like it. However, I have couple comments for improvement:

1. you mentioned to usage of H2, but you use Postgresql at the end

2. you are using Spring Boot 2.6.x, but I would expect 3.4.x now

3. you defined many dependencies which can be managed by Spring Boot in order to simply Maven (Mockito, JUnit, etc.)

see https://stackoverflow.com/a/78976735/7190169 -> not helpful so far :-)

Good article, but IMHO it's still not time for this (to replace Lombok with Records). There is still too many code boilerplate. I recommend to check https://dzone.com/articles/records-vs-lombok?edition=722502

Sorry, but how is your comment relevant to this article?

for "... using a different database for production than in development ...") well. it depends on many aspects, but believe me we are not brave. Our goal is to have the development smooth, efficient and reliable. Therefore, we have many tests for PROD technologies as well. However, as most of us have many environments before going to PROD where tests are not applicable it seems not efficient to me.

BTW have you considered Spring Actuator? It provides the same feature out of the box -> see e.g. Database Health Indicator part in https://reflectoring.io/spring-boot-health-check/.

Nice article, but I have 2 comments:

1. I prefer to use line numbers from article instead of GitHub -> it's hard to see what you are referring to ;-)

2. I don't think the test class is the best solution. Let's imagine you have a different DB provider in tests then in runtime. We use H2 for tests and Oracle for runtime. Such test would be useless to us :-). It depends on the specific project & solution, that's for sure.

> you could use any of the variations in any environment if you want, right?
TEST & PROD environments use strictly the application server. But it's not effective for the local development to need to start AS, deploy application, etc. Instead, we can run our application as standalone application in different configuration / profile. I'm not talking about features, but dependencies -> e.g. we use H2 database in MEM profile, but Oracle in the rest.

Is it clearer?

Well, we use profiles to run our application in different setup -> similar to the test case mentioned by you. Except test we also use MEM (a standalone JAR with all resources embedded inside), FAT (a standalone JAR with real resources) and AS (just WAR to be deployed to application server). By resources I mean database, AMQ, LDAP, etc.

It's not always easy to maintain it, but it really simplies our development life ;-).

for Spring Boot) it supports more languages -> also Kotlin & Groovy. See https://start.spring.io/

Evidently we honor different aspects/approaches. I wish you to find users for your validator.

for "you don't have to create multiple DTOs or litter your code with annotations ") well, it's probably just a matter of prefernce. I prefer annotations more -> to have all definitions at single place.

for "when you want to apply more than one rule to the same field. ") Sorry, I don't understand.

for "I don't see how it is "bad" for testing in the sense that ") The static methods are hard to mock.

what's the benefit comparing javax validation? It seems better and more standard way. Spring Boot uses it natively and it's not using static approach -> it's "bad" for testing.

Good catch of my typo. Thanks!

I recommend to avoid using @Autowired annotation and rather use constructor injection without it. I got this recommendation on Spring certification training. It promotes independence and testability.

Note: There are more wiring possibilities. I wrote about them e.g. here https://dzone.com/articles/smart-dependency-injection-with-spring-overview.

I believe so. We are used to use generics anyway. I use this approach a lot. It simplify the usage when I want just a specific bean.

correct! It's fixed now.