Lesson 4 - Microservices

This has to be my favorite. It starts off with nicely explaining why the Microservices architecture is more flexible than the Monolithic and N-tier designs:

The Microservices Architecture (MSA) decomposes systems into discrete, individual, standalone components that can communicate amongst themselves, working together or with external systems.

This philosophy is exemplified by Amazon's and Netflix's business models which embrace this architectural style. Simply put they would not scale under the Monolithic or N-tier one.

My understanding is that, instead of packing everything in a single application as we've been doing thus far, we break it down to several pieces, that is RESTful APIs, which communicate in between over HTTP.

But how does one service know about the others? That's the key idea in Microservices. Through a registry server, which is responsible for the registration and discovery of the microservices. Spring uses Netflix's registry, released as open source under the name of Eureka.

In this lesson we build such a service registry based on the Eureka server and register with it a Rest service as a client so that it can be discovered. After pulling the related dependencies, it's just a matter of configuration in setting up both the Eureka server and the client.

To make things even easier and more automated, on top of JPA our service is going to use Spring Data REST, which automatically generates REST API endpoints based on our data repositories. No need for the Controller and Service annotations anymore. As such Spring Data REST makes it dead easy to expose microservices, at least for CRUD operations. And while I'm not a fan of relinquishing that much control to an ORM, I acknowledge its usefulness and ease of use.

The bottom line is that a Microservice should be registered so that we do not need to know its hostname and port. For example, instead of:

http://localhost:8766/items

we access it as: 

http://items-service/items>

And this point was troublesome (that is how to call the registered service by name). The instructor left that detail unanswered and this was a cause of a lot of frustration within the class. It was left to the students to do the research and find out by themselves, but it turns out this was not that easy. As such it was the most-sought after question in the Knowledge forum. For instance someone asked: 

• how to configure the microservice to be accessible at http://dog-service/dogs<br< a="">>
  
• another person asked: 
  How the Vehicles-service will discover the other microservices registered and how to call them by their application names rather than the IP address?

• I asked: 
  How can you access the item-service as http://item-service> 

The Mentors didn't really know how to answer these questions. This became even more frustrating when dealing with the final project, VehicleAPI, which couldn't discover the registered endpoints by name.

Finally I managed to get it working and I really think that I'm still the only one who has accomplished that. It happened that I managed to formulate the right question and get the right answer on Stack Overflow and it was not a mere case of copying and pasting code. Instead I had to extract the concept behind the answer given and apply it to my own requirements. I then posted the solution to the Knowledge Forum to help the rest of the students. All good in the end, but I would had preferred to spend my time coding rather than spending it trying to get to the right configuration.

Other than that, I liked this lesson a lot because it debunked the myth that Microservices is something considered far off and beyond reach. Turns out this isn't the case and moving away from the traditional n-tier architecture to modern architectures is within reach. It was also a testament to the Spring framework's versatility - under one framework you can build RESTful APIS, Web sites and Microservices.

Lesson 5 - Security

Next stop is a short lesson where we discover the difference between Authentication and Authorization and learn how to secure our API with HTTP basic authorization.

Basic auth requires a username and a password and, more or less, we have already seen how to deal with that in Chapter 1 with the form-based login. In this case we override the default security and provide our own configuration by extending WebSecurityConfigurerAdapter to set up an in-memory authentication so that we won't have to store the user credentials in a database.

Lesson 6 - Consuming SOAP & REST

In the case of SOAP vs REST, it is explained that SOAP is much older and is used in heavyweight and mostly legacy applications. Nevertheless, this lesson shows how to access a SOAP service by means of a WSDL and client code generation as well as a REST one by means of RestTemplate, which in contrast to Postman's GUI allows calling the service programatically.

Not much to talk about here, except for the introduction of JAXB for mapping XML to Java and vice versa, as well as Jackson for mapping JSON to a Java POJO and vice versa.