- @ResponseEntity automatically serializes Java objects to JSON
- Spring uses the HttpMessageConverter to serialize the body of the ResponseEntity into the appropriate format (e.g., JSON, XML, plain text) based on the client's Accept header.
Clear and targeted goals and steps, simplistic structure, tested code packets from professional experience, focused on Java, Spring, Angular and more
MICROSERVICES WITH SPRING CLOUD
CONFIG - EUREKA - GATEWAY - BOOK-SERVICE
CONFIG SERVER
We centralize all application properties of business microservices, plus Eureka and Gateway
INTRODUCTION
Ninja is a Java web framework that is lightweight and easy to use.
It is a fully-fledged framework for web development, providing amongst others:
DEPENDENCY INJECTION
ROUTING
MVC
REST
PERSISTENCE
TESTING
METRICS
LOGGING
I18N
HOT-DEPLOYMENT
ANALYSIS /COMPARISON
DEPENDENCY INJECTION
Ninja uses Google Guice for DI, which has some benefits over the Spring Core DI:
ROUTING
Ninja has built-in mechanism to support an easy and readable routing:
public class Routes implements ApplicationRoutes {
@Override
public void init(Router router) {
router.GET().route("/index").with(ApplicationController::index);
router.GET().route("/home").with(ApplicationController::home);
router.GET().route("/hello").with(ApplicationController::hello);
router.GET().route("/editUser").with(ApplicationController::editUser);
router.GET().route("/createUser").with(ApplicationController::createUser);
router.GET().route("/books").with(ApplicationController::getAllBooks);
}
}
PERSISTENCE
MODES AND APPLICATION CONFIG
@Repository
public interface DayActivityRepository extends JpaRepository<DayActivity, Long> {...}What is the difference between checked and unchecked exceptions?
Consider two transactions, T1 and T2, are both dealing with a BankAccount entity with id=1:
READ UNCOMMITTED: T1 starts and updates the balance. T2 reads the balance while T1 is still running. T2 sees the uncommitted changes of T1.
READ COMMITTED: T1 starts and updates the balance. T2 tries to read the balance before T1 commits. T2 will only see the committed balance, not the changes made by T1 until T1 is committed.
REPEATABLE READ: T1 reads balance first. Meanwhile, T2 changes the balance and commits. If T1 reads the balance again, it will see the same value as the first read, even if T2 has committed a change.
SERIALIZABLE: Both T1 and T2 cannot run in parallel on the same User entity (id=1). They will be executed one after another, ensuring complete isolation.
REQUIRES_NEW: always create a new transaction (suspend existing, if any)NOT_SUPPORTED: execute without transaction support, (suspend existing, if any)NEVER: execute without transaction support, (exception, if any exists)REQUIRED: use existing transaction (create new, if none exists)SUPPORTS: use existing transaction if any, else run non-transactionallyMANDATORY: if none already exists, throw exceptionNESTED: if any exists, run extra nested transaction in it, else create a whole new one