MapStruct is a Java Bean Mapper.
It contains functions that automatically maps between two Java functions. We only need to create the interface, and the library will automatically create a concrete implementation.
pom.xml modifications for maven
<dependency>
<groupId>org.mapstruct</groupId>
<artifactId>mapstruct</artifactId>
<version>1.3.1.Final</version>
</dependency>
(This are my notes taken from the book Spring in Action 5th Edition)
Spring core Provides the core container, dependency injection framework, Spring MVC (Rest APIs), Spring’s web framework and support for template-based JDBC and reactive programming with Spring WebFlux.Spring boot Starter dependencies and autoconfiguration.Spring data Provides the ability to define your application’s data repository as Java interfaces. Works with relational (JPA), document (Mongo) and graph (Neo4j) databases.Spring security Authentication, authorization and API security.Spring integration & Batch helps integrate with other applicationsSpring cloud helps with microservicesIt’s a mechanism to let a web application running at one domain, protocol or port have permission to access resources from a server at a different one.
This is needed if you have, for example, a Frontend running on port :3000 (React) consuming a Backend API running on port :34831 (custom port for Spring). Unless CORS are set, FE will not be able to access BE resources.
It’s possible to enable them for a single RestResource or globally for the whole application.
(This example has been done in Kotlin)
@RestController
@RequestMapping("courses")
@CrossOrigin("http://localhost:3000")
class CourseRestResource {
// dependencies and methods
}
Is possible to auto-generate builders for a Java class using @Builder lombok annotation. They’re really simple though and do not provide auto-filling. They just create an API to fill them with test data.
All we need is to put the annotation into a Java class
@Builder
@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
public class PersonDto {
private long id;
private String name;
private int age;
@Singular
private Set<String> hobbies;
}
Thymeleaf is an HTML template engine, which provides full Spring support.
<h3>Designate your wrap:<h3>
<div th:each="ingredient: ${wrap}">
<input name="ingredients" type="checkbox"
th:value="${ingredient.id}" />
<span th:text="${ingredient.name}">ING</span>
<br/>
</div>
@{} produces a context-relative path to the /static/ folderth:src="@{images/taco.png}" retrieves an image with relative path from /static/th:href="@{/styles.css}" retrieve a css fileA spring bean is the basic building block of a Spring App. In its basis, it’s an Object which Spring Framework manages at runtime.
This management includes:
There’re 3 ways:
@Component annotation@Bean annotation at a Bean Factory.xml config. file (old way)mvn clean install
java -jar target/[substitute_with_name]-fat.jar -cluster
Concurrency is handled completely by Vert.x
When created, a standard verticle will have one Event-loop assigned to it (it’ll always use the same) and the start method it’s called within that Event-loop.
If it calls other Handlers, it can guarantee that they’ll be executed in the same Event-Loop
Meanwhile, a worker verticle will have a different Thread assigned to it, everytime it wants to perform a Job.
If you’re able to use a standard verticle for non-blocking jobs, you’ll save resources every time you execute code with it.
A standard verticle runs in an Event-Loop thread (one of many). If they’re completely blocked, the whole Program will be blocked and it will just halt. On the other side, the worker verticles run on a different Thread than the main event-loop, so they’re perfect to execute blocking code (another option is an inline .executeBlocking() call). They will never be executed by more than one Thread simultaneously, but they may be executed each time by different Threads.
The downside of using always workers, is that the max. concurrency achievable is much lesser than using normal verticles + workers. With a lot of blocking tasks, you may create a processing queue.
The only thing it does, it’s to do a bit easier to test and assert for exceptions in a Test Driven Development-like way. To use together with AssertJ. It only has two methods which are useful to me:
// When
BDDCatchException.when(this.instance)
.methodWhichThrowsException();
// Then
Assertions
.assertThat(BDDCatchException.caughtException())
.isNotNull()
.isExactlyInstanceOf(IndexOutOfBoundsException.class);
A cache itself may be imagined as a key-value map. For a basic Cache we need:
@EnableCaching tag in @Configuration classCacheManager Bean@Cacheable@CacheEvictWe may declare +1 cache(s) at the cache manager and select the one we want to use in the method we tag. As key for the cache we may use any conjunction of the parameters given to the method, or if this is a class, any of it’s accessible variables. The cache will only be triggered when the exact key is given again. Then the method won’t be executed and the value will be directly given from the cache. If the parameters don’t match any key, the method will be executed as normal and then the value will be saved into the cache to be returned the next time.
Caution with logs in big apps as they need to be written accordingly.
The hard part is not knowing when to cache something, but to know when to Evict the cache.