The Spring Boot Course

COMPLETE SPRING BOOT

BACKEND NOTES

Rest API: Get, Put, Patch, Post, Delete Methods

Spring Boot: Layered Architecture, Annotations, Beans And Application Context, Dependency Injection, Component Scan, Customizing Bean Nature, Bean Lifecycle & Scope, Conditional On Property, Profiles, Global Exception Handlers And Controller Advise, Aspect Oriented Programming, Transactions, Transaction Propogation, Isolation Levels, Spring Data Jpa Architecture, H2 Database, Types of Repositories, Spring Data Jpa Relationships, Interceptors, Filters, Caching, Types of Caching, Redis Implementation, Scheduling, Cron Jobs, Logging, Spring Batch, Unit Testing, Spring Security Architecture, JWT Authentication.

AWS: IAM, S3, EC2

Thanks To Chetan Ghate For His Playlist

This Page Is Intentionally Left Blank

REST API

Basically REST stands for REpresentational State Transfer and API stands for Application Programming Interface. We are going to look into how REST APIs are implemented over HTTPS? What are the actual meaning of GET, PUT, POST, DELETE, PATCH? And What is the meaning of Representation, Representational State, and Resources? And the terms such as Headers, Request and Response, Request Payload, Status Codes?

Let's start with REST first. As we know, it is a standard and it is implemented in most protocols. In most cases, rest apis are implemented over HTTPS, and there are various https methods which makes this possible. REST APIs are all about transferring data from one layer of system to another layer of system. Like Client and Server relationship. But there can also be a Server and Server relationship. The data we are talking about here is actually the Resources.

Let's say it's an ecommerce website, and you're designing an webapp for it. Now the resource or data that we are talking about here can be customer data. This data sits in database or storage, and it can be in multiple databases. It can be present in primary database, or in search database, or in caching layer database. And each layer is going to have a different REPRESENTATION of this data or resource.

Now these resources also have to be transferred from one storage to another, or from one layer to other. Whenever the client is trying to interact with the server, the data has to be returned to the client as well. While client is asking for the data, the server is going to return the data to client. Now, the representation of data that stays in the server might not be the same as the representation that has been received by the client on the ui app. So that means for the same data, we have two different representations. And also this data transfers from one layer to another. To represent that data in a particular state, we call it a representational state.

For example, let's say we have a resource customer which says in the database and represents a record. Now the client has requested this data from the UI, so the data has to be transferred from server layer to client layer. And it'd be transferred in a JSON format. Because that's what we do in most cases in REST APIs. And UI may represent it in a different way. So for same resource there are different representations. And the data or resource is getting transferred from one layer to another. When a customer record gets updated then in that case what happens is the resource state has changed and its representational state will also changed.

So REST APIs are all about managing these resources, creating and updating these resources. Second, to represent these resources on different layers, and how to pass one representational state from one layer to another. Now this is done using HTTP protocols using REST APIs.

Any REST API implemented over HTTP protocol will be composed of a URI (Uniform Resource Identifier) which points to exactly some resource in your database. Let's recall our app as mystoreapp. Now https://mystoreapp/customer/1 this URL is going to point to a resource in our system. This URI is also known as API endpoint or path. There are different methods like get or post or put or patch or delete to modify this resource or to interact with this resource. For example, using get might give you some read information about this resource, using put may update the resource, using patch also updates this resource, using delete to delete this reosurce, and finally using post to create a new resource.

Let's understand Path Parameter and Query Parameter. In our URI, https://mystoreapp/customer/1, the number 1 here is a Path Parameter. We know that mystoreappp is a fixed DNS (Domain Name Server), and customer is a fixed string (Resource name), however, 1 is a parameter. If we want to fetch the data for customer 2, we'll change this to 2 and so on. So different parameter might point to different resources. A customer might have different orders, so suppose we have something like this, https://mystoreapp/customer/1/orders. Now this whole URI is pointing to all the orders of customer 1. And changing parameter here will also change the order resource it is pointing to. Now, there can also be URIs without path parameters, suppose if the URI is https://mystoreapp/customer then it should list all the customers.

" So, a Path Parameter is a variable in a URI path that helps in pointing towards specific resource. "

Now, let's talk about Query Parameter. Let's say we're having a pointer that points to all the customers. And I want to apply a specific query before fetching the customers. Suppose I want the customers whose name has a substring " A ". In that case, our URI may look something like this, https://mystoreapp/customers?name=A. So that means I am trying to say I need all the customers whose name has A string. So I am trying to fetch the resources on the basis of that query parameter right.

" So, a Query Parameter variable in a URI path that queries/filters through a list of resources "

So, basically Get method is just about fetching the data, and doesn't modify the existing resource. However, the other methods such as Put/Post/Update may modify the existing resource. So when we talk about modifying the state of resources, we try to send some data with request itself, on the api path itself, that is, for example, https://mystoreapp/customer/1. Let's say I want to change the address of a customer, in that case, I'm going to send a Request Payload, that is the body or the json file, that we send with the request. So whenever we're trying to change a resource, it is called Request Payload. And whatever response we get in return , that body or the json file, as a result of the api call, that will be known as Response Body. These two are basic terms that may be comfortable to understand.

With REST APIs implemented over HTTP protocols, we get some status codes, that try to tell us something about apis, the response that we have called, so there are response codes like these below.

2xx means Success

3xx means Redirection and Others

4xx means Problem on Client Side

5xx means Problem on Server Side

Headers basically in a request are set of parameters or set of attributes that tries to actually tell you about the metadata about the request. For example, you want to mention that the content-type in which this api is going to send and accept resources is going to be json, so we can add that to our headers as, "content-type": "application/json", and there are so many headers that we should actually be aware of. So headers help us to send and get the metadata with respect to the request which does not have anything to do with the actual resources on which the apis are interacting.

POST METHOD

So Post method is used in order to create a resource. But that's not entirely true. Post method can be used to not create a resource but to trigger some kind of operation, on any existing resource or post some data on any existing resource which has to be used for processing. So, let's jump directly to the postman.

In the postman, we have an URI https://localhost:8080/mystoreapp/customer which points to a resource, and we are hitting it with a Request Body, which has some data in json format, and the returend request from the server is in status codes of 201, which means the resource id along with the status code is returned only, however we could also have returned the response with a status code of 200, which not only returns the reosurce id and status code, but the response body itself that we passed initially to be store in the resource. Now, in the case when POST request has been used to process some data, we'll return with the status code 204 which is an empty response with request accepted signal. So, we've understood three types of codes, 201, 200, and 204.

Now what happens if you send something wrong in the request data? Let's say you have sent an invalid phone number or email. In that case, the server is going to return the response 400 saying bad request, that means they expect you to send data in a certain format, and you have not followed that format. It also returns the response body, and it'll mention in the error fields, the error messages and codes so that the client can understand better. Suppose if the server responded with 400 bad request status and had no response along with it, then how will client know where did error had occured? So giving proper error messages is very necessary so that the client can understand and the application developer could debug it. 4xx is generally requests telling clients that there is something wrong from your side while sending the request.

Now suppose you have already sent the response body with your details, and you have hit sent again with the same data. So ideally the same duplicate data should not be created, and it should return 409 which is essentially Conflict Response. That means this entity or resource already exists in the system. And you're sending the conflict request.

IDEMPOTENCY. What is it? It means that if we make multiple identical requests then the request is always going to be the same, which is not the case in post. In post, if you send the same request body two times, you may get an error response for sending it again. First we'll be able to create the resource. But second time, we'll get 409. That means post request is not idempotency. However, if you compare it with Get request where if you send multiple requests again and again, you get the same response, therefore Get request is Idempotent.

Suppose we want to create a resource under an existing resource, for that case, we use Path Parameters. For example, http://localhost:8080/mystoreapp/customer/1/order, the order was existing under customer resource.

" So, remember this by heart, POST URIs may or may not have Path Parameters, but definitely POST URIs are never going to have Query Parameters. "

And always have a response body before sending a post request.

GET METHOD

When using get method, the URI has to have has to have a path parameter, incase a single resource is fetched. We have to mention the id of the resource that we want to fetch. We may think that we can mention the id as an query parameter also? But that's not a good standard practice. We must always have the id that we want to fetch as a path parameter. And usually in get requests, there is no request body, because it is unwanted. Actually when we are using get method, then we're trying to pick information from the server, and not putting any information from our end to the server. So if we send the get request and everything goes fine, we'd get the response body with status code 200, saying OK.

Let's say we have a lot of customers and we want to fetch all those customers in one api request. In that case, we might get rid of this path parameter first. Now, we cannot fetch thousands of customer data from one api itself by doing get request on http://localhost:8080/mystoreapp/customer. That's why, we use something known as Pagination or Limits. We can use some query like ?limit=10 that means just return 10 resources. But from where, either from top or from bottom? For that we have something known as offset, which tells which counting the response has to be written. If we say ?limit=10&offset=0 then that means I want first 10 resources.

Now, let's say I want to fetch all the customers whose name starts with "abc". In that case, I can use an URI like this, where the first parameter has ?name=abc. Now this query parameter is going to filter as per all the customer names, match abc with names and if the name matches server will return only those resources. And again if the number of these customers is huge, then we can use limit query parameter to limit the resources being fetched. However, the implementation of limits, filtering and pagination is done on the backend, it's not like a magic kind of thing okay.

Let's say you provided a long customer id in the get request response, and there was no customer id particularly. In this case, the code should return a response code of 404 Not Found. It is just to say that the server does not have any resource like that.

So in case of get method, status code 200, and 404 are most commonly used.

However, remember to follow good practices, and do not design api in such a way that request body is expected in get method, and 400 is being returned that expected format has not been matched.

Let's say it. Is Get an Idempotent request? Yes. Because if you send the same get request multiple times, it'll give you the same results again.

PUT METHOD

Now we want to update those resources. Put and Patch methods. Now you might have heard that put requests are used to only update resources, and that is partially true. Put requests can be used in order to update any existing resources or put request can also be used to create a resource. Sometimes this operation is known as UPSERT which means if the resource does not exist then create a resource or if the resource exists then update the resource. The important thing to note here is that whenever you're using PUT request, you've to send the whole body of the resource that needs to be updated. Similar to what we have seen in the post method, we send the request body in the request table. Now the question arises. How do we know whether put has been used to update or create that resource? Very simple.

If we want to UPSERT, it can only happen when the client who is sending the request has access to the id of the resource, so either they know the id of the resource or they are able to generate the id on their own, and the server supports the id sent from the client. For example, we send a request to http://localhost:8080/mystoreapp/customers. As soon as we send this request, the server sees the request and realizes that customer with id already exists. In this case, the server is going to update the whole customer resource with the attributes that we just sent with the put request and in response the server is going to retunr the whole object itself with the response code as 200 ok. So we can see that an update operation has happened, since the resource has already existed, a new resource has not been created, in fact, the same resource has been updated. Now suppose, when we give a unqiue id number of customer which did not existed, now since the id did not existed, and according to the implementation, the server trusts on the id sent from the client, for put request, so what the server is going to do, since any customer resource with an unqiue id doesn't exist, it is going to create that resource, this is an create operation.

Now, second case, let's say UPSERT doesn't support operation, and server doesn't trust on the id sent by the put request. In that case, it can only update the existing resource. However, in the case when the server does support UPSERT operation, or allows put to create resources, we're expecting the id of the resource to be sent in the body and not as the path parameter. Why? Because if the Upsert operation has to be supported and if the send the id in the path parameter, if the case where the resource is not existing, it'll result in a 404 Not Found error. That's why we send the id in the request body. This was about supporting upsert operation using put method.

No let's see if the server implementation does not support upsert operation and it only supports update resources. In this case, note that we are going to send a request with the id of the customer in path parameter and the whole customer object in the request body. What will happen on the server side is looking at the id which exists in the server side, the whole body of the resource that is saved in the server side is going to be replaced with the body that has been sent with the put request. Suppose for example we had the phone number of a customer, but then when updating the customer details with the put response we did not gave the phone number, then the phone number will actually be null. So whatever request body has will completely replace what is present in the backend before.

What are the errors of put request? If we're going to use an id in the path parameter which doesn't exist, then you're going to get a 404 in response. And if you're going to send any attribute which is invalid like, invalid email id, then you'll get the sam eerros as you have received in the case of post request like 400 bad request.

Now is there an error 409 in the case of put? The duplicacy conflict error. NO. Because you're definitely going to use the id which already exists on the server side right. And you're trying to update it. So you'll not get 409 in case of put request.

PATCH METHOD

Now coming to patch, what is the difference between put and patch? As we have seen, we just understood that in case of put request, the whole body of resource is replaced by whatever attributes the resource had. Let's say you don't want to replace the whole body, and you just want to modify one or two attributes of a resource. In that case, you can use Patch. As the name suggests, it is just patching or changing few things in the existing resource. So let's say you just want to update the city of a customer, you'll use the same URI as you've been using in put, and you'll use the method patch, and you'll just send the changes that you want to apply to the resource instead of sending the whole json response body. That means you're only sending the changes or difference that you want to apply and you'll use patch request for the same, which'll update only that field of the resource on the server.

However, if you are still sending all the attributes in the patch request itself, you might as well use put and let patch go and don't use that. But if you have a use case of updating one or two fields, or applying just few changes in a resource, then patch is the best way to go about. Now there comes a thought. If we can do the same thing using put, then why there is a need for sending using patch request? Why patch method even exists? Now think about this. There are some resources which will have hundreds of attributes. In that case, it might become very cumbersome for the client to send the whole body again and again, and it'll also slow down the request beacuse you're transferring a lot of data. Instead if you just want to update one or two fields and you don't have to send all the hundreds of attributes, just sending those specific attributes that we want to update, will actually make your apis faster and efficient. That is why patch methods are used.

Now what about Idempotent in put and patch? Actually both are idempotent. Why? Because once you update a resource using a put method, second time also if you send the same request, the server state is not going to change, as we have discussed, the property of idempotentcy is that your reqeust is not going to change the state of the server no matter how many times you send that request. This stands true for put as well as patch as well as get also. The only method which should not be idempotent is the post method.

DELETE METHOD

As we can see, in the case of delete, we just want to delete a resource from our table right. Now how do we do that? We're going to mention the id of the thing that we want to delete along with the URI, and the method is going to be delete. We don't want to send anything in the request body. We just want to tell the server that ideally this resource must be deleted. And the response of all the delete apis should be 200 ok, telling me that the operation has been successful.

Now what this api is going to do on the server side. There are two things that can happen. One, you can completely wipe off the customer resource. That means you just delete everything from your database and there is no entry left for this resource. Or you can actually soft delete the resource, that means you'll keep a field in database for this resource which can be known as deleted, and it can be a boolean like thing, and we can mark that field as true if this thing as been deleted. This is known as SOFT Delete. Usually, in most cases, whenever the resources are deleted this strategy is followed, unless for some kind of data which is not useful, the resources are completely deleted, and like hard delete happens, or removed completely from the server storage.

Now how do we check whether our delete has been successful? Soon after delete, you can send a get request and check that request should return 404 Not Found error, because the resource is not found, since we have deleted that resource.

What if you want to delete multiple resources at a time? Let's say you want to delete all the orders for one customer. Similar to other operations and other URIs, this is going to look like this. http://localhost:8080/mystoreapp/customers/1/orders and call DELETE method on it. This is going to delete all the orders for that particular customer. Next time, when you try to fetch these orders, what is the response that we are going to get? Ofcourse 404 Not Found. Because no orders have remained in the system with respect to this customer.

Now coming to errors, can delete result in an errored response like 400 or 409? Maybe not, it can result in an 500 server side error. But yeah status code 404 is possible if the id in path parameter has already been deleted before.

Now coming to Idempotent, do you think delete is idempotent? That we leave upto you as an exercise to go through.

This Page Is Intentionally Left Blank

SPRING BOOT

The journey into spring boot starts from creating your first project intellij, to understanding the layered architecture, the package structure. Like we need to understand what is controller layer, what is service layer, what is repository layer, and how they are segregated, and how the test packages are segregated inside our application. Not just this, we have to understand maven and gradle build toold in depth right.

When we need to understand spring boot annotations one by one. How can we configure things by using annotations right.

The next thing is about dependency injection and inversion of control. This is the core of spring boot. There are topics like Field Injection, Setter Injection, Constructor Injection etc and we have to understand the pros and cons of each.

Next we have to understand how do we configure a spring boot application, using application.properties file where we can add various configurations. Like we have code snippets that we can add there and we can use it anywhere in spring boot. Like storing some constants such as APIs and URLs. And we also have to understand what are spring profiles. Let's say you have different environments while developing, testing and deploying, so configuration related to these are handled using spring profiles.

Then we have to understand Spring Beans And Its Lifecycle. And the Four Types Of Spring Bean Scopes. Singleton, Prototype, Request, Session.

Then we have Spring Boot Data Access Layer Using JPA (Java Presistence API), And JDBC for handling data and databases.

Then we'll get a basic knowledge of RESTful APIs Using Spring Boot.

Then we've to go deep into Spring Boot Security, Authentication And Authorization.

Then we'll cover some aspect of Spring Boot Logging. Exception Handling, Caching, Interceptor, Scheduling, Unit Testing Using Junit And Mockito, Spring Boot Actuators and much more.

Then we'll learn about deploying Spring Boot Applications, on Tomcat, Docker, Using CI/CD pipelines Jenkins, Cloud.

Then finally, we'll go into Microservices With Spring Boot using Eureka, And tracing the request in multiple microservices using Sleuth And Zipkin. And we'll understand API Gateway, And Spring Cloud Configurations.

And finally, we'll build a spring boot project from scratch.

SPRING BOOT LAYERED ARCHITECTURE

In @SpringBootApplication, we commonly use three layer architecture. First one is controller layer, second one is service layer and third one is repository layer.

Controller Layer is something where you write your controllers. What is a controller? Controller is first entry point of your spring application where we write apis. So, we have annotations like @Controller or @RestController on top of the classes that we add in a controller. So, these controllers basically will have the APIs that a client will call right. So, client will call some like a setter or getter request so these particualr requests will be handled by your controller layer. So, your client will hit some API to your application. For example, let's say /api/getEmployee so this particular call will go to this controller, this controller will have this mapping to get the details job of your controller, so it'll just get the details, and your call is coming to the controller, and controller will do something at the backend, and it will just return the response, so primary responsibilities of controller layer is to get the request, whatever request is coming from user, process that request, and then return the response back, so that is the primary purpose of your controller layer.

Now, controller layer is just for taking and giving back the requests, and it'll not be able to do any business operations inside it. It'll just take the request, and it'll just forward that to your service layer, in order to do whatever operation, and whatever business logic, and whatever processing that we want to do on that data.

So, our controller does not have any responsibility of writing any business logic, we now understand that the controller sends the details to the service layer to process and do all the business operations tha twe want to do right. So, all business operations will happen in service layer, it'll take the request from the controller, basically client wants the data, so service layer will do all the modifications on the data, all the data populations if needed, and all the business operations will be performed inside your service layer.

Now, suppose the request was to get something from the database, so what service layer will do is it'll forward the request to repository that dude, I need this data from the database, will you go ahead and fetch it from the database for me and give it back to me? Let's say, the client asked for employee details. So, service layer will call the repository layer and say, I want the details of this employee, and what repository layer will do is it'll talk to the database, hit it with respective SQL queries, or whatever language queries, and it'll get the respective data, and give it back to the service layer right, and the job the repository layer is just to talk to the database, get the data by fetching from database or save the data to the database, and return the response to your service layer.

Now, what service layer will again do is it'll take the response from your repository layer and give it to your controller, and this way, every layer has its own responsibility over here. Well, you might say, service layer can also go directly to database, why do we need repository layer then? Right, you can do whatever you please, no one is stopping you. But that is not the ideal case, and this is not a standard way of doing things, and it'll be more confusing when your business grows.

So, client first taks to controller, then controller talks to service layer for business logic, and finally service layer talks to repository layer for database integration. And it goes in reverse the other way around while sending back the requests it intially accepted.

So, this is how the layered architecture looks like, and these are the responsibilities of each of your layer.

Now, we have four things over here above: DTO, Utility, Entity, Config. What are these? Let's find out.

DTO is basically data transfer object. So, let's say client can also call some post request, like using /api/addEmployee, so it'll send some json object which will have the details of the employee, so this json object which is kind of a employee should be converted to some java object inside your controller layer so that particular java object we called as DTO is basically used for client to controller communication. The request dto will have request details, and response dto will have response details. Basically, in similar fashion, there is one more java object that we have when we call to database that we call as entity, so it'll be a similar object to this dto but entity will be a direct mapping to your database, so whatever entity you have, let's say, you have employee class inside, and you have primary id as name, and department and other details of empoyee, then those particular details need not to be shared with your client right. Client just wants the respective details it asked for, so that particular details which are not needed by your client, will be removed in this DTO, so DTO will not be having it, and basically, this DTO will be returned to your client, and the conversion of this Entity to DTIO will happen inside your service layer. And Entity will be a direct mapping of your table inside your database.

When there is something common between these three layers, supppose some calculation functions that we need in all the layers, then that particular code we can put up in utility package or class, and we can directly import and use it right. After that, we have configuration as well. In spring boot, we have configuration files, you can have some common values or common URLs or common configuration that you want to use in your entire application. For example, let's say there is a URL of third party, that you can configure inside your application.properties file and you can use in this configuration right, and then you can use it in your entire application. And changing this URL in configuration will change it in entire application.

This is a basic spring boot setup. We can see that the client has a connection with controller. So client has a controller. Then controller is connected to service. So controller has a service. Then service is connected to repository. So service has a repository. This is the basic flow of a spring boot application.

Now, let us add DTO and Entity here.

We can see how Entity is being handled by the repository only. And how DTO is being handled by the controller only. In the middle, we have service which is responsible for conversion from Entity to DTO.

SPRING BOOT ANNOTATIONS

What is @Controller? A controller class simply connects to the clients by letting us write our actual apis. So the api request which is coming from outside your application will first land inside the controller based on the mappings.

Let us go more in details of it. The user is actually connected to the server, it can be tomcat, jboss, jetty. Now when a user is sending a request to your application, so it will first land inside your server. Now what this server will do is this will transfer the request to the next compnent inside your application. The next component will be something called as dispatcher, servlet. Whatever request is coming from your server will first land in dispatcher or servlet inside your application. Now what is the job of this dispatcher or servlet? They'll find out the controller for you that consists of the mapping.

So, let's say the user is calling /getEmployee. Now the moment dispatcher gets this request, it'll try to find out th controller in which this particular request is mapped. So, dispatcher or servlet will use HandlerMapping to figure out the number of controllers right because there can be a thousand of controllers inside your application, who knows? However, we only want the controller in which this request mapping is mapped, we'll try to find out this mapping inside the respective controller right. And how do we know a class is a controller? By using @Controller annotation right.

Here, the moment we mark a class as @Controller, the dispatcher or servlet can find it out and it can map the request coming from user to respective controller right. Now, in order to add that mapping, what we need to do is that we need to add @RequestMapping annotation. So what request mapping annotation does is it will have a path basically to which we can map our incoming api to. So, once the user will hit this mapping, the dispatcher or servlet will find this controller and call this particular api right. So, we can make use of request mapping to map the request with particular path, which is a end point for some http method. Now, which http method are we going to use here, for that we need to write a method as well, so here we will add method alongside the path in request mapping annotation like this.

@Controller

public class EmployeeController{

@RequestMapping(path = "/getEmployee", method = RequestMethod.GET)

public String getEmployee(){

return "employee";

}

}

However, this particular mapping will not actually return a body. Once this api will be called, what this try to do as we are returing it is that it will try to find something like employee.html file to render it on UI right. Because it'll think that we need to render some kind of UI as a response right. But that's not what we want to do here, what we want to do is to actually return a json response body. For that we use @ResponseBody on top of it. So, it'll return this particular string as a json or whatever format you want to give to the user instead of rendering any UI. Response body will just indicate that the response of this api should be a body and not any view right, so that is the use of @ResponseBody.

Now, suppose I have multiple functions within the controller class and each function has to return a response body. Would I be using @ResponseBody on each function then? Well, everyone is going to return the same kind of response body right. So, instead of annotating this way, what we can do is we know that this controller is serving as a rest controller so we can actually go ahead and convert this to rest controller using @RestController. So, the moment I do that I don't need to annotate any function with response body rather I can remove that @ResponseBody annotation and the api will still return response body. So that is the use of @RestController annotation.

So @RestController is basically the combination of your @Controller and @ResponseBody Annotation. So if someone is asking you the difference between these two, highlight that if there is certain controller which is only going to return the data and not going to render any UI then we need to go ahead with @RestController rather than going with @Controller.

Similar way, we can mention the method we want within @RequestMapping and it can be any http method. However, I have to mention those methods explicitly in request mapping annotation each time, which is not developer friendly. Instead, we could just use annotations for each mapping separately. such as @GetMapping, @PostMapping, @PutMapping, @DeleteMapping. Mappings to these annotations can be provided as an String arugment, for example @GetMapping("/api");

Now, suppose the user wants the get the employee by id, now the user has to provide some kind of an id to get that employee's details, and we have to get the id that has been passed by the user. So, in order to get the employee id, what we need to do is we need to do is define a parameter in function and use @RequestParam so that we could accept whatever request parameter user is going to pass to us right. We can also provide some other name ot it like this @RequestParam(name = "id")

@GetMapping("/api/getEmployeeByID")

public String getEmployeeByPathID(@RequestParam Integer empID){

return "employee"; // some db logic

}

However, we are going to take this as a query parameter right. Let's say I don't want to pass it as query parameter rather I just wan to pass it as a path variable like there are some apis where there won't be any query parameter right. So how do we do this? For this, we need to use something called as @PathVariable. For this to work, we have to provide a variable inside our mapping like @GetMapping("/api/{id}"). So we are passing a variable parameter from our request url into the method signature. So the moment I use @PathVariable with the same name as in {} variable parameter, the value will be automatically mapped to this method signature. And we can also provide naming like this @PathVariable(name = "id")

@GetMapping("/api/{id}")

public String getEmployeeByPathID(@PathVariable(name = "id") Integer empID){

return "employee"; // some db logic

}

Now, suppose the user is sending the post http request and sending a json object in the response body, and we have to catch that response and store it up as an java object, for that we use @RequestBody, which'll take the json object and automatically set the values into the corresponding object values we have created.

@PostMapping("/addEmployee")

public String addEmployee(@RequestBody Employee e){

return "added";

}

public class Employee{

int id;

String name;

}

json object {

"id": "1",

"name": "Aryan"

}

Now, we have used some annotations such as @Service, @Repository, @Controller which marks the 3 layer architecture and makes our code readable, but these annotations are stereotype, which means they are just an alias name for @Component annotation, which simply creates a bean of that class and stores it in its container. We'll look into @Component soon.

SPRING BEANS

AND APPLICATION CONTEXT

So what is a Bean? Bean is just a java object right. Nothing fancy. We refer to java objects as a POJO meaning plain old java object, and same thing in spring we refer that particular object as a bean right. So when a java object or a pojo is managed by your spring application then that is referred as a bean. So whenever we say Bean it's just a java object.

Now spring has something which manages all your beans inside your spring application along with the dependencies of those beans. So bean creation and deletion and everything will be handled by the spring IoC container. So consider spring IoC container as a box in which all the beans of your application will be stored right. Now spring IoC container is kind of a terminology. When it comes actual implementation, it'll be ApplicationContext. So, more often these two terms are used interchangeably. Basically, application context is the implementation of your spring ioc container.

So application context will be the actual object inside your application which will store or refer to all the beans right. Now consider this as a spring boot application which will have a container running spring ioc container and let's say you have business objects that is pojos. So pojo will be used in your application right. Along with that, you will have multiple configuration metadata like multiple annotations. It'll take the configuration metadata for the pojo object you have provided and then the bean of a particular object will be created inside your application context and your application will be ready to use. That means you can perform operations on that particular object.

Now consider your application as a backbone of your application which will manage all the beans which will have a reference to all the beans that you have and which will handle all the bean injection bean dependencies bean deletion and all the life cycle of bean it can handle, and it is the implementation of spring ioc container right.

So this is just one implementation, there is yet another implementation of spring ioc container that we call as Bean factories.

Let's have a look at actuator. It's a very deep topic and a lot is going on here. But let's take a quick look at it.

First we'll configure actuator inside application.properties in resources/ folder of our spring application.

Inside this file we'll write:

management.endpoints.web.exposure.include=*

Now, I need to get a dependency spring boot actuator in our pom.xml file.

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

Now, we can check the beans that we have added to our application like magic. We have to go to localhost:8080/actuator/beans. We'll find a lot of predefined beans here by spring. And inside these, we'll have our bean as the class name somewhere which we'll be abe to find once we have used @Component annotation or its stereotype annotations.

@Component

public class ProductService{

public ProductService(){

System.out.println("ProductService");

}

}

Here we can see that all beans are of Singleton pattern. And all stereotype annotations that are alias of @Component are of singleton scope.

So, fundamentally there are just two ways of creating beans. One is by using @Component. And the other way is by using the traditional @Configuration & @Bean annotations.

SPRING DEPENDENCY INJECTION

So there are basically three types of dependency injection, these are basically Field Injection, Setter Injection, Constructor Injection. We'll learn about them now with each injection's pros and cons. And along with that, the commond problems that we face during dependency injection, such as Circular depdendency and Unsatisfied dependency.

public class User{

Order order = new Order();

public User(){

System.out.println("Initializing User");

}

}

Now what is happening here is that user has a tight dependency on your order. So this tight coupling between two might create some problem in future. So what problem it will create? Let's check it out. Let's say we have an order class and we want to convert this to interface in future and have separate implementations of Order class like OnlineOrder and OfflineOrder whose parent interface will be order right. Now when I go back to my code, it's obvious that it'll throw an error, because we cannot instantiate the object of an interface right. So, if in future you're converting your classes to interfaces and have such a tight coupling then you cannot create object of that interface right and our code may break apart.

public class OnlineOrder implements Order{}

Now what we did is: Order order = new OnlineOrder();

It may work but we are breaking one SOLID principle okay. Which one? It breaks dependency inversion. So, dependency inversion is basically D inside your SOLID principles which says that do not depend on concrete implementations, rather depend on abstrations. So we do not have to use the new keyword and initialize our Order class inside the constructor.

public class User{

Order order;

public User(Order order){

this.order = order;

System.out.println("Initializing User");

}

}

So, in spring we can make these classes independent of these dependencies right. What we can do is we can add dependency dynamically right. So, this dynamic dependency injection will be taken care by your IoC container. So, here this step our bean lifecycle takes place which we'll look into soon.

Basically we are avoiding any tight coupling over here, and because when injecting that dependency, we want that to be a component too managed by bean, we'll use @Autowired on top of where we declared order interface.

Now let's go into each of the dependency injection types:

1. Field Injection

So in field injection, dependency is set on the field of a class right.

@Component

public class User{

@Autowired

Order order;

public User(){

System.out.println("Initializing User");

}

}

So, what happens inside the hood is that in the bean lifecycle, once the IoC container is initialized, it'll start constructing the beans right, it'll check for the @Component annotations and it'll create beans inside it. So by here spring has initialized the bean object and have the object ready inside your spring ioc container. And then this bean object will be injected over here, adding that dependency right.

So basically spring uses reflection it iterates over the field of your class and then injects the dependencies right so that is how it works right. So any number of dependencies you add, it'll inject all those fields right if those fields are your spring components and they are annotated with @Autowired where they're being injected.

So advantages of your Field Injection is that it's very simple to use, we can just add @Component and inject fields directly using @Autowired.

What are the disadvantagse of field injection? Well, the first problem is that it cannot be used with immutable fields.

@Autowored

public final Order order;

Let's say you mark your injected field with @Autowired as final, then you can see we're getting some error. Since final fields do not change their value once they're initialized, at class level, and since an object field is initialized to null first if we have not used the new keyword.

The second problem is chances of null pointer exception over here. Let's see an example to understand it further.

@Component

public class User{

@Autowired

Order order;

public User(){

System.out.println("Initializing User");

}

public void process(){

order.process();

}

public static void main(String[] args){

User user = new User();

user.process(); // NullPointerException

}

}

Now if I run this code, we are getting a null pointer exception over here because even though we are creating the instance of user yet this dependency is not actually injected because this code is not running from spring right and this is not a spring component, so when we ran it explicitly we don't know what is order. However, when we run it in spring context, it'll automatically inject the dependencies right.

So, if we create objects like this that is not a spring component then it'll likely break the code and throw NullPointerExceptions.

Now let's proceed and look into Setter Injection.

So we inject the dependency by using setter of that particular field right. So let's say I created a setter for Order class and here I am going to use @Autowired on top. We'll remove @Autowired from the field and put it on top of the setter right.

@Component

public class User{

Order order;

@Autowired

public void setOrder(Order order){

this.order = order;

}

}

Now let us discuss the advantages of setter injection. " Dependency can be changed any time after object creation. " What does that mean? We can change dependency at any point of time like that right and this is easy for junit testing as well. We can pass mock objects independently so we can use setter methods and we can pass the mock objects and set the mock objects explicitly right.

But it does have some cons. What are these? Fields still cannot be marked as final. So the same problem presists as we encountered in field injection. We cannot use setter injection when it comes to your immutable variables right. It'll give us an error because that field object was initially null at the time of parent object creation before it even called the setter method.

Another disadvantage of setter injeciton is that it is difficult to read and maintain, as per standards. So the readability is the problem here right.

Now, let's see the main thing that we're waiting for: Constructor Injection.

This is the one mostly used rightm because it brings a lot of advantages and overcomes the disadvantages of other injections. So both the problems of the field injection and setter injection are resolved here like magic. Let's understand it.

" Dependency will be resolved at the time of initialization of object "

Now dependency is injected while creation of your bean only. The dependencies will be injected like this.

@Component

public class User{

Order order;

@Autowired

public User(Order order){

this.order = order;

System.out.println("Initializing User");

}

}

What happens under the hood is that Order class itself is a @Component so it'll be created in the IoC container first. When it'll go to the User class, it'll see the dependency injection in the constructor initialization, so it'll inject that same order class here that was already present in the IoC container, and then user class will be created in the IoC container.

This is something which we call as constructor injection right. Now let's say there are multiple fields that you want to inject. We can also add in our constructor right and all those fields will be initialized and injected accordingly. So overall this is the recommended way of injecting your dependencies.

Note: " When one constructor is present then @Autowired is not mandatory. "

Let's say we remove @Autowired and write the code something like this.

@Component

public class User{

Order order;

public User(Order order){

this.order = order;

}

}

Now dependency will still be injected because spring will use reflection right and it will analyze that okay this order is also a spring component and we already have that component present so what it'll do is it'll inject the same bean directly okay.

Now suppose we have two constructors like these.

@Component

public class User{

Order order;

OnlineOrder onlineOrder;

public User(Order order){

this.order = order;

}

public user(OnlineOrder order){

this.onlineOrder = order;

}

}

Then spring will get confused that which bean needs to be initialized so @Autowired is mandatory here.

We'll get BeanInstantiationException: Failed ot instantiate Bean because it doesn't know what bean to instantiate.

Basically we can explicitly say that okay I want to inject this one using @Autowired. But we have a simple rule, we cannot have @Autowired in more than one cosntructors. So when we want to inject more than one fields, we cna ismply extend the constructor parameters.

@Component

public class User{

Order order;

OnlineOrder onlineOrder;

@Autowired

public User(Order order, OnlineOrder onlineOrder){

this.order = order;

this.onlineOrder = onlineOrder;

}

}

Now what are its advantages? Well, all mandatory dependencies will be injected at the time of initialization itself. It makes sure that our object will be initialized with all the required dependencies else it won't be initialized. Avoids NullPointerException because your injected objects will never be null. Another thing si we can create immutable object using constructor injection which is very very important right. Even if we make our fields final here there won't be any errors now. Which means immutable fields we can also inject now by using constructor injection. That's why it is useful and recommended as well.

And lastly, Fail Fast which means fail at compilation only in case of missing dependencies. For example, let's say one of the classes that we injected in constructor was not a component. Then it'll say application failed to start and it'll say that class we were trying to inject could not be found in the IoC container since we have removed @Component from it.

Now let's discuss the problems that could occur during dependency injection.

Let's look into Circular Injection first.

What we were doing till now is we are injecting order component inside your user right. We are auto wiring your order inside your user. What we are going to do now is we are going to inject this user as well inside yoru order component. So this becomes a circular dependency. Yoru order is dependent on user and user is dependent on order.

@Component

public class User{

Order order;

@Autowired

public User(Order order){

this.order = order;

}

}

@Component

public class Order{

User user;

@Autowired

public Order(User user){

this.user = user;

}

}

So spring is say we have circular dependency so go and fix it. So how can we resolve this? One way to resolve this is by using lazy annotation right. So lazy annotation is basically injecting beans whenever they are needed right. So how we achieve this by lazy annotation? What can do is while using @Autowired in constructor injection, we caa also use @Lazy along with it, which will avoid the cyclic dependency. We'll look into how lazy works in more detail later.

@Component

public class User{

@Autowired

Order order;

public User(Order order){

this.order = order;

}

@PostConstruct

public void init(){

order.setOrder(this);

}

}

@Component

public class Order{

User user;

public void setOrder(User user){

this.user = user;

}

}

Let's look into other problem of dependency injection, that is Unsatisfied dependency.

We have seen one kind of unsatisfied dependency when the objects that we were trying to inject into a compoent was missing in ioc container because it was not a component itself. Obviously in this case we are going to get some error that there is a dependency missing right.

Anthor behaviour of unsatisfied dependency is ambiguity when putting @Autowired on an interface and there are two classes that are implementing the interface with @Component. Now how will spring know which concrete implementation of that interface should it inject onto where @Autowired has been written. What we can do in this case is mark one of the classes that have been marked with @Component as @Primary so that will be the default concrete implementation of that interface for spring even though there are many component classes that implements it. We cna also use @Qualifier instead and give the bean name that we want to inject from the number of components that were implementing that interface by using @Qualifier("className") in camelCase.

So when we are trying to adhere to SOLID principles by using abstractions (interfaces) and there are multiple implementations of those interfaces then we can tackle them out either by using @Primary or by using @Qualifier annotations.

SPRING BOOT @ComponentScan

Have you ever wondered how application finds the beans? Finding the pojos inside your classes which needs to be converted to beans. How exactly it is scanning all the packages and looking for your beans. So the answer to these is component scanning.

So we'll first look into what exactly is the component scanning and the usecase of @ComponentScan annotation. Then we'll look into th earguments that we can pass into the component scan such as basePackages and exclusions.

So whenever your application is being initialized it'll look for beans right. So how does spring find beans? So suppose if spring does not know in which package are the beans kept so spring'll go through each one of your packages which might take some time. Instead suppose if it had some required metadata or required annotation through which it'd know exactly where to search for beans, it'd so easy for it right. So which package it should scan for beans that will be defined by component scanning.

What is the use case of component scan? Well scanning is fine but where is scanning taking place, that needs to be defined somewhere right, because we cannot just go ahead and randomly look into all the classes inside your application. So we need @ComponentScan annotation for that. But we haven't been using this annotation in our spring boot applicaiton right. Where is it?

So basically when we go inside the @SpringBootApplication annotation, we'd find that it is actually a combination of various other annotations. And @ComponentScan is present inside this annotation. So component scanning is already a part of spring boot application. The @SpringBootApplication annotation will contain that and you don't need to explicitly define that. This is the magic of spring boot. It does so many things behind the scenes that we won't even notice them.

So what happens is that all the subpackages from the class having @SpringBootApplication will be scanned for bean components by default. And any component outside of this default package where @SpringBootApplication has been written will not be scanned for beans.

Now we are going to study the arguments of component scan.

Now suppsoe we also wanted spring to scan for the components outside of its package, how would we do that? That's where we'd use @ComponentScan manually alongside @SpringBootApplication right. And we'll pass basePackages in its parameter like this.

@SpringBootApplication

@ComponentScan(basePackages = "com.example.default")

public class SpringApplication{

psvm{}

}

Now when we add basePackage in component scanning then it is only scanning that particular package only so that is something we need to keep in mind. However to add one more package over here, what we can simply do is use comma in between package strings. And because it is kind of an array it has to be enclosed within curly braches. Let me show you.

@ComponentScan(basePackages = {"com.example.default", "com.example.extras"})

There is a rule that we must look into: @ComponentScan should be used along with @Configuration annotation

Now, you'd say where did we used @Configuration annotation? It's working fine even without it. That's spring boot magic. It has already been implemented inside the @SpringBootApplication if we look deeper into it. Suppose for example, we'll scan it within a simple class like this.

@Configuration

@ComponentScan(basePackages = "com.example.extras")

public class Extras{

}

Now, let us take a look at exclusions/excludeFilters

Let's say there is some class that is now deprecated, and we don't want to include some class. I'd say exclude that particular class but include all the other classes. How do we do that exclusion? Well we have one more argument in @ComponentScan along with basePackages, that is excludeFilters. Now, this excludeFilters accepts another annotation @ComponentScan.Filter() which further takes 2 arguments for filteration. First it takes the kind of a filter type we want. Then it takes the class names that we want to exclude.

@Configuration

@ComponentScan(

basePackages = "com.example.extras",

excludeFilters = @ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, classes = {DeprecatedUtilityService.class})

)

There are some FilterTypes for this, that we can look into

1. ANNOTATION to filter that are marked with some annotation

2. ASSIGNABLE_TYPE to filter based on their certain type

3. ASPECTJ to filter that matches a given AspectJ pattern

4. REGEX to filter based on a given regex pattern

5. CUSTOM to filter based on a custom implementation of TypeFilter class

CUSTOMIZING BEAN NATURE

First we'll see what do we actually mean by customizing the nature of a bean. Then we are going to look into the interfaces to customize bean nature such as InitializingBean, DisposableBean. And another way ot customize beans using @PostConstruct and @PreDestroy annotations.

Let's say just after creating a particular bean I want to perform some certian action, it can be any action. For example, initializing any database connection. So those initialization aspect I want to perform right after creating the bean and before the bean is ready to use. Other thign I want to do let's say when we stop our application the beans that are created over here will be destroyed, so before destroying the bean let's say I want to clear some memory, that means I want to perform certain task before destroying the bean right. So these are custom actions we want to perform after creation of bean or before destruction of bean. That is what we call as custom actions where at being creation or destruction, we are customizing the nature of bean life cycle.

What exactly is custom action? We can let the bean perform certain action upon initialization and destruction of your bean, or we can let the bean perform certain actions after bean creation or before destroying bean. That is something which we can achieve by using this.

Let us go by the traditional approach first, that is by using interfaces.

Now, we have POJO classes which we apply inside our application and we will have some configuration metadata for example annotations. So what will happen in the traditional way, first when we start our application, your spring ioc container will be started, after that once the container is up, the bean creation will be started, so it'll find which packages to scan and it'll start creating beans. And how to know which packages to scan? By using @ComponentScan that we know now. While doing bean creation, there will be multiple dependencies. Let's say Class A is dependent on Class B. Then that dependency will be injected. So your ioc container will be started, beans will be created and dependency will be injected. After that your bean will be ready to use and will be used inside your application. Now let's say I'm stopping my applcaiton at that point when the bean will be destroyed, and after that the application will stop. Now that is the typical lifecycle of a bean.

Now let us add two more stages into it for custom action after bean creation and custom action before bean destruction.

Let's go into interface bean customization.

We can simply customize our bean by implementing " InitializingBean " interface and overriding it's method afterPropertiesSet().

@Component

public class Example implements InitializingBean{

public Example(){

System.out.println("Bean has been created");

}

@Override

public void afterPropertiesSet() throws Exception{

System.out.println("I come after bean has been created");

}

}

So before bean being ready and after bean has been created, we are doing our custom actions here.

Similarly we can use " DisposableBean " interface for custom actions before destorying having the method destroy() to be overrided.

Now let us look into @PostConstruct and @PreDestroy annotations.

What we have to do is use @PostConstruct on top of the method that you want to run after bean creation and that's it.

Similarly we can use @PreDestroy on top of some method and it'll run automatically before bean destruction.

So they may be behaving same as the interfaces internally but this is the modern way.

BEAN LIFECYCLE & SCOPE

Now we'll understand the scope of a bean and its four types with examples. That is: Singleton, Prototype, Request, Session.

Before that let's take a look at the bean lifecycle.

Now, let's jump right into the bean types.

What is a singleton bean? Well as the name suggests only single bean will be injected right. In the eager initialization, beans with singleton scopes will be initialized eagerly. That means when the application starts the beans with singleton scope will be initialized at that time only. When we do not give any scope then the default scope of our beans will be singleton.

Let's say we want to add some other scope to beans. Then how do we define our custom scope? For that we use @Scope("typename"). Like for singleton we use @Scope("singleton") and for prototype we use @Scope("prototype")

Now what is a prototype? In prototype each time new objects are created. And they will be lazily initialized, which means new object is created each time it is requested. Well all scopes other than singleton are lazy in nature. What do we mean by lazy? When it is required at that time only then it'll be created and not otherwise.

Beans with eager initialization that uses default singleton type will be created and injected first. But the lazy types will be created and injected when used later on, and if they are not used then they'll never be injected at all.

Now the third type is Request type. So inside request scope there will be one bean created for each request. Again this will be lazily initialized. Which means not at the time of startup rather whenever needed right. By request we're referring to http requests. So whenever a request is sent, beans with prototype will be created whereever needed. But suppose we want to put this request type in a component which is not a rest client. For that we have to use custom proxy mode.

@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)

There are in summary 4 scoped proxy modes. DEFAULT which is an alias for NO. When NO is used, it does not creates a scoped proxy, which is not useful when beans are non-singleton. Then we have INTERFACES which creates a proxy implementation of interfaces to expose class objects. Finally, TARGET_CLASS is basically used to create a class-based proxy.

Now beans that are of session type have a behaviour such that new object is created for each http session. They are also lazily initialized. So whenever user accesses any api a session is created right, so there can be multiple requests inside your session. And it remains active till the session gets expired.

SPRING BOOT @ConditionalOnProperty

Annotation

Let's say we have a spring application with thousands of beans. So thounsands of beans are being created inside your application context that will likely create a chaos right because your application will be bombarded at one time right. Because all the beans are craeted while your application is coming up at first place perhaps you don't need all the beans and you may only a few beans at first. But these unneces sary beans are also getting initialized in your application context. In this case, your application context will be cluttered right. So that is one of a kind of problem right. What we can do is initialize only those beans which are needed at the time of initialization so that your application loads faster and your application contexts gets declutterd. And we can do this by using conditional on property.

What exactly is condition on property? Well beans are created on some certain conditions. If your condition is true then bean will be created and if your condition is false then bean will not be created.

Assume a scenario to handle, that we want to create only one bean that is either MySqlConnection or NoSqlConnection. Another scenario to handle could be, we have 2 components sharing the same database, but one needs MySqlConnection and the other needs NoSqlConnection.

@Component

public class DBConnection{

@Autowired(required = false)

public NoSQLConnection nosqlcon;

@Autowired(required = false)

public MySQLConnection mysqlcon;

@PostConstruct

public void init(){

System.out.println("Initialized Connection");

}

}

@Component

@ConditionalOnProperty(prefix = "nosqlconnection", value = "enabled", havingValue = "true", matchIfMissing = false)

public class NoSQLConnection{

public NoSQLConnection(){

System.out.println("NoSQLConnection Init");

}

}

@Component

@ConditionalOnProperty(prefix = "sqlconnection", value = "enabled", havingValue = "true", matchIfMissing = false)

public class MySQLConnection{

public MySQLConnection(){

System.out.println("MySQLConnection Init");

}

}

Let's see what exactly these parameters do. Now prefix plus value will create your key. What key will it create? A key which it will try to find a configuration. Where it will try to find configuration? Inside application.properties. So what it will do? It will try to find the prefix plus value inside your application.properties. And having value is the value for it. So let's see.

nosqlconnection.enabled = true

sqlconnection.enabled = true

If these properties having true as the value then we create the bean. As simple as that. Let's say I have it as false. In this case, it won't create. Because it is checking for true right. So the string in the havingValue parameter must match the value that we give in application.properties.

Now suppose your configuration itself was not present in application.properteis. In that case, what matchIfMissing does is if you mark this as true then it'll still inject the bean otherwise it'll not inject the bean. So this is basically fallback mechanism. If this configuration is missing then what are we going to do thenthis is something which comes into picture.

Now suppose we write our application.properties to not match like sqlconnection.enabled = dontcreate. Then what happens is the bean will not be created. But because we have injected that bean somewhere as a dependency then our application may fail. That is why we have marked @Autowired(required = false) in DBConnection for this particular case to demonstrate. Because if go inside @Autowired it has a required parameter which is by default always true. In our case, it may or may not come right, it is not mandatory. When we have marked sqlconnection.enabled = dontcreate then it'll not be matched with havingValue and the MySQLConnection bean will simply be null.

So what are the advantages of doing this? Well it gives us kind of Toggling feature. It avoids cluttering application context with unnecessary beans. We can avoid a few beans which are going to be created at the runtime which are not needed right. If they are not needed why to create them upfront? It saves memory for us. And also reduces application startup time.

But there are some disadvantages as well? Like misconfiguration can happen. Code complexity increases when over used. Complexity in managing.

SPRING BOOT PROFILES

First we'll see what exactly is Profiling? And then how are we going to use that profile inside our spring application. After that we'll see the @Profile Annotation.

Let's say you have application running on your local machine. Now here this is your local machine and you are going to connect to your database and that will require some user id and password. And where do we provide this application in configuration? The configuration file we call it as application.properties which are used to configure all the properties which are needed for your application.

Let's say we have given username, password in application.properties to connect to database, then you can use it in your java classes as

username = devUser

password = devPass

Then in your java classes, we can use these values like this using @Value annotation.

@Component

public class DBConnection{

@Value("${username}")

String username;

@Value("${password}")

String password;

}

Now let's say we pick up this application and we deploy it in another environment. By environment I mean let's say QA Stage where testing people deploy their code and test in separate environment. However, the username and password before belonged to the local database. But now in this case, we want the username and password for QA database. So that will be different and what we need to do is update the password and username in application.properties that's it.

Again tomorrow let's say you are going to go live with this code. You are going to deploy this in production. Now this database would need different configuration. And this is just an example. There are multiple properties that you need to configure right. There are so many other configurations, which are different in different environments. For example, URL, Port, Connection Timeout Values, Retry Count and many more.

But how do we handle different configuration for different environments? We canot go ahead and change it over here and then deply right. So this is when profiling comes into picture. Suprisingly, we can create multiple application-{profileName}.properties files like this.

But how do we set profiles? At application startup we can tell spring to pick specific application.properties file.

Let's say we have application-dev.properties and application-prod.properties and each of it has different database username and passwords

How are we going to tell our spring boot application that go ahead and pick this dev properties for me and don't pick it from prod properties for now? So that is when how to set profiles comes into picture. At application startup we can tell spring to pick specific application.properties file using spring.profiles.active configuration. We can have application.properties which is kind of a parent property that we have and here we add this profile like this:

spring.profiles.active=dev

By writing this in our parent property, that is application.properties we can run our application-dev.properties file and set active profiles.

Suppose spring was not able to find that specific property then default values from application.properties will be picked up. Now suppose we not have given the default values and further the profile that we marked as active was not found by spring. Then our application may broke and say, Injection of autowired dependencies failed. So because it was not able to find the configuraiton so your application initialization itself is failed.

Let's say I've moved from dev environment to production environment. I need to still go ahead and makes changes over to that one line in parent property right. So that again involves code changes because this application.properties is again inside your application only. So basically we need a way to externalize things without making code changes inside your application. What we want is we want to provide this active profile from outside the application while running the application? So let's say there's a jar file with me. We run that jar in our production or dev envionment and provide this active profle dynamically.

So how do we configure profiles dynamically? Basically there are 2 ways by which we can achieve that. First one is application startup by using command. Basically we can start our application manually and provide profile to it like this.

mvn spring-boot:run -Dspring-boot.run.profiles=prod

So the first keyword mvn is maven, and then spring-boot:run is a command that runs your application. After that hyphen D means we are going to set a parameter right. Where? spring-boot.run.profiles and then we specify which profile word matches with application-{profile}.propertices and runs that configuration.

So this is how you can externalize your configuration of profiles right.

Another way is by using pom.xml file. What we can do is add profiles in your pom.xml file as well. And run using this command instead.

mvn spring-boot:run -Pproduction

<profiles>

<profile>

<id>production</id>

<properties>

<spring-boot.run.profiles>prod</spring-boot.run.profiles>

</properties>

</profile>

</profiles>

This is basically how we can add profiles in our pom.xml file. This is placed below the <build> tag and outside of it.

Now let's see what is @Profile annotation? So by using profile annotation we can tell spring boot to create a bean only when particular profile is set. That means if we set let's say dev profile inside our application.properties then profile annotation will tell particular bean should be created or not. Let's see how? Simply by using @Profile("profileName") according to application-profileName.properties on top of that bean we want to run for our profile.

Global Exception Handlers

& Controller Advise

So first we are going to see a traditional way of handling exceptions. So whenever client is calling your api, how do we handle exceptions and how do we propagate errors to respective clients right? After that we are going to see how exception handler comes into picture and how it helps us in order ot handle exceptions. Then we will see what is the need of controller advice. Why is it needed? So that's something which we are going to answer. After that we will see the actual implementation of controller advice as well.

Now let's try to visualize it right. Let's say we have this client whihc is kind of a postman in our case, sending a request to our application, let's say here we have this particular application over here, so request is coming to our controller, and then it is going to service, then to repository, and then finally the call is going to database right.

Let's say there is no product found inside this particular database over here right. Then what will happen? Then our repository and service will be null right, and this controller is going to throw an exception to the client that our product is missing. What we do is we handle the exception inside our controller only. Now as per traditional approach, what we usually do is add a try/catch for each and every function in controller. But we can use an @ExceptionHandler so that all the error responses will be thrown by this exception handler and duplicacy in code is reduced.

Now consider this exception handler as a smaller package inside your controller which will handle all the exceptions that are being thwon to the client. So in case of any exception coming, controller will not give the response rather the exception will be handled by this exception handler. And this exception handler will give the responses to client.

Suppose we have created a rest api in controller for products and we have to write a product not found by id exception. We have written a custom exception that extends RuntimeException. What we will do is pass the class file of this custom exception class into the @ExceptionHandler parameter on top of a function that takes the instance of that custom exception class which has been instiantiated whenever a runtime exception occurs. Then we can handle it accordingly for any runtime exception irrespective of the route in which the api call has been made.

@ExceptionHandler(ProductNotFoundException.class)

public ResponseEntity<> handleException(ProductNotFoundException e){

return new ResponseEntity<>(e.getMessage(), HttpStatus.NOT_FOUND);

}

Now the apis inside our main controller that are throwing an exception is being handled by the exception handler annotation. But let's say we have another rest controller. Now suppose this second controller was for some processing with another database. And we want to throw same exception over here as well if product not found. However, exceptions inside our second controller will not be catched by this exception handler because this exception handler is of the main controller only. One obvious solution that comes into mind is to copy the same exception handler code into the second controller as well. Well that may definately work. But this code is repeated in each controller right. Suppose if I have a thousand controllers where other thousand controllers are throwing product not found exceptions. Then are we going to go ahead and add this particular exception handler in each controller. Not a feasible appraoch right. It is when controller advises comes into picture.

Now what controller advice is that it will allow your exception handlers at a generic place in a generic file. It will allow us to centralize our exception handling. Let's see how we can implement that? What we can do is add a GlobalExceptionHandler class alongside your controllers and write the same @ExceptionHandler function over there and remove it from all controllers. Now what we have to do over GlobalExceptionHandler class is add a @ControllerAdvice annotation in order to convert this exception handler to controller advice. That's it.

Now there is one more annotation that we can use that is @RestControllerAdvice. It is basically for response body plus controller advice handling right. If you go inside you'll see it's an alias of controller advice and also has a response body.

Suppose we use a simple @ControllerAdvice and try to return just a string when exception is thrown. In that case, that string internally will be treated as a view that servlet will try to find by name of that string plus .html extension, and if that file is not present, it returns an error saying unspecified view. Remember that we can solve this by using @ResponseBody annotation. So @ControllerAdvice do not have any response body by default unless we use the ResponseEntity class. However, by using @RestController, the default behaviour is returning response body.

In our GlobalExceptionHandler, we can add as many exception handlers as we want in a generic place where each custom exception extends a specific type of exception and handled it in all controllers accordingly. For example, let's see the code.

@RestControllerAdvice

public class GlobalExceptionHandler{

@ExceptionHandler(ProductNotFoundException.class)

public String handleNotFound(ProductNotFoundException e){

return "Product Not Found";

}

@ExceptionHandler(MaxOrderException.class)

public String handleMaxOrder(MaxOrderException e){

return "Maximum Orders Reached";

}

}

@Aspect Annotation

Aspect oriented programming complements oop concepts in a manner that instead of objects we now have aspects. These aspects enable the modularization of concerns that cuts across multiple types and objects. This may be complex to understand but we'll simplify it.

They are trying to say AOP will handle cross cutting concerns. When they say cross cutting concerns, it mean that things that we do apart form business logic. Let's say there is one method which is doing some business logic right and now you have some other code which is doing some other thing for example having loggers inside that method right. Now loggers and that are not a part of business logic. And that is something which you are doing for logging purpose right or debugging purpose in the latest stage when you are going to deploy your application and logging will be useful for monitoring and all later on. But this is different from the business logic right. For example, logging is your cross cutting concern which is different from your business logic.

For a class that has bussiness logic as its core functionality. Logging is an overhead concern and therefore called a cross cutting concern.

" Aspect enables separation of cross cutting concerns from your actual business logic. "

Let's look into AOP Concepts one by one.

A join point is represented by a method. Before invocation of a method or after invocation of a method, we are going to call our aspect. So that method becomes a join point for our aspect.

Advice is an action taken by an aspect to a particular join point. Like for example if we separate the logging concers in a class aop, then the call will pass through that aop class before invoking the actual business logic method. We have different types of advices such as "around", "before", "after", which will look into soon.

Now this method aspect over here only needs to be called on the methods of class. Let's say I only wan tot call it before or after or around, but on which class we want to call this aspect, or I would say on which method we want to call this aspect, everything will defined by using a point cut. And that point cut will be present over here on top of this particular method. We'll clear it shortly, but just keep in mind that point cut is about which particular class or method this particular aspect should be applied to.

Spring AOP is proxy based. Let's see what are AOP proxies? But first let us know what is a proxy? A proxy is basically an object which surronds the pojo object. When someoen is calling your code, the call will first land inside your proxy and then the call will be diverted to your plane object. They are saying proxy can delegate to all the interceptors (advice). That may sound confusing. Let's understand it.

The call will first land to the proxy of this class, and now we are inside the proxy. Now the proxy will check if we have any aspect for this particular class right. How will it check? It will check by using point cut expresssion. It will check if we have any aspect of this class. If we do have the aspect then proxy will call this aspect first and do whatever is needed, and after calling that depending on point cut expression, it will finally call your method join point. So that is the flow and use case of proxy. So what we understand by this is that method calls on that object reference are calls on the proxy.

Let's go straight into annotations first. @EnableAspectJAutoProxy is required alongside @Configuration. However, we have the magic with us. @SpringBootApplication annotation already has them by default. So we need not to worry about configurations, and we can go straight into using aspects.

Suppose we want to use Aspects for logging purposes which separates the concers with the business logic. So what we can do is use @Aspect annotation on a class. Let that class name be LoggingAspect. Now we can add any methods to these class. And we can run them as per advices and point cuts. Also remember that an aspect is also a component.

As we have seen, advices are @Before, @After, @Around. And then we have point cuts, which points to the exact location of methods. A point cut also takes a declaration which tells how our advice function is supposed to run on those point cut functions. Let's look at the code.

@Component

@Aspect

public class LoggingAspect{

@Before("execution(* com.demo.example.ExampleClass.helloWorldMethod(..))")

public void log(){

System.out.println("Aspect log called");

}

}

Here, @Before is an advice. The string inside is a declaration. Inside the declaration, we have the point cut. The point cut is like this. First is *, that means any return type. Then we have the package name and specific class name and then specific method in that class following by any parameter of that class. We could also do something like com.demo.example.*.*(..) which would mean any class and any method within a package. However, being specific is preferred for clean code.

Now what will happen is the aspect will find the exact method in the exact class within the exact package, and run that advice method before the it joins the point, that means before it executes that method. And similar is the approach with @After and @Around.

@Around is little more advanced. It has to take the class ProceedingJoinPoint as the parameter in the advice function where you define @Around on top, and then it has to specify the split with .proceed() method. Basically, advice with @Around runs before the point cut function on which it is being called, but when we call proceed() within this advice function, then the call is passed to the point cut function, and when the point cut function ends it's call, then it returns back and completes the remaining function. Let's see the code.

@Component

@Aspect

public class LoggingAspect{

@Around("execution(* com.demo.example.*.*(..))")

public void log(ProceedingJoinPoint joinPoint) throws Throwable {

System.out.println("Aspect log called before");

joinPoint.proceed();

System.out.println("Aspect log called after");

}

}

SPRING BOOT TRANSACTIONS

Code segments where shared resources are being accessed and modified are our critical operation code sections. For example, let's say there are multiple people who wants to book a flight right basically long weekends are coming and people want to go to Goa right. Now they want to book a flight over here. And let's say everyone wants a window seat right. Now multiple people will hit the same request to book a window seat right. Let's say there is just one window seat left. And these people are hitting the request to book that particular window seat.

Now what will happen over here is we will first read the flight seat with id_number, and we will check if the seat status is available right and if it is available then we'll update the status to booked right. Now what will happen if the simultaneous requests are coming with three users at once and your database will read that the status is available. Now the booking status may be updated for all three users as booked right. All three of them will think that okay my seat is booked but when they onboard, there will be a chaos right, so that situation may happen over here. That there will be inconsistency of your data if you hit multiple requests and try to access a same resource.

" When multiple requests try to access the critical section, data inconsistency can happen. "

What is the solution? Basically Transaction right.

Transaction helps us to achieve ACID properties. So what are ACID properties? Atomicity, Consistency, Isolation, Durability.

Atomicity ensures that all operations in transactions are completed successfully. And even if any operation fails then entire transaction is rolled back.

For example, let's say you want to send some money to your friend. Now, let's say you are sending 100 rupees to your friend. You initiated a transaction, and 100 rupees got debited from your account. Then the requests went to the bank. And bank is transferring that money to your friend. But while transferring this money, there is some error that has occured. So the money got debited from your account but never credited to your friend's account. So this is basically a classic problem over here. In such scenarios, if there is some error which is occuring inside your tansaction, then the entire transaction should be rolled back. That is the debited money from your friend's account should get credited back. So that's what we call as a rollback. And that covers our atomicity.

Consistency ensures the database state before and after transaction is consistent.

We have to ensure the database state before and after transaction is consistent right. So even if the transaction is failing, the database state of both the users is consistent right. The user had 100 rupees before transaction and it's still there after transaction failure. Basically no change inside the account of both the parties. So that is basically consistency.

Isolation ensures that if multiple transactions are running in parallel, they do not interfere with each other.

So if there are thousand people who are sending money to each other, the transactions will be different right. They will be in parallel in your application. Ther may be multiple things which are happening in parallel, multiple transactions which are running in parallel but even if those are in parallel, each of the transaction is working in isolation right, each of the transaction is running in isolated state, they are not interfering with each other. So that is basically isolation.

Durability ensures that committed transaction will never be lost despite of system failures.

That marks the end of ACID properties.

Let's look at how a typical transaction looks like.

BEGIN_TRANSACTION

- Debit From A

- Credit To B

If All Success

COMMIT;

Else:

ROLLBACK;

END_TRANSACTION

Now we could see a lot of bolier plate code in a typical transaction that may be similar for nearly all transactions. That is where AOP comes into picture. It'll handle the boiler plate code and let us focus on our business logic. Let's say you have a thousand methods, and each method if you start handling every step of transaction manually then what'll happen is it'll be kind of a chaos right. And you'll have to take care of a lot of things.

This is when spring transactions comes into picture. We don't need to handle these things manually right. We just need a transactional annotation on that method we just need to annotate. However, to begin with spring transactions, we need a dependency that'll need to add to pom.xml file. That is spring-boot-starter-data-jpa.

Where would we handle the transactions? In service, as the service handles the business logic. There we'd annotate any method having a critical section suppose add() with @Transactional on top of it. So this @Transactional annotation can be applied either at a class level or at a method level as well. When we do this at class level, then it is enabled for all methods of that class. Note that transactions cannot be applied to private methods. So even if you annotate a private method with @Transactional annotation that is of no use, because they simply cannot be a transaction.

There is one more configuration that we have to use @EnableTransactionManagement alongside @SpringBootApplication annotation. However, we don't have to care much about it as we have enabled auto configuration, and spring will take care of it for us, so this is not needed, but if spring is not doing auto configuration then we'll need this.

Let's go deep into how Transaction Management in spring works. Basically, it uses aspect-oriented-programming heavily, which uses a point cut expression right and it uses a advice right. So advice is basically a method which runs before or after a certain function right. So we have this function that has @Transactional on top of it. Before and after execution of this function, a certain method will run that is called as advice and that will be executed based on a point cut expression which we have seen already in aspect-oriented-programming. So basically how spring works is it uses a point cut expression to search methods having transactional annotation right. We have seen how aop works internally right. So at the run time only it will create all the proxies which are needed in order to execute these methods right.

Now this is how your point cut expression may look like right now within the method which are annotated with @Transactional within the method or classes. Now we have an advice over here. Let's see it.

@within("org.springframework.transaction.annotation.Transactional")

So this particular method is basically present inside TransactionInterceptor class which is kind of an inbuilt class inside your spring framework provided by spring, and that will have invokeWithinTransaction method which is kind of advice. So once the point cut expression matches, it will run "Around" type advise. So we have seen in aop that @Around handles both before and after, and the switch form before to after is with proceed() function.

Now the invokeWithinTransaction method actually has three jobs. First it'l initiate a transaction. Then it'll invoke your class. Then it'll commit the transaction. Or in case of any exception it'll just roll back itself. If we go inside the invokeWithinTransaction method, we see that it first calls the createTransactionIfNecessary method. Then it proceeds with the around advice .proceedWithInvocation() invoking the next interceptor in the chain which normally results in a target object being invoked. And finally completeTransactionAfterThrowing() method will rollback itself if there occurs an exception during the transaction. If no exception has occured then instead of this commitTransactionAfterReturning() method will be called.

If we actually debug the method with @Transactional, we could see that spring is calling the createTransactionIfNecessary() method first through the annotation before calling the actual method on which the annotation is being applied. So the advice is being invoked within transaction. Then it proceeds with invocation which moves ahead with the actual method we called which will do all the business logic operations and come back to the invocation. And then it'll call the commitTransactionAfterReturning() method to commit at the end. That's the way it works.

Suppose if we throw a RuntimeException explicitly to demonstrate that an exception has occured during transaction, then it'll automatically invoke completeTransactionAfterThrowing() method from the invokeWithinTransaction() method which is rolling back the transaction.

Basically creating proxy and everything applies here as it applies in your aop. And that is how our transaction is working internally and invoking advices around the methods which are annotated with @Transactional annotation.

Let's look into Transaction Managers and both Programmatic and Declarative approaches.

What is transaction manager now? It is basically responsible for manging your transactions like getting your transactions, commit to it and rolling back. So all the transaction operations are handled by your transaction manager inside spring. They'll understand the particular transaction manager hierarchy. Transaction manager inside spring is basically an interface right. So it is a parent interface.

On the top we have a transaction manager which is kind of an interface which do not have much things. And your PlatformTransactionManager interface extends this particular interface which will have three abstract methods in the interface which is getTransaction(), commit(), and rollback(). Now that particular implementation is provided by AbstractPlatformTransactionManager which is an abstract class So basically it provides the implementation of these methods. So these particular methods will be used when we actually use transaction inside your spring framework right. Now this abstract class will be used by your different transaction managers inside your spring application. Basically, there are multiple transaction managers. For example, DataSourceTransactionManager which is used for JDBCTransactionManager. We can also have HibernateTransactionManager or JPATransactionManager. And we'll choose just one between them. Basically, spring will choose for us. Mostly, it chooses JPA at runtime which has simple operations.

The first three Transaction Manager concrete classes are used for our local transaction management. And the fourth one JTA TransactionManager is generally used for two-phase commits for distributed transaction management. Otherwise, the other three transaction managers are used.

Now, let's look into the type of transaction managers, which are declarative and programmatic.

So, declarative transaction management is kind of done heavily through annotations. Declarative means to declare a transaction and the job is done. Whatever we are looking into till now is a declarative way of define your transaction right. So by now we were using @Transactional annotation only right. And spring boot will choose the appropriate transaction manager for us. We have seen that it was choosing JPA transaction manager for us. And we can create an explicit transaction manager and tell spring to choose that as well.

So suppose I don't want what spring chooses for me. Rather I want to tell it explicitly which transaction manager to choose. Let's see how we can do that?

@Bean
public DataSource dataSource(){
DriverManagerDataSource dataSource = new DriverManagerDataSource();
dataSource.steDriverClassName("org.h2.Driver");
dataSource.setUrl("jdbc:h2:mem:testdb");
dataSource.setUsername("root");
dataSource.setPassword("Password");
return dataSource;
}
@Bean
public PlatformTransactionManager transactionManager(DataSource dataSource){
return new DataSourceTransactionManager(dataSource);
}

So here we have given our own data source of H2 database. What we have to do is tell spring while using @Transactional(transactionManager = "transactionManager") that use this particular transaction for me. Here, we are giving the same name as function name of that bean that returns the new datasource. In order to demonstrate we have seen that we can also do it this way. Now instead of JPA transaction manager, we have dataSource transaction manager.

Let's look at Programmatic transaction way.

As the name suggests, programmatic means handle your transaction programatically through a code, that means don't use annotations and write a code. Now we have discussed that boilerplate code will be handled by aspect oriented programming. Then why to go and write a code in order to handle the transactions? Basically the answer is a specific use case in which this type of transaciton management could be used.

Let's say you have a class, and you have updateUser() method which is doing three things, updating the database, then it is calling an external api call, and then again it is updating the database. And then we are done. So, while it is hitting the external api call, it'll go and hit the call and keep waiting for the response right. Meanwhile, your database connections and everything is there. Let's say the connection took 2 to 3 seconds, and for that particular time, the connection is not released. This particular function is holding that one okay. Now when you scale your application and put it in production, there is such cases where your connection is not being released quickly, and that can be the bottleneck issue. In such scenarios, we should not make a use of @Transactional rather we should do a programmatic approach and we handle those operations explicitly. So that is when programmatic transaction managers comes into picture. So, it's basically flexible but it's difficult to maintain right.

We're going to look into two approaches for the programmatic approach. What we have to do is create a component class, and inject the PlatformTransactionManager object into the class through constructor injection at runtime. And this object will come from the dataSource we have created above in AppConfig configuration class for example. Now what we have to do is get the TransactionStatus object instance in a method suppose updateUser() by using getTransaction() method on it. Remember that our PlatformTransactionManager had 3 methods within it that is getTransaction(), commit() and rollback() and we are going to use just them. What we are doing is directly calling these methods from this interface and they wll be dynamically resolved at runtime from the abstract class the implemented that interface that is AbstractPlatformTransactionManager.

@Component
public class FirstProgrammaticApproach{
PlatformTransactionManager transactionManager;
public FirstProgrammaticApproach(PlatformTransactionManager transactionManager){
this.transactionManaager = transactionManager;
}
public void updateUser(){
TransactionStatus status = transactionManager.getTransaction(null);
try{
System.out.println("Do Operations");
transactionManager.commit(status);
} catch(Exception e){
transactionManager.rollback(status);
}
}
}

The second approach of programmatic transaction management is by using TransactionTemplate which will handle all the boilerplate code for us, and we need not to write each and everything explicitly. What we have to do is create an instance of TransactionTemplate instead of PlatformTransactionManager and use the constructor injection again as we did before. Where this TransactionTemplate bean will come from? Then we have to add a @Bean for it.

@Bean

public TransactionTemplate transactionTemplate(PlatformTransactionManager transactionManager){
return new TransactionTemplate(transactionManager);
}

Now let's look at the code implementation of second approach.

@Component

public class SecondProgrammaticApproach{
TransactionTemplate transactionTemplate;
public SecondProgrammaticApproach(TraansactionTemplate transactionTemplate){
this.transactionTemplate = transactionTemplate;
}
public void updateUser(){
TransactionCallback<TransactionStatus> dbOperationTask = (TransactionStatus status) -> {
System.out.println("Perform Operations");
return status;
};
transactionTemplate.execute(doOperationTask);
}
}

Here callback is the task you want to create, and we are doing this by using lambda expressions. Here, we are just executing a particular task inside the transaction callback and we are just returning the status code. So when we do execute, then all those boilerplate code things will happen internally.

Transaction Propagation

We'll look into each of propagation ways such as REQUIRED, SUPPORTS, MANDATORY, REQUIRES_NEW, NOT_SUPPORTED, NEVER, NESTED. But let's first understand what exactly is transaction propagation? As the name suggests, how the transaction should be propagated to other method right. That will be decided by your transaction propagation. So transaction propagation refers to how transaction behaves when a method annotated with transactional is called by another method that may or may not have transactions right. For example, there is one method and there is another method inside your same application. However, they may or may be in same class okay. Let's say one of them has @Transactional annotation on them. Then in this case, what will happen? How the transaction of method one will be propagated to method two. Suppose if method one only has @Transaactional annotation. Then does method two needs any transaction? If it does not needs it then what exactly needs to be done? All these things will be handled by propagation inside your @Transactional annotaiton. So depending on your use case, spring will handle propagation for us, as we can specify the propagations on the respective methods according to our scenario and we can get the task done. That's where transaction propagation comes into picture.

When we do not mention any propagation way then REQUIRED is the default propagation behaviour of @Transactional. So it works something like this. @Transactional(propagation = Propagation.REQUIRED). However, we need to mention it for the case of REQUIRED because it is default. When it comes to understanding this default behaviour, required means that this particular function requires a transaction. So basically if the transaction is already active, it will join the same transaction okay, or even if we do not have transaction in the calling method, then it'll start a new transaction. So suppose controller is calling the method on service where we have put @Transactional on top of a method, however we do not have @Transactional annotation in the parent caller in controller that is calling the method to the service where we actually handle the transaction. So, even though the one who started the transaction does not have a transactional annotation, the method call will still be started with a transaction. Another situation is suppose the parent caller in controller and the method being called in service both have @Transactional annotation on top, then they will join the same transaction that was started earlier by controller instead of creating a new one. So these are the two common scenarios of understanding REQUIRED propagation.

Basically the default propagation says that the function is joining the existing transaction which is coming from the calling method which is kind of a method inside controller. So this behaviour is not creating any new transaction. Now there is a keyword named REQUIRES_NEW propagation which always creates the new transaction in such scenarios and never joins the already existing transaction. But the question is why do we need to create a new transaction? Basically we use REQUIRES_NEW propagation whenever we want to isolate a particular transaction form other sorrounding transactions. For example, we can use requires new while we are doing logging or auditing for certain cases right or whenever we want to perform some independent operations which are isolated from your existing transaction. The famous example of that would be sending a notification right, you are doing a certain task but you want a notification to be sent to client in a different transaction that is something you can handle inside requires new. Another famous example where you can use requires new, basically whenever you want to implement a retry mechanism right, and each entry could happen in a new transaction. That is when REQUIRES_NEW comes into picture. In a nutshell, what it does it it'll suspend the existing transaction which is coming from your calling method and it'll start a new transaction over here.

Now when we propagation as MANDATORY, it enforces that there should be a existing transaction present in the calling method. That means this function should not start any transaction rather the calling method of this method which we called should already have a transactional annotation. Let's say if the calling method does not have any transactional annotation. Then this method that we called will not start any new transaction rather throw an exception that there should be active transaction present in order to propagate that particular transaction. So this MANDATORY propagation is useful when you want to enforce that there should not be any new transaction created rather things should work inside the existing transaction and there must be a existing transaction present while someone oen calling this particular method. To put simply, this is basically enforcing the exisitng transaction present.

Now when we mark a transaction as NESTED, that means if the calling method have a existing transaciton then this method will run in same transaction in a nested way. However, if the calling method does not have a transaction annotation then this behaves like a required type and it'll simply start a new transaction.

Now by nested way, we mean that it'll eventually join the existing transaction but it'll create a save point at that point okay, and then the transaction will run ahead of that save okay okay. If for instance, there is some exception that has occured, then only that particular transaction upto taht save point will be rolledback and the existing transaction before that save point will not be rolled back. So NESTED is basically useful when you want to do partial rollbacks, like only rollback just this function and not rollback the entire transaction.

Now when we mark a transaction as SUPPORTS, that means this particular function will support a transaction if the calling method have transaction right. That means if the method that has been called from the controller have any transaction then our method in the service will support the transaction and have it, otherwise if the calling method form the controller does not have any transaction then this method being called in service will also not have any transaction.

Now NOT_SUPPORTED means that if the calling method have existing transaction then for this particular method only, the transaction will be suspended right, and after this particular method the transaction will be resumed again. That means this particular function will not run inside any transaction. So the usage of this is straightforward, whenever we don't want any transaction and we want to skip the transaction for certain methods, then we can do it.

Now NEVER means that this particular method should not run in any transaction. If the calling method of this particular method have a transaction then this method will throw an exception saying that there is already ongoing transaction and I don't want to interfere that transaction. It'll throw IllegalTransactionStateException saying that Existing transaction found for transaction marked with propagation 'never'.

Isolation Levels

Adding an isolation level on a transaction is pretty simply right. We have to add that up in the parameter of our annotation.

@Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.DEFAULT )

Let's first discuss what is an isolation? Let's say we have multiple transactions running in parallel right. Let's say you are working in multi-threaded environment and there are multiple transactions running. Now how is Transaction A is isolated from Transaction B? What is the impact that they have on each other? How Transaction B is separate from Transaction A? That is something which we define as the Transaction Isolation Levels. How these two transactions running in parallel will impact your data? Isolation is basically a global concept whereever we use transasction right. Not just related to spring, it'll be a global concept basically everywhere when we talk about transaction.

Now the next question is, Why Isolation? We have different levels of isolation and they are introducted because they are solving some problems while running a parallel transaction. What problems are they solving? They are solving dirty reads, non-repeatable reads, phantom reads which we already know.

READ_UNCOMMITTED says that it allows a row changed by one transaction to be read by anotehr transaction before any changes in that row have been committed. And if any of the changes are rolled back, the second transaction will have retrieved an invalid row. It indicates taht dirty reads, non-repeatable reads, and phantom reads can occur here. If it has so many problems then why are we even using it? It is particurally used when we are using a particular data source for only reading the data then it's fair. However, for updating and deletion stuff, it's better to go a higher isolation level.

READ_COMMIT says that it prohibits a transaction from reading a row with uncommitted changes in it. However, it says that dirty reads are prevented here, but non-repeatable reads and phantom reads can still occur. Here dirty read is being prevented using locks.

REPEATABLE_READ says that it prohibits a transaction from reading a row with uncommited changes in it, and it also prohibits the situation where one transaction reads a row, a second transaction alters the row, and the first transactionr re-reads the row, getting different values the second time (a "non-repeatable read"). Thus it indicates that dirty reads and non-repeatable reads are prevented but phantom reads can occur.

SERIALIZABLE says that it includes the prohibitions in REPEATABLE_READ and further prohibits the situation where one transaction reads all rows that satisfy a WHERE condition, a second transaction inserts a row that satisfies that WHERE condition, and the first transaction re-reads for the same condition, retrieving the additional "phantom" row in the second read. It indicates that dirty reads, non-repeatable reads, and phantom reads are prevented.

SPRING DATA JPA

Now whenever your repository layer is talking to the database layer, there should be some kind of connectivity between these two right. There should be some kind of connectivity between your java application and the database right. Let's see the traditional way first, so if we go by using the JDBC, still we'll able to connect to database right. Let's look into it in more detail.

First, we load the JDBC driver, and after that, we establish a connection between your database and your application by using some classes like driver manager right, then we need to create SQL queries right, then we need to prepare a statement, and after that query might need some parameters, like you have entity or object and thoes entities are mapped to this query right, and those parameters needs to be set, so we used to write a lot of code in order to do that, and at the end, we used to execute the query right that will actually hit.

Now, spring JDBC comes into picutre. And this is a framework which automates a lot of these things for you right. It's still a jdbc connection but it'll automate this boiler plate code for you.

Now let's look into the concept of ORM. What is ORM? ORM is basically object relational mapping. The term itself defines what exactly it is. The relationship between your object and the relational database that you have. For example, SQL right. So it's a mapping between your object and relational database. Now, when you are defining your java object, it'll have some kind of fields. Let's say if you're talking about user, you'll have id, name and a lot more things. So in a table, you've some columns of the table with same names as your fields. So it looks like kind of a direct mapping right. That is when ORM comes into picture. It provides the direct mapping between your entity (object) with your table. For example, let's see the code.

@Data

@NoArgsConstructor

@AllArgsConstructor

public class Book{

@Id

@GeneratedValue(strategy = GenerationType.IDENTITY)

private Integer id;

private String title;

private String author;

private String genre;

}

We'll understand the annotations in the code snippet above in a while, but first focus on the point that these fileds can be direct columns inside your table and your table can be mapped right. So, " Java object to table mapping is basically ORM. "

When there is a mapping between a java object and the orm, then entires are automatically added to your database on an object creation. And the data in a database should be updated and deleted as per the java objects automatically. Now, who is going to manage this mapping? Who is going to retrieve the data? Who is going to update and delete data inside this table? That is when framework comes into picture. Who is going to automate all of these things for us? Right. Now the famous framework for ORM is Hibernate. Although there are other famous frameworks as well such as EclipseLink and OpenJPA.

Now what exactly is JPA? JPA is basically Java Persistance API. It is not a framework like Hibernate. It is basically a specification provided by Java in order to manage relational data inside your application by using OOP principles. This is essentially a set of interfaces or we can say a set of guidelines right. This needs implementation. And who provided that implementation? It is again Hibernate. So Hibernate is basically implementation of JPA. And internally JPA is basically using JDBC in order to do database connection right. So it is kind of a hierarchy right.

Now there may be a question. Why exactly do we ned JPA and why not Hibernate? If JPA is internally using Hibernate then why not just use Hibernate as a default behaviour. Well, we can use that and precisely no one is stopping us from doing that. But in case we need to migrate away from Hibernate then we'd need to do a lot of changes inside our application. Now because JPA is kind of a standard practice so everyone is using it. It is kind of an abstraction layer ontop of our Hibernate. It is simplifying stuff for us. It is an standardized API.

Now when it comes to Spring Data JPA, that is different from this jpa? Spring data jpa is basically a framework provided by your spring framework in order to do your database connections right. Spring data jpa is kind of a layer of abstraction on top of your jpa right. It's a layer of abstraction which will provide us a lot of interfaces okay. And we can directly make use of those interfaces inside our application. We don't even need to provide the implementation because the implementation is handled by jpa and hibernate internally.

So spring data jpa is an abstraction which uses jpa that meeds an implementation which is hibernate in our case which in turn uses jdbc which will do the database connection and manage everything for us. So this is how spring data jpa flow will look like. And spring data jpa basically makes our crud operations very easy because as we said it's a layer of abstraction on top of jpa. It provides interfaces like crud repository, jpa repository, and like paging sorting repository.

Now let's look into JPA architecture.

Let's start from entity which is an object which will be mapped to table inside your relational database right. Now how this entity will be saved inside your database? So what is the journey of this entity to this database? Now this entity will be managed by a EntityManager. What is this entity manager? It is an interface inside our application which is responsible for managing the entities. So whatever entities you create all of them will be managed by this guy over here. Think of it as a manager who manages multiple entities inside your application. So all the operations that you are going to do on this particular entity for example let's say save or presist that operation will be done by entity manager. This is kind of a responsibility of entity manager to perform operations on entity.

EntityManager em = entityManagerFactory.createEntityManager();
em.persist(book);

And who creates this entity manager? Basically entity manager factory is responsible for creating our entity manager. It'll generally be one factory per application which will be managed by persistance. In our application, the configuration will be managed by something called as persistence.xml. That will basically create entity manager factory which will be one factory and it can create multiple entity managers inside our application which will manage all the entities inside our application. This persistance.xml is something which we define in JPA. That is something which we do not need inside spring data jpa. But in order to understand spring data jpa, we need to understand jpa first and this is basically the architecture of jpa and what happens inside jpa. Because spring data jpa as we know is just an abstrastion on top of jpa, and internally it'll use all of jpa.

Next let's look into this Persistance Context. Now think of persistance context as a cache where these entities will be stored temporarily inside a persistence context. Consider a bag inside which we have this entities stored on a temporary basis and this guy entity manager is interacting with this persistence context to get those entities. It will be more clear when we see entity life cycle.

Now what entity manager will do is it'll call persist right. It'll say EntityManager.persist() and it'll try to save this entity. Now entity manager is kind of an interface. Entity manager cannot directly interact with database. What it will do is it'll have some kind of a provider. Internally JPA will use Hibernate as a provider. So what entity manager will do is it'll offload the task of interacting with database to Hibernate. Now hibernate will have its own query language. And depending on what entity manager is asking, hibernate will create the sql queries and hit on the database. And entity manager will also create the transactions which is also managed over here.

Let's look at the lifecycle of entity.

We have some states of the entity, that is Managed, Transient, Detached, Removed. So whenever we create new entity, the moment it is created it is in the Transient state. This is basically the state of our new entity. Whenever the entity is in transient state, then it is kind of a fresh entity. And it is not managed by our entity manager here. So when our entity manager will manage it, the moment we call persist() on the entity. When we call entityManager.persist(entity) then it'll be a managed entity. And managed by whom? As we have seen, the EntityManager manages it. Means this entity will be in the Managed state now. And how this state transition happened? By using persist() funciton on that entity by the entityManager.

Now whenever the entity is in Managed state, then it'll be associated with the persistence context. That means this entity will be added inside our persistence context. That is why this state is also called as Persistence state as well. Basically persistence context will store the managed entities and not all. Now when our entity is in managed state, if we make changes to that particular entity, then it'll be automatically synchronized with our database. And it'll actually be save dinside a database when we actually flush() it. That means when we do transaction commit. And in case we are finding something, that means we are finding an entity inside our database, then that particular entity will be created and it will be in the managed state.

After that we have Detached state right. What is detached? The entities which are detached. Those entities were once in persistence context but now they are no longer managed by our entity manager. So basically once we detach the entity using detach() or clse() or clear() then it'll not be managed by your persistence context and will be in the detached state. And if we want to move it back to the managed state, then we have something called as merge() operation which we can do in order to move it back to managed state and make them manageable by our entity manager.

Now the last state we have is Removed state. Let's say our entity is marked for deletion, but it is still inside our persistence context, and it is ready to be deleted. When we call this remove() operation then our entity will be transitioned from Managed to Removed state. When we commit the transaction, it'll be removed from our database. And that is basically the entire flow.

SPRING BOOT JPA IMPLEMENTATION

In order to convert a typical pojo class into an entity, we need to make the user of an annotation that is called as @Entity which comes from persistence. Once we add @Entity on top of our class, it'll be converted to entity. And it'll be treated as a table inside our database. It'll create a table with the name of class inside the database. Now every database needs a primary key. We make use of @Id annotation for that. Now whenever we create that class, we're going to manage that primary key on our own.

Suppose the database is for storing applicants for a job, why would they care about the id then? So system should handle the autogeneration of this particular id. So then is when @GeneratedValue comes into picture. Now it needs to be given a strategy. There are different types of strategies such as TABLE, SEQUENCE, IDENTITY, UUID, AUTO. Now each persistence provider has its own way of creating this primary key. For example, Hibernate will have its own way. If we choose AUTO then our persistence provider can pick up any one of these. UUID is basically a universally unique identifier. IDENTITY means it should use identity column in order to provide an id. SEQUENCE means it should use database sequence in order to generate the primary key. TABLE means our persistence provider must assign a primary key for that particular entity using a underlying database table. But let's select AUTO for now.

@Entity

public class Applicant{

@Id

@GeneratedValue(strategy = GenerationType.AUTO)

private Long id;

private String name;

private String email;

}

As we know that spring data jpa is an abstraction layer on top of jpa. It provides three types of repositoriesz; CrudRepository, JpaRepository, Paging&SortingRepository. Now because spring data jpa provides abstraction to interact with jpa. Similarly, we have to rely on abstraction by using interfaces that extends one of these repositories. Supose we extend the CrudRepository, then it'll take some parameters as well. First parameter, what would be the entity? Second parameter, what type of primary key of this particular applicant? Let's see the code.

@Repository
public interface ApplicantCrudRepository extends CrudRepository<Applicant, Long>{}

Once we do that we need to go to service, and create the object of that interface. What we can do here is use @Autowired on top and inject it on service.

Now we can save an Applicant instance on this ApplicantCrudRepository using save() method.

@Service

public class ApplicantService{

@Autowired

private ApplicantCrudRepository applicantRepo;

public Applicant saveApplicantCrud(Applicant applicant){

return applicantRepo.save(applicant);

}

}

Before running our spring application, we have set up some default configurations in application.properties.

spring.datasource.url = jdbc:h2:mem:appdb

spring.datasource.driverClassName = org.h2.Driver

spring.datasource.username = sa

spring.datasource.password = password

spring.h2.console.enabled = true

spring.jpa.hibernate.ddl-auto = update

spring.jpa.show-sql = true

So what we have to do now is just move to /h2-console after running application in local host. And we'll have something like this.

And this is how the h2 console looks. Now it has created Applicant table with all the columns that we had listed while creating our entity. Now who is creating it? If we check the logs, we could see that Hibernate is creating the table automatically. And it is doing sequence generation for primary key and stuff. In our case, the provider is hibernate.

Now, in order to add applicants, what we will do is use @PostMapping and send the response body in json with the same parameters as our entity class, and then we'll accept the response using @ResponseBody Applicant parameter inside our post function in controller. And then we'll pass it to service which will save it up usng applicantRepo.save(applicant). So this is the whole process. And now if we do select * from Applicant in our database after sending responses through postman, we'll be able to see the records successfully.

Now H2 database does not persist data. When we rerun our application, the data is basically vanished, because H2 is in memory database and it'll be reloaded each time you reload your application or restart your application. So if you want the data to persist, then use something like MySQL which'll persist your data inside your database.

If we look into the methods that CrudRepository provides us, then we have save(), saveAll(), findAll(), count(), delete(), deleteAll(), existsById(), findAllById(), findById(). So these functions are majorily for CRUD operations on our database.

However, there are two more types of repositories such as PagingAndSortingRepository, and JpaRepository.

But what's the difference between these repositories? Let's look into it. Basically CrudRepository provides very basic stuff related to crud operations. Basically this is very lightweight and suitable for your simple operations. Then we have PagingAndSortingRepository, as the name suggests, will give features related to paging and sorting, and what this repository does is extends over from our crud repository. So this has all the functions of CrudRepository plus it's own functions as well. After that, we have JpaRepository, so this comes from spring data jpa. Now this jpa repository extends from the PagingAndSortingRepository, that means it'll include functions form both CrudRepository and PagingAndSortingRepository along with few Jpa specific functions. For example, we have flush() methods. And it also supports something called as query methods and batch operations which is very important for us.

So what we need to do is create an interface and simply extend from paging and sorting repository giving the parameters of the entity and the type of primary key, and then inject its instance in service using autowired keyword and use its functions. Let's see the code.

@Repository

public interface ApplicantPagingAndSortingRepository extends PagingAndSortingRepository<Applicant, Long> {}

On each page how much data we want, that is something we have to define while hitting the post api , and as per what we pass as page and size in postman key-value pairs it'll show the entries accordingly. Let's see the code.

@Service

public class ApplicantService{

@Autowired

ApplicantPagingAndSortingRepository applicantPagingAndSortingRepository;

public Iterable<Applicant> getApplicantsWithPagination(int page, int size){

return applicantPagingAndSortingRepository.findAll(PageRequest.of(page,size));

}

}

@RestController
public class ApplicantController{
@Autowired
ApplicantService applicantService;
@GetMapping("/page")
public Iterable<Applicant> getApplicantsWithPagination(@RequestParam int page, @RequestParam int size){
return applicantService.getApplicantsWithPagination(page, size);
}
}

A very important point to highlight over here, the behaviour we have seen where the three repositories extends is not valid in the recent versions of spring data. Now there are some modifications and new introductions in the new version of spring data. What are those? Let's see.

What happens is when we use findAll() method, it returns something called as Iterable, but we don't want that right. We have to convert that iterable to a list and then return. This is an extra work right. Now, they have introduced new repositories like ListCrodRepository, and ListPagingAndSortingRepository.

Now, the newer verions looks something like this.

First, we have a marker interface that is Repository. Now we can see that CrudRepository and PagingAndSortingRepository both extends from the Repository. But a major thing to notice over here is that our paging and soritng repository is no longer extending through the crud repository that it used to do before. So the behaviour that we saw in the earlier diagram is no longer valid anymore. And they have introcued two new repositories of list. Now the jpa guy will extend both of these list repositories. And an interface can also extend from multiple repositories since paging&sorting and crud do not extend each other and are separate. The way to use both of them is like this.

@Repository
public interface ApplicantRepo extends ListPagingAndSortingRepository<Applicant, Long> , CrudRepository<Applicant, Long>{}

Now let's see the JpaRepository. It is an interface that internally extends from multiple interfaces we have extended above. And if we see within that JpaRepository, we may see methods such as flush(), saveAndFlush(), saveAllAndFlush(), deleteAllInBatch(), deleteAllByIdInBatch(), getReferenceById(), findAll() and many more.

The whole point of using Jpa is Query methods. These methods comes in handy in cases when we want to filter data not just based on id, but on various other parameters in a database. Suppose we want to find users by their name. What we are going to do is define a method in our ApplicantJpaRepository like this. And Jpa will be pretty clear what it needs to do if name is one of the field inside our applicant entity. We can also combine queries and it is quite simple. Let's see the code.

@Repository

public interface ApplicantJpaRepository extends JpaRepository<Applicant, Long>{
List<Applicant> findByName(String status);
List<Applicant> findByNameOrderByNameAsc(String status);
List<Applicant> findByNameAndEmail(String name, String email);
}

@RestController

public class ApplicantController{

@Autowired

ApplicantService applicantService;
@GetMapping("/getByName")
public List<Applicant> getApplicantByName(@RequestParam String name){
return applicantService.getApplicantByName(name);
}
}

@Service

public class ApplicantService{

@Autowired

private ApplicantJpaRepository applicantJpaRepository;

public List<Applicant> getApplicantByName(String name){

return applicantJpaRepository.findByName(name);

}

}

Suppose we want to find entires by something like partial names, then there cannot be query method that would match with findByPartialName(). So that's where @Query annotation comes into picture. We can actually write SQL queries inside the @Query annotation, and suppose if it needs a parameter then we'd use @Param in the method parameter for it. Let's see the code now.

public interface ApplicantJpaRepository extends JpaRepository<Applicant, Long>{

@Query("SELECT e FROM Applicant e WHERE e.name LIKE %:name% ")

List<Applicant> findApplicantsByPartialName(@Param("name") String name);

}

SPRING DATA JPA RELATIONSHIPS

Whenever multiple entities are coming into picture then how are they interrelated with each other and how that can be implemented by using spring data jpa? We are going to see the relationship between entities and the types of relations as well, such as one to one, one to many, many to one, and many to many.

Let's get started with relationships. So Applicant is basically one entity right now. As we have only one entity inside our application, we cannot really define the relationship. So when we say relationship, it is basically the way by using which two entities are associated with each other, and they way they are related to each other. That is basically the relationship between entities. So let's say there's another entity called Resume. Basically each Applicant will have Resume.

Suppose I'm the Applicant, then I can only upload one Resume right. I cannot upload 10 Resumes and ask them to select one for me. When we talk about Resume entity, then one Applicant can only have one Resume. That is how we can define the relation between applicant and resume. Let me write some entity relationship diagram. So there is something called as entity relationship diagram. And it looks something like this.

Basically we have a applicant table, and we also have a resume table. And both tables represents the respective entity. Now we can define how they are related to each other. Let's put an arrow from applicant to resume, and show the ER diagram relationship. So one resume can have just one applicant and one applicant can have just one resume. So it's kind of a one to one mapping.

Now we have to tell spring that Applicant is a foreign key in Resume entity. For that, we have to use the @JoinColumn annotation. It is basically a annotation to add the foreign key inside our entity. And we need to add some kind of a key name over here as well. And this key name will be saved inside our database, and we can add one more field, that is nullable, which means this column cannot be null inside our resume.

@Entity

public class Resume{

@Id

@GeneratedValue(strategy = GenerationType.AUTO)

private Long id;

privateString content;

@OneToOne

@JoinColumn(name = "applicantId", nullable = false)

private Applicant applicant;

}

Now we can also make use of the @OneToOne annotation. It means that one applicant is associated with one resume. This annotation will actually tell joa that this particular entity have one to one mapping with your other entity. And jpa will use the later annotation @JoinColumn to set up the relationship when it creates the table right.

What we can do is instead of a unidirectional mapping, we can do bidirectional mapping, that is while creaing the applicant entity, we can create an resume for it as well, that is bidirectional association within our entities right. In the Applicant entity we can add something like this.

@OneToOne(mappedBy = "applicant")

private Resume resume;

However, if we see the response from postman, we'd not get the resume field, and instead we'd get an internal server error. If we see the logs, we'd see TransientObjectException and it says save transient instance before flushing. Now if we see carefully, when we were trying to save the Applicant entity through service, the Resume entity is not saved inside a database. So Resume is not storesd and it says how it is going to store the Applicant. That is when something called as Cascading comes into picture. There are two ways to solve this. First we can do while saving Applicant, we can first save Resume and then save Applicant programatically right. But there is another way, just use cascading okay. So we just have to highlight the cascade type in @OneToOne mapping. That means first resume will get added and after that applicant will be added in database. And if go inside CascadeType, there are many types right. ALL, PERSIST, MERGE, REMOVE, REFRESH, DETACH.

@OneToOne(mappedBy = "applicant", cascade = CascadeType.ALL)
private Resume resume;

Now, if we run it, we'd see another exception from Hibernate saying PropertyValueException, not-null property references a null or transient value. Here, if we carefully observe, when we were doing mapping in Resume with Applicant earlier. We had given nullable = false in @JoinColumn parameter that applicant for a resume cannot be null. But when we were using CascadeType.ALL in @OneToOne mappnig, then it is first trying to insert Resume, and at that moment, Applicant is not inserted in the database, so Resume is not aware of what exactly is the value of our applicantId. Now they are referring to each other and giving exceptions.

What we have to do to solve this is actually manually get the resume response from the Applicant json in service and pass it to resume to set the applicant there first, then this null check inside resume will no t fail.

@Service

public class ApplicantService{

@Autowired

private ApplicantCrudRepository applicantCrudRepository;

public Applicant saveApplicantCrud(Applicant applicant){

Resume resume = applicant.getResume();

resume.setApplicant(applicant);

return applicantCrudRepository.save(applicant);

}

}

Now when we go into postman and see the response, we'd actually get an infinite loop. If we look carefully, resume has applicant, and applicant has again resume, and it is going so on and creating an infinite loop right. So, bidirectional by its very nature is kind of a circular dependency right. To prevent this behaviour, we can use @JsonIgnore annotation in Resume entity, which is basically to prevent resume to serialize this applicant in order to avoid the recursion that we are facing over here.

Finally, our bidirectional one to one mapping works.

Now let's go next level, basically one to many mapping. Let's say one applicant can have many applications. Let's see the ER diagram.

For applicant, we have one to many mapping, but for application, however, we have many to one mapping. One applicant can apply for many jobs but many applications can be associated with one job. It is very straightforward once we understand it.

@Entity
public class Applicant{
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
private String name;
private String email;
@OneToOne(mappedBy = "applicant", cascade = CascadeType.ALL)
private Resume resume;
@OneToOne(mappedBy = "applicant", cascade = CascadeType.ALL)
private List<Application> applications = new ArrayList();
}
@Entity
public class Application{
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
private String status;
private String position;
@ManyToOne
@JoinColumn(name = "applicantId", nullable = false)
@JsonIgnore
private Applicant applicant;
}
@Repository
public interface ApplicationRepository extends JpaRepository<Application, Long>{}
@Service
public class ApplicationService{
@Autowired
private ApplicationRepository applicationRepository;
public Application saveApplication(Application application){
return applicationRepository.save(application);
}
}
@RestController
@RequestMapping("/api")
public class ApplicationController{
@Autowired
private ApplicationService applicationService;
@PostMapping
public ResponseEntity<Application> createApplication(@RequestBody Application application){
return ResponseEntity.ok(applicationService.saveApplication(application));
}
}

Now let's see many to many mapping. For example, let's say there are many jobs, and many applicants can apply for that job. There is some kind of job opening, and many applicants can apply for that job right. On the other hand, there could be many jobs and applicant can apply for many jobs. When there is many to many mapping, it is advisable ot create a separate table where we can store the applicant id, and job id. And that table may look somthing like this. Which can have duplicates as well.

Now here we need to make use of @JoinTable. Why join table now? Because we need to create some kind of other table as well? This annotation creates a table by joinning some columns of those two tables which we are mapping. Let's see the code.

@ManyToMany

@JoinTable(

name = "applicants_jobs",

joinColumns = @JoinColumn(name = "applicantId"),

inverseJoinColumns = @JoinColumn(name = "jobId")

)

private List<Job> jobs = new ArrayList<>();

Now, the rest of the code and its implementation will be your Assignment. This one assignment will be your entire revision of Hibernate, JPA, ER Relations. And it just can't be done by just reading it. The more revisions you may do through this assignment, the more comfortable you'd be with handling databases in spring applications.

SPRING BOOT INTERCEPTORS

So what are interceptors? Let's say you have this client and client is making certian request to your application inside your spring application. THe request will first land inside your dispatcher servlet. Now what is this guy dispatcher servlet? Right. So the job of dispatcher servlet is basically to take the request from your client and assign it to the respective controller inside your application depending on the URL. For example, you have many controllers inside your application. Let's say this is your application with multiple controllers. Now each controller will have multiple apis right and each api will have its own path right so depending on the path, this guy will select the appropriate controller and transfer that request to that particular controller, that is basically the job of thsi dispatcher servlet. Let's say there are multiple requests coming to this particular controller.

Now, let's say there is a use case right. Let's say you have a client right and your client have a user id. Let's say there is a field user id that is stored inside your database right and this is basically your application. Let's say client knows this user_id in numeric format. So in UI everything is in numeric format. And in the database it was saved in the same format. But now let's say there is a requirement of converting that numeric format to uuid format right. And we have changed this inside our database and inside database we have the uuid. But we don't have it in numeric format. And our client will still have it in numeric format. Let's say we have kind of a table where we have numeric to uuid mapping. And we know the relationship between the numeric format from the client and the uuid in our database. Now suppose you have thousand tables, and you try to migrate a numeric id to uuid. Now we are not able to migrate this because user understand snumeric values only. And in this case, user will keep sending numeric values to your controller. And our database do not understands that numeric values, it only knows about uuid values. You just have kind of a table where you have mapping right and all the operation inside your application is working based on uuid. Now we are not actually changing the user ids, just the format will be changed right. Whenever the request will come, let's say get user by user id to your controller. What we have to do is get that particular uuid of that particular number. Let's say i'll do a database call and I'll get that uuid right, and using that uuid I'll perform the operation on the database. Now let's say you've a thousand controllers over here. What we need to do inside each of the controller api, we'll need to go ahead and convert our incoming request numeric format user id to uuid before doing anu processing. Suppose if you have 5,000 apis inside your application, you'll need to change 5,000 apis to do that which is not feasible.

What if there is a way to change this numeric format to uuid even before your request is reaching your controller? Now we can just pass the uuid in controller and then we don't have to change the apis right. Now this middleman we're talking about is the Interceptor.

So Interceptor is basically something which will allow you to modify your incomimg requests even before the request is reaching to your controller. So it sits between your dispatcher servlet and your controllers. So whatever requests are coming from your dispatcher servlet it'll modify it. For example, one of the use case would be converting your user id to your uuid right. So that is basically the example.

Now suppose there are multiple uses of this, we can also do loggign over here, we can also do authentication as well, right. Let's say before your requset goes to controller you want to log it, you can log it here before your response goes back to dispatcher servlet also. So basically Interceptor allows you to intercept any http request even before your call reaches to controller. You can intercept and modify your request right that is something which you can do as well. When you have let's say service right, so before your call reaches to service from your controller, you can add some kind of aspect in between and you can intercept the request right that was something which was aspect oriented programming, but here we're talking about the middleware between our dispatcher servlet and controller when sedning an http request.

Now, let's see what are handler interceptors? So hander interceptors is basically an interface which is provded by spring in order to make use of interceptors inside your application. We can extend it like this.

public class LoggingInterceptor implements HandlerInterceptor{}

Now if we go inside this inceptor, we could see preHandle(), postHandle(), and afterCompletion(). We can do over here in the class that has implemented that interface is implement all those methods. We'd override these methods. But what exactly are these methods?

Let's say we have dispatcher servlet, we have our controllers right. In this case, our controllers are HomeController and ApplicantController. Let's say our request is coming to dispatcher servlet. So first when your request is received by this guy dispatcher servlet. What this guy will do is it'll check if we have any Interceptor. If we have any interceptor, we have Handler Interceptor. It'll find our interceptor. What it'll do is it'll transfer the request to preHandle. PreHandle means before our request is reaching to your controller, this function will be executed. How to configure the controller? That we'll see. Now, in the postHandle we cna also modify the response sent back so that it is better understandable by your client right. Lastly, we have afterCompletion. Once the response has been sent. This guy will clean up any resources if you have. For example, garbage collection and stuff like that over here.

Apart from that, we need a configuration. For example, we have a configuration here okay. And we need to implement WebMvcConfigurer on that class. Now what is it? If we go inside, we could many functions in this interface such as addInterceptors(), addFormatters(), configurePathMatch(), configureAsyncSupport() and many more. So basiaclly it helps us to register our interceptor. Because we need to register our interceptor. Because we see, we can use the addInterceptor() to register our interceptor so that it'll be invoked whenever our request is reaching to your application. This add interceptor method will help us right. So we override it.

@Configuration

public class WebConfig implements WebMvcConfigurer{

@Override

public void addInterceptors(InterceptorRegistry registry){

registry.addInterceptor(new LoggingInterceptor());

}

}

Now we can add url patterns, add path patterns, which we want to include inside this particular interceptor right. So what we'll do is add path patterns right. So whatever the path is for our @RestController, we can copy that and paste it over here. And we can do like * * after that, which is basically regular expression right. So whatever is coming after star and star, it will match everything. That means all the paths starting with our @RestController path will be intercepted. And we cna exclude few patterns as well. So let's say I want to exclude few patterns right. For example, let's say we have some authentication, so what'll do is we can add a specific path that we want to exclude right.

public void addInterceptors(InterceptorRegistry registry){

registry.addInterceptor(new LoggingInterceptor())

.addPathPatterns("/api/**")

.excludePathPatterns("/api/auth/**");

}

Here in spring, we also use filters to modify the request, and we also use interceptors to modify the request. So what is the difference between the two? So everything in inceptors is basically inside your spring application. But however, filters is not a part of your spring application, rather it'll be a part of your servlet api. It'll be outside your spring mvc application right. It is a part of servlet api and it'll modify the request even before reaching to your spring application. And this guy will not have access to your spring application. On the other hand, handler interceptor is basically part of our spring application, it is a component inside our spring application as we have seen. This guy dispatcher servlet can access spring beans inside your spring application directly. It can inject it as well. That is something which servlet api cannot do. Filters will operate on entire life cycle of your http request. But on the other hand, interceptors work specially within spring mvc flow. So inside spring application, the request is inside your spring mvc application. It can modify, it can access your bean. It can do whatever you want, like logging, authentication, request modification, or even it can inject the beans and play with your database.

SPRING BOOT FILTERS

Now when we say filters. Conside filters as kind of a gatekeeper of your application right and for each request they'll validate the request. For example, write or perform some kind of operation on that particular request. So basically the job of filter. For example, you want to fly somewhere and you go to the airport. Now there will be multiple checks that will be happening, and multiple security gates will be there. So we can relate to those gates as your filters.

Now, let's say we have our spring application and we're hitting some request with our browser or our postman to our service right. Now our service will be deployed somewhere on the server right. If we're talking about spring boot, we'll get multiple embedded servers. For example, tomcat, or be it jetty, or be it anything. So request will first go to your server right. Now, java has a mechanism to handle all your request and responses right. What is that mechanism? That is basically the servlet api. That is basically the legacy mechanism inside java to handle to your requests and responses. So your request will be handled by this guy, servlet api. Now when it comes to our spring application, there is something called as dispatcher servlet, which is basically an abstraction of your servlet api, which is provided by your spring application. So internally that guy is using servlet api itself. But everything is abstract over there for us and we don't have visibility of anything because it's a framework, and it's designed to handle and automate stuff. Now remember that in between the dispatcher servlet, we have the interceptors, and then the request will be sent to the controllers to be handled.

So basically filters is a part of your servlet api, and it is basically a legacy interface which is a part of your servlet api. So even before the request has gone to the spring core, the filters will handle the request. And mostly filters will perform operations such as performing login or performing authentication, which we are going to look into inside spring security. The filter will have authentication and stuff.

Now let's look inside the servlet api and what kind of filters we do have. When we send the request, it'll first go to this particular logging filter, then your request will be transferred to this particular dispatcher servlet. Whatever operation we're going to perform inside this filter will be executed first right. Be it your logging, be it your authentication, authorization and much more.

Now if we have to define filters, it is a component inside your java which processes http requests and responses for you even before the request reaches the dispatcher servlet. So that is basically filter right. So we have understood what exactly is filter. Then let's see what is filter chain? It's just multiple filters right. We can have authentication filter. But what happens particularly in filter chain? That after reaching the first filter, that is logging filter, your request will not go to the dispatcher servlet, and rather than your request will now go to the next filter. And that filter will filter out stuff for you. And after that, whatever is the last filter inside your filter chain, that particular filter will transfer the requets to your dispatcher servlet inside your spring boot application. This is basically the filter chain. So when I say filter chain, then it is nothing but the chain of your filters which are running in sequential manner.

Let's see implementation of a custom filter. Like we have create a separate package named filters. And we need to implement this class with filters.

public class LoggingFilter implements Filter{}

We can see over here that Filter interface comes from the jakarta servlet. If we go inside this filter interface, we could see init(), doFilter(), and destroy() methods. What we can do is override the doFiler() method which has servletRequest, servletResponse, filterChain in its parameters, and we just have to use them. Now we can filter our requests as we want it to be. If we use filterChain.doFilter(servletRequest, servletResponse) inside the doFilter() method, it's kind of like calling itself either in the next filer, or it'll directly call the dispatcher servlet if it seems to be the last filter out there.

@Component
public class LoggingFilter implements Filter{
@Override
public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain){
HttpServletRequest httpServletRequest = (HttpServletRequest) servletRequest;
filterChain.doFilter(servletRequest, servletResponse);
}
}

SPRING BOOT CACHING

So what exactly is caching? So let's say we have a library right. And there is this librarian. And people are coming to get some books. For each person's request, what this librarian will do is he'll go to this library and he'll fetch some kind of book which this particular person is asking right. He'll find the books and he'll give it to that particular person right. Now for each person, this poor guy is going to this bookshelf finding the book and returning it to this particular person right. So that they can go ahead and read the book right. So this poor guy is basically tired but this guy is smart. So what he is doing now is finding a trend that there are many people who wants harry potter books. Because harry potter book is very popular right. What this guy will do is he'll go over here to bookshelf and he'll pick the bunch of harry potter books and he'll keep it on the desk right. So that next person who wants the harry potter book. This librarian don't have to go to this bookshelf again and again rather he can just pick the book from his desk and give it to that particular person. In this approach, he'll just save his time to go to this particular bookself. This guy is making his life easy.

Now consider this library is our application, and this particular shelf is basically our database right. This particular librarian is going to this database and fetching the data. Our application is sending the request to the database and it keeps on doing that on each request rate. But this stack is basically the cache that comes into picture. So what we are doing over here is the frequently accessed data we are storing it inside a cache, so that we don't have to send the request to this particular database right.

Now our application will get the request to get the data from database right. What we'll do is we'll call the database, we'll make a call to database and finish the data and return it to the user right. Now what we can do over here, we can introduce a cache in between your application and your database. So it'll be here so it'll be a layer between your application and your database right and the frequently accessed data. We'll store over here in the cache, so that we can directly return it to the user without visiting your database right. So database is just one example.

We can also think of a microservice based architecture. Let's say there is some other service right. Let's say there is another application and our application have to make a request to this particular application in order to get the data again. Now the frequently accessed data for which the response is not going to change for a long time. We can store that data over here inside cache and now instead of calling this particular app, our application directly will call our cache and get the data and this'll save a lot of time. So that's basically the use of caching.

Why use Caching? Well it'll help us reduce latency, that means faster access to data compared to fetching from a database or an external service. It'll decrease our load, that means it reduces the number of calls to the backend systems or database. And it improves scalability, that means it helps applications handle higher traffic loads efficiently. So that's why we use caching to reduce latency, decrease load, and increase the scalability of our application.

Note that this is a very important concept for microservices architecture because we eventually have to cache a lot of things.

Now let's see how we can implement cache in spring boot. First, in order to make use of spring boot caching, we you need to do is you need to enable caching right. How can we do that? So we have to use @EnableCaching annotations. It'll enable us to make the use of cahcing inside sprin gboot. Now this annotation needs to be added on top of your configuration class. So we have to use @EnableCaching annotation on top of @SpringBootApplication annotation. Basically this caching annotation has to be placed with a @Configuration annotation, and spring boot application already has that configuration annotation.

What happpens is that we handle caching in a service class, when the database returns the same data multiple times, it'll catch the input being similar, and it'll use the cached data. The way it'll use it instead of calling database is by using @Cachable above the method in service class that may have a database call to repository.

@Configuration

@EnableCaching

public class AppConfig{}

@Service

public class MainService{

@Autowired

public class Repo repo;

@Cachable

public String getFromDB(String id){

return repo.dbScan(id);

}

}

Further what we can do is ues CacheManager from spring framework to manage the entire lifecycle of caching.

@Service

public class CacheInspectionService{

@Autowired

private CacheManager cacheManager;

public void printCacheContents(String cacheName){

Cache cache = cacheManager.getCache(cacheName);

if(cache != null){

System.out.println("Cache Contents:");

System.out.println(Objects.requireNonNull(cache.getNaiveCache()).toString());

} else {

System.out.println("No such cache: " + cacheName);

}

}

}

@RestController

@RequestMapping("/api")

public class MainController{

@Autowired

MainService mainService;

@Autowired

CacheInspectionService cacheInspectionService;

@GetMapping

public String getById(@RequestParam String id){

String getResource = mainService.getFromDB(id);

return getResource;

}

}

Types of Caching

First we have InMemoryCaching, which is basically the cache which is created inside a memory of your application right so it is part of your application. Like we never mentioned which cache we want to use. So that's the reason internally spring is making use of a concurrentHashMap and storing all the cache data in memory. So this will be basically stored inside the heap memory within concurrent hash map.

But in memory cache comes with its own problems. Let's say you have an application and you have deployed your application inside production right. So you have this application and you have a node server, and now you are doing horizontal scaling right. So our load is slowly increasing as we are creating more nodes. So we scaled instances of our application. Now when you have in memory cache. Each of the instance will have its own cache. Now each node will have its own in memory cache, and it'll cache things over here. Let's say you have an element cached inside all three of these nodes right. All three nodes and now one of the node is updating the data inside database. Now the cache of that guy will be updated as per the latest database value but the cache of other nodes will still have the older data right. That is basically the problem that happens when it comes to in memory caching. It is fine if you have have one node like a monolith architecture. But when it comes to multiple nodes and an microservice based architecture. it'll start creating a problem instead of being an help because each node will have its own cache and it will lead to data inconsistencies. That's were distributed caching comes into picture.

When we say distributed caching, it is something called as, it is like you do not have any in memory cache, and you just have a single cache which is out of your application. So now this big guy is not inside your application, rather it's outside your application, and now all the nodes that have been created will be connected to this particular caching right. Now they are referring to same cache right. The famous example of distributed caching is redis. Redis is basically a distributed caching which is widely used. Now how can we connect redis caching to spring boot? We'll see soon.

Now what happens is sometimes cache may have stale and old data, and the data in database has been update using Post request. Now we need some way to tell the cache that the data it was referring to has been updated. Because if we do not update the cache after initial store, there may arise a case, where the data has been changed by other end point, but still the cache may return the old data on hitting the same query parameters. Because cache validates on the basis of input, and checks whether the input earlier was same or not, and it gives the response accordingly. It has no concern with database unless specified that we are going to do. So we use @CachePut in order to update cache.

But whenever we try to update and store it up in the cache, it'll not update onto the same mapping key, rather it'll store that value as a separate new cache data, and still it'll return the old cache data. Why this happens? Because internally spring uses ConcurrentHashMap. To fix this new key everytime even for same values. What we can do is mention specifically in @Cachable and @CachePut the behaviour of key. We can also mention cache name like this.

@Cacheable(value = "weather", key = "#city")

@CachePut(value = "weather", key = "#city")

Now let's go into @CacheEvict annotation. Right so again it is pretty similar to cache put but it's other scenario right. For example, we have used the @DeleteMapping annotation, to delete a record from database. Now even though the data in database does not exist because we deleted it. It'll respond to the apis requests that are handled by cache, and has not been updated. So what we is put the annotation on top of the function that is handling deletion within database like this.

@CacheEvict(value = "weather", key = "#city")

SPRING BOOT AND REDIS

So basically we're going to see what exactly is redis? and how do we connect our spring boot application with redis.

Let's read from the official docs. Redis is basically an in-memory data storage as a cache, vector database, document database. Now when they are saying redis is an in-memory data storage, that means redis can store data on ram making it much faster instead of storing data on disk. And this in memory storage is not similar to what we have seen eariler as the types of cache. Redis is in fact a distributed cache which we can run on an separate server apart from our application server, so that all nodes can connect to this particular one cache server when we are doing horizontal scaling.

Now we have to give configuration to spring that okay you have to use redis instead of its own concurrent hash map for cache. But in order to connect to redis first, we have to run redis inside our application. So what we can do is go to terminal over here. And we can just run it from docker container okay.

docker run -d --name redis-cache -p 6379:6379 redis

docker run will run the container okay. That hyphenD is basically a flag which means detach mode means things will run in the background. So the image will run in the background. Then we have hyphenName which tells us what is going to be the name of the container that you want to give so we have given here redis-cache. Then we have hyphenP which means that the port of your container so we're running the container at port number 6379 which is the official port of redis server. After that, we are saying redis right, basically it is from where where I am trying to pull the image, basically it will pull the image from dockerhub and run for us right. However, in order to run this command, we need the docker engine, so make sure to have it in your laptop.

Now when redis runs, we can check it by performing a command on the redis cli like this.

redis-cli ping

And we need the redis command line interface for this. Make sure to have this in your laptop.

Now we need to tell spring boot to make use of redis. So we need some configuration like this.

spring.cache.type = redis

spring.data.redis.host = localhost

spring.data.redis.port = 6379

spring.cache.cache-names = weather

Now it's not going to run straight away like magic just with configuration. It'll cry and say that a component required a bean named 'cacheManager' that could not be found. Basically we have to add a dependency using maven file.

<dependency>

<groupId>org.springframework.boot</groupId>

‹artifactId>spring-boot-starter-data-redis/artifactId>

</dependency>

Now we can chcek the behaviour of this cache. First we'll post a request into database where @Cachable and all those annotations are used. And we know that after the post, the same value will be stored in redis as well, which will be cached the next time we use it. But we actually have to provide the name of the cache as well as the key of the cache. Suppose the key of that query parameter city is Manali. Let's check it in redis cli.

redis-cli get weather::Manali

First, it'll show null because the cache data has not been asked so it has not exposed it. Once we hit the get request with the same key Manali and then run this. It'll show the weather information we had posted in database earlier. And now no matter how many times we send the get request again and again, it'll always throw it from its cache.

We can see the ip address of redis using redis-cli command, and we have also see the number of keys using keys * command. And there may be a lot more commands that you can explore from your end.

SPRING BOOT SCHEDULING

First we'll understand scheduling and why do we need it? Then we'll enable scheduling in spring boot. Inside our spring boot, we'll see basic scheduling, we'll see fixedRate, fixedDelay, and initial delay. After that we'll jump into cron expressions. And finally, dynamic scheduling.

Scheduling in spring boot allows you to automate tasks at specific intervals or times. It helps in running background jobs without manual intervention. For example, consider a scenario, that you want to process certain orders that users are placing on your e-commerce platform. Let's say, you want to process them every 5 minute. How you're going to do it. There could be one person who is hitting your api every 5 minute. Well, that is a manual approach and may not be the right approach for this use case since we need to automate that somehow. That is when scheduling comes into picture. It'll automatically process pending orders every 5 minute right. That is something this implementation we're going to look into.

Another example could be sending email notifications right. We want to send promotional emails daily at midnight. Now, how you can send emails to thousand people at might rate you cannot keep a resource for that. You cannot have a manual approach right. In that case, again the schedulign comes into picture. So you can again do that you can also do data cleanup after certain amount of time like every 2 am. Another example could be you want to log system status at periodic interval like system health check ups. So these are basically the simple uses cases of scheduling.

So you may have understood why we need scheduling? Because without scheduling, repetitive tasks must be triggered manually. And there are so many restrictions which may not let us do it. So this is not really a feasible approach to do it manuallly. Now, we can make use of that to perform automated tasks at hand.

Now, how do we enable scheduling in spring boot? What you need to do is go to main class where @SpringBootApplication annotation is there, and below it, add the annotation @EnableScheduling. Now this will do all the configurations related to scheduling inside our application for us.

Let's add schedulers now. What we are going to do is add a package scheduler, and then a @Service named SchedulerClass. Now, I can add a method to write which is going to be called through our scheduler. Scheduler is going to call. In order to schedule this particular method, this particular task, we can make use of @Scheduled annotation. Now this annotation takes a lot of arguments. If we go inside, we could see cron(), zone(), fixedRate(), fixedRateString(), fixedDelay(), fixedDelayString(), initialDelay(), initialDelayString() and more. Let's make use of few of them.

@Service

public class SchedulerClass{

@Scheduled(fixedRate = 5000)

public void getGreetings(){

System.out.println("Hello Guys! I'm still alive.")

}

}

Now let's say the scenario where we have lots of orders to process and this function over here is running for 10 seconds. But within the execution of this particular function, another invocation will be started at 5 seconds, because this function will not wait for its own previous invocation to be completed. This function will trigger another invocation of itself before the previous invocation has been completed which may create a problem and may overlap your function execution call. That is basically the problem with fixed rate. So we don't want to do that. So if you don't want to overlap your method executions on top of each other than you can make use of fixed delay.

What is fixed delay? So when the previous invocation ends, then the timer starts and from that 5 seconds after, the new execution will begin. Here, regardless of the execution time the function invocation takes, they'll never overlap each other. Because the delay between two invocations of a method is fixed here. Now let's say you wanted to wait a longer initially before running the fixed delay interval time. For that purpose we can use initialDelay within the @Scheduled parameter.

Now by using cron expressiong, you can have more precise scheduling. You have the ability to schedule with a fixed interval of time using fixedRate, fixedDelay, initialDelay but you cannot make interval changes precisely on certain date, on certain time of the day right. So that is something which we can do by using crom expressions. For using cron, we have to understand the syntax precisely, where every star signifies something deep and meaningful.

@Scheduled(cron = "* * * * * *")

Now, let's say we deploy an e-commerce application inside production, and this is your production environment. And like you're getting orders in your application and according to some particular frequency, you're processing these orders through your scheduler. Now let's say every 5 minute, your orders are being processed. So there is a chunk of orders and this guy is processing your orders right. But let's say on certain days, there is a sale, and there is a festival coming up. Now we have lots of offers inside our e-commerce appliaction. Now, in that sale, your prices are reduced and you'll see a massive increase in orders. A lot of orders at that time. So we were expecting few orders every 5 minute. But now we're getting hell lot of orders. And we want to reduce this processing time as well. Now, I want to bring it to. I don't want to wait for 5 minutes rather I want to process orders every 1 minute. What do you think can we do now? We have scheduled this fixed delay to 5 minutes, now I want to reschedule that and make it to 1 minute, but our application is already deployed in production. Now how I'm going to change it? I don't want to redeploy my appliaction in production again and again. It's not a feasible approach. I cannot just change something small and deploy again. That's where dynamic scheduling comes into picture. A dynamic mechanism so that we can change the value of particular scheduler dynamically.

What we'll do is store the cron expression inside a particular database right and our particular application gets that data from this particular database. So now we are detaching that cron expression and saving it up inside database. And whenever I want to change this particular cron expression. I'll just have a api over here to update the value inside database and force my scheduler to use that particular new value. So this scenario is basically our dynamic scheduling.

Now for implementing this, we use ThreadPoolTaskScheduler. Now we are not going to use @Scheduled annotation. Rather we are going to call this particular function dynamically by using our ThreadPoolTaskScheduler. And what is it? It is basically a class provided by spring and managed by spring which will help us to dynamically update the value of your cron expression. So this is basically multi-threaded task scheduler. By using this, we can run multiple task in parallel as well right. Like if we had used @Scheduled then it'd run in single thread but by using ThreadPoolTaskScheduler, we can run multiple tasks in parallel as well. In this case, we're going to use this guy to update the values of cron expressions dynamically.

We can have a controller class which will have an api end-point through which we can communicate and send the new cron expression. Implementating dynamic scheduler is your assignment as the code and explaination can be longer, and may better understood with hands-on experience. This is another assignment apart from the assignment given in mapping topic of spring boot transactions.

SPRING BOOT LOGGING

Let's say we have this particular application over here, which is an e-commerce application, and let's say we want to deploy it now. So we have deployed it in dev/QA/Stage environments, and we have done out testing and everything in these environments. Now let's say we're going to deploy it now on production. So once we deploy our application on production. Let's say there is certain functionality that starts failing, and here itself is not working. But that same functionality is working on dev/QA/Stage environment. Basically it works on my machine, but what exactly is happening in production, that how you are going to find it out? So that is when logging comes into picture and that is the reason we need logs for everything.

We need those logs in order to do investigation of things going wrong in your production environment once you deploy your application. Logging is something which will guide you to debug something in your production environemt when something is going wrong. So now if you have appropriate logging mechanism, then in production for the functionality which is failing you can go ahead and check what exactly is happening. So the main purpose of logging is to have better visibility of your issues and to be able to find out issues inside your production environment.

Spring documentation says that Logback is used for logging as default. Spring itself at the starting of application uses logs. And the format has came from Logback. Now there are various logging levels and each one has different meaning right. First let's understand the format of Logback message that we see at the start of spring application. First we get the date, time, and utc. Then INFO is basically nice log right. It is just providing us an information of what is happening inside your application and nice and friendly log right. So after that we have ProcessID which is basically that ID on which your application is running on and from this processID you are getting this particular log. After that we have information about the package where it came from. Then we have this particular message that you are seeing that is basically the body of your log. So that's how our typical log format looks like.

Now these logs are supposed to be configured somewhere in spring boot right. Basically these are coming from the logback. Usually we use starting dependency inside our spring boot application so that guy will bring up log back for us in order to do logging. So these logs are basically comign from there right and log4j.

We can see clearly from the above table that we have different levels that we can use for logging. So whenever we get some errors and critical issues, it's generally of high priority right. And when there's just a warning for something, like high usage or latency or storage almost full, then that's medium issue, means you don't have any issue now but you may have issue in future right. And normal is just general logging of general purpose, like Info, debug, trace. So these are just identifiers or tags.

We use Slf4j for logging in spring boot. Now what is slf4j? Basically it is used for the implementation of your log back right. So log back is kind of abstraction right and slf4j is basically the implementation of that so the full form of this thing goes like, " simple logging facade for java ".

private static final Logger logger = LoggerFactory.getLogger(ClassName.class);

Our logger instance is global and singleton. That is stored internally. We have its referrence in our Logger static type, and we kept it private final to limit of scope to that class where we are going to use it. We can also make it static so that logger reference is not bound to that object only.

Now what we can do is use logger.info("That's cool !"); And we have methods like info(), error(), warn(), debug(), trace() and we can use accordingly.

Now the other way that spring provides us is by using annotation @Slf4j. So this particular annotation is coming externally from lombok right. So lombok is kind of a dependency that needs to be added if you want to use this annotation. So we add this annotation, then we do not need to get the logger reference and use LoggerFactory.getLogger(). Now " log " keyword is something which is provided by @Slf4j as a default reference to the heap memory for logger instnace, which can be used as log.info(), log.error() as such.

SPRING BATCH

Let's say there is this bank and the bank is reaching out to you saying that I want a software right. So as a engineer, we'll createa a software for bank and what bank wants is bank wants a bank statement generator which will generate detail account statements for the users of bank right. Now bank have millions of users. Bank will provide the daily data of the customer transactions each day right. Let's say end of the data bank closes and they will provide the data to your software right. Now you have to take that data, load it into your system and then process it and then provide the reports right. Now it is kind of a daily job and daily millions of transaction will happen right, So the job that this particular bank want us to do is. Let's say they want to pull us the transaction history right. Let's say they want to calculate the fees on various transactions. After that they want to format the specific sttements. And send it via email or by any means possible online. So that is basically the requirement of the bank.

So the main point over here is our software will need to pull the data from the bank on daily basis, and the data is huge, like literally very huge, with millions of records. Let's say that is the case we're handling on daily basis. Now when our application is pulling that data, how much time it'll take to process that data and insert that data back inside your database. Let's say can you imagine how big operation that is.

Let's suppose they gave you a csv file, and at the end of the day, we just want to do a processing and format it in a nice format and calculate various aspects like transaction history and calculate fees over here, that is basically the task they want us to do right now. What exactly we need to do inside our application . We need to take that data, we need to process all rows one by one, right. And we need to insert it inside our database so that we have a historical data as well with us right. If there are millions of records, how muhc time it will take and how much resources it will take to insert all those data inside your database right. And how much time it will take to process that particular data right. So it is kind of tedious operation. Now if it was one time then it was fine right. But we need to do it daily. Because bank will be open daily right, we need to do this job daily so that is the reason we need to think into the aspect of resource utilization as well. And doing that one by one will slow down the operation of the bank as well right. THey won't really get the outout of our application within the given time. That is again a problem right. They will look for alternate solutions and they will go away from your application. SO what is the solution right. The solution on this kind of problem is spring batch.

So what are the benefits of spring batch? It can read transactions for a few hundred customers at a time and process them in chunks in a parallel fashion. So it's kind of a bulk insertion operation we're doing here. We can also schedule that operation. Like suppose bank wants you to do it every evening, so we can automate and schedule it for that. Spring batch can also retry automatically if there arises some failure at some point. And hence it has restartability, which means if it has failed while it was in the process, next time the service goes live, it'll continue from there, avoiding any duplication in data. And finally, it provides us to do the monitoring of the job it has done.

Spring batch is nothing but a lightweight comprehensive batch framewoork designed to enable the development of robust batch applications, which means you have a lot of data and you want to save it in batch or process it inside a batch right. Also that are vital for daily operations of enterprise systems, that means processing large chunk of data on daily basis right. If you want to do that, go with spring batch.

Now let's look into the architecture of the spring batch. So we have various components over here. Let's go through each one of them. Job launcher means it iwll star ta job right. It's an interface that is provided by spring batch framework which will help you to launch or trigger a job right. Then we have a job component. Now what exactly is a job? The job is basically a sequence of task that you want to execute for certain purpose right. For example, once you get the data from the bank, you want to pull the transaction history for that particular data plus you want to calculate fees plus you want to format the statements plus you want ot deliver it via email. So all these sequence of steps is kind of a job for us right. So that's how we define a job. So there may be multiple jobs that you can have inside your application right. There can be many jobs which you can run right.

Now if we go into the documentation, it says a job will have a job instance, so there may be multiple instances of a job, you can run it in separate instances right. And then each job instance will have job execution. So when a particular instance has run once, that is job execution right. That is basically the hierarchy that we have for job. So job will have job instance then job execution right. Also, it says that a job is simply a container for step instances. Now a job can have multiple steps, as we have understood from the bank job example. So step is again a component inside a job right, which may be multiple steps and each step will have a different purpose and they will run step by step in a sequence right. Step is a domain object that means a name given to an independent sequential phase of a job. That means it is basically kind of a task inside your process, and a job is composed of one or more steps right. And each step will have its own step execution right. Because that will be executed inside your job right. So step execution represents a single attempt to execute a step so those are basically the entities that we are defining over here. So we have a job launcher which will start the job, and this job will be having multiple steps.

For example, these steps that as we have seen and each step can do these three things right. What are these three things? First we have IteamReader. It means it will read the data set right. A data set that is provided by bank in our example. As per documentation, ItemReader is again an interface that is provided by a batch framework so it'll just fetch the data from different type of inputs. For example. we have flat files. For example, XML or data source, it can be anything right. After that we have ItemProcessor, where we can perform various kind of operations right. We can perform after that we have ItemWriter which is again a similar functionality to an ItemReader interface but with inverse operations. So it's basically used for write operations.

Now the final component inside the architecture is job repository. What is job repository? So it is kind of a repository or a database where we will store the detaisl about these jobs right. If I go back over here, so job repository is persistence mechanism for all the stereotypes mentioned earlier. That means job launher, your job, and steps, all of them will be stored inside your job repository. For example, when the job was first launched, also details about your each step execution, your job execution, your job instance id, step execution ids, all data is stored over here within the job repository. And you don't have to handle it explicitly. The batch framework will take care of everything on its own right. So we don't really need to do anything explicit in order to store the details about these jobs and the execution of that particular job or the execution of that particular step right, the job repository will handle everything for us. It'll explicitly create tables for us inside the database, and it'll start storing all the details about the job and step executions once we trigger or launch our job. That is basically the use of job repository. And that is basically the overall architecture of your spring batch.

So for implementation part, we can import spring web, H2 database, spring data jpa, spring batch and we are good to go. Then we are going to assume that okay we have a csv file which has large amount of user data stored within it and we have stored that csv file in the resources folder of our spring application. Then we're going to assume that okay we have an entity in spring that is mapped to the columns of that csv file and a repository to store it to database.

Now first we have a job launcher which is going to launch the job right.

@RestController
public class JobController{
@Autowired
private JobLauncher jobLauncher;
@Autowired
private Job job;

@PostMapping("/importData")
public String jobLauncher(){
final JobParameters jobParameters = new JobParametersBuilder()
.addLong("startAt", System.currentTimeMillis()).toJobParameters();
try{
final JobExecution jobExecution = jobLauncher.run(job, jobParameters);
return jobExecution.getStatus().toString();
} catch(Exception e){}
}

}

So we have some parameters that we are going to give to the job, and then we have job launcher which is going to trigger our job. In this case, this is how we launch the job particularly from the api endpoint. Now basically whenever we start our application, waht spring boot will do is you are using spring batch and you have a job launcher inside your application, then it'll automatically start that job at startup, since we do not need that because we have a api endpoint, we have to manually configure it in application.properties and set it to false as such, spring.batch.job.enabled = false.

If we go deep into the documenatatios, we can see that earlier @EnableBatchProcessing was needed in configurations to use spring batch, but now it is discouraged and no longer needed, which is basically the spring batch migration form 3.0 to 5.0.

@Configuration
public class SpringConfigurations{
@Bean
public Job job(JobRepository, jobRepository, Step step){
return new JobBuilder("importPersons", jobRepository).start(step).build;
}
}

Basically we have Job and Step as beans in configurations, and then we're using a builder design pattern on it. Now because a job interacts with the job repository, so we needed that argument, and this particular job will return a new job right. How are we going to create a job? Using the class called JobBuilder which will create it for us. Then we'll just give the job name, and the particular job repository. And then we'll start the first step of that job. Like wise we have to define step and handle it as well. Further implementation, you can do yourself as an assignment which will help you revise everything about spring batch well.

SPRING BOOT UNIT TESTING

So what is unit testing? Unit testing is a way to test the smallest part of your code. You have a big spring boot application but you can segregate your application in small chunks and the smallest unit of your application, you can test inside unit test right. For example, it may be a single method or a single class inside your application which is doing certain task, that particular task is tested in unit test.

Let's say this is your application, and inside your application, you'll have package of controllers, you have different controllers over there. Then you have service package and inside that you'll ample amount of services. After that you have repository layer. Inside, we have multiple repositories and let's say each controller have multiple api functions right. So we'll have a rest api if you have rest controllers right. You may have a get api. You may have a post api. After that, you may have various services, in which you may have different functions. For example, get() and add() functions.

So unit testing is testing the smallest chunk of your application. So here the smallest chunk of my application are these. For example, this add() method is a smallest chunk of my application. So my unit test will revolve around the functionality that is supposed to be provided by this particular function. So I'll add a test case for this particular function. Now how do we add? Like similar to the package structure. We have test packages. And we'll see further. Like for a particular package ServiceTest, we'll have our test cases for addTest() which is the smallest test unit that is testing the functionality that is supposed to be provided by the add() method in the Services package. So a particular unit test actually tests a particular unit and doesn't care about anything else. It does not care about other controllers and repos. And it is just focusing on the functionality that is provided by this particular get method. So for each of the method, we'll have unit tests written inside our application. And how much of your code is convered in unit test is called as your code coverage. So you might have heard about tools like sonar right. What they'll do is analyze the code coverage inside your unit test. And it'll just give you a number that okay 80% of your code is covered inside unit tests. So that is when sonar analysis and everything comes into picture. There are ample amount of tools available. And sonar is one of them. So that is basically unit testing.

Let's say you have existing code base, and you as a new developer wants to add a feature inside that particular code base, and you are changing ample amount of functions inside your application. Now once you're done with your features, you'll ask tester inside your project, that dude please test this. Now in that particular testing, your QA will start getting issues. In other functionalities that you don't even touch. Now you are fortunate if your QA is finding that for you right. Sometimes that will go inside production directly and it will break things that you don't want to break right, and you didn't even touch them. That is when if you have unit test that is covering entire code base, what you can do is you can just run the amount fo unit test that you have already and they will tell you that the respective existing functions are working fine or not. If you are breaking some other functionality, then that particular unit test will fail. Now that issue which may lead inside your production and break stuff can be caught up front by using unit testing. So faster feedback is something that unit tests provide us right. Once you do your changes, you just run a quick unit test and that will tell you that if the existing functionality is broken or working. Unit tests are generally lightweight, faster, and easier to maintain right. And mainly helps us to debug early and better. And it gives some confidence that if my QA's are passing that means I haven't broke another functionality. So that's how you get a bit of confidence as well while you have unit testing inside your application. So next time you implement a feature, never ever skip unit testing okay.

Now, in our spring applcation, we have a test folder, with some packages and default ApplicationTests class with @SpringBootTest annotation. So we use a dependency called spring boot starter test which is automatically injected in pom xml file by spring which includes a lot of libraries for us like Junit5 and Mockito. So what we have to do is create the same kind of packages for which class you want to create tests for, suppose for ServiceClassTest we'll import service package respectively. Another quick way to create a test in intellij is to go over which ever function you want to create test case of, and use cmd + shift + t, that'll open a pop up and you've to accept the button create test for it.

SPRING BOOT AND AWS

So before starting off with aws, we'd probably be knowing java, spring, maven, git, docker basics because these we'd be using in our tutorial.

What are the core aws services which we have to learn? Now there are many services in aws which we are categorized into multiple categories. For example, we have compute. When it comes to compute, think of it as a actual computer, there is AWS EC2, Elastic Beanstalk, and Lambda. THen we have AWS S3 for storage service for storing images and videos. After that, database comes into picture. There is something called as RDS which is provided by AWS for connecting MySQL/Postgres to the cloud that we'll look into. Then we also have DynamoDB. After that, when it comes to networking, we have Virtual private cloud (VPC), Route R3, API Gateway and these things. After that, when it comes to security, we'll look into IAM, we'll see secrets manager, and cognito authentications as well. After that, when it comes to monitoring, aws provides CloudWatch and X-Ray. After that CI/CD pipelines will come into picture, we use CodePipeline and CodeDeploy provided by AWS. After that Infrastructure as a code is provided by aws as CloudFormation or we can make use of Terraform as well. Then we have containers then we have ECS, EKS and Fargate. After that aws provides some servicse for messaging, such as SQS (simple queue service), SNS (simple notification service), eventbridge for async processing. After that we'll jump into serverless that is lambda functions and spring cloud function which are lightweight services provided by aws.

Apart from this, we'll look into spring boot integration with it. For example, upload files to S3 from spring boot, connect spring boot to rds/dynamo, deploy app to ec2 and elastic beanstalk, integrate spring boot logs with cloudwatch, use sqs for background tasks, secure config with secrets manager, ci/cd pipeline using codepipeline, host frontend on s3 + backend on beanstalk.

AWS Free Tier

Now we're going to dive deep into free tier so that we don't go into unexpected bills. We'll see the step-by-step process of signup with aws. After that, we'll set up billing alerts. And then common mistakes to avoid.

Now when we go into aws.amazon.com/free we'll see that it says 100 AWS products on free tier, and three different types of offers. First, there is something called as firee trials, then 12 months free, and after that, there is something called as always free tier.

So we can see that Lambda, S3 (1GB), CloudWatch monitoring is always free. And if you go into their website and look at the always free tirs, you'll find more details.

After that, we'll sign up and create an AWS account as usually we do, sign up and stuff.

Now, because we don't want bills, we'll set up a budget notification, where even if we spend a single rupee, we'll immediately get notification. Basically whenever we exceed the free stuff limit. The options to set billing can be found on Budgets on left side bar. The billing alerts are basically free of cost and won't charge us anything at all.

AWS IAM [ Identity & Access Management ]

Now, what exactly is IAM? Let's say here we have an IT company, and we all work in the IT industry. Let's say there is a new employee who wants to join this particular company. When this company actually onboards this employee, what they do first is, they'll create a user of this particular employee. First they'll create a user so that this guy can login inside the system of this particular company. He'll have some kind of access. And in order to do all this. Like creating user, providing access to various resources in the company. For example file systems, labs, officies. And they'll need some kind of service right. They'll have something called as a security system. They'll develop some kind of security system so that they can manage all these users and manage all the access to this particular company to all the users, not only this new employee, but all other employees. Same thing is done by aws just that instead of this IT company, consider this aws enviromnet.

Now we have aws instead of it company. So this guy is able to use the aws account which means this guy is the root user. But it wants to create some other users as well. Let's say I want to give you access to my aws account so that you can login and do your job or there is a root user in the company and I'm joining as a developer in that company. Now, this root user has to give access to me to aws account so that I can go ahead and do my job. In order to do that something, there is something called as IAM. Through IAM, this new user can also access the aws account apart from the root user. Now what we can do over here is we can give some kind of password. Here we have some kind of password. So this guy will use his username and his password, put it into aws and login into the same root user's account. So this is basically your identity. So you have creatd a user so that you can login inside your aws application. Now a user can be a person or a user can also be a application as well. For example, let's say we have some kind of application, spring boot application. Now from this spring boot application we want to access few services of aws. For example, let's say we want to put the data in S3 bucket. How can we do that? We need to create the user for this particular aws account as well. Once we create the user, we will be able to access this particular resources in the aws. Again, now what is the difference between these two? This user is basically passwordbased user, and this application is basically your programmatic user. So it's a programmatic access that we are providing to this particular application because we are going to access resources but through our program right. We are going to access through our program that is through our code right.

Now suppose we have created a new user by using password and he is able to login over here, but he is not able to access the resources or apis in aws account. What it is not able to access the resourcs? Because we have not given an permission to it? So when we say oermission, you can give permissions by using policies. So each permission will have a policy document. There are some policies pre-defiend for each aws service that we have to choose from for the new user then it'll get the access accordingly.

Now let's say we have many users now to this particular aws account. Right? So we kept them as 2 groups. One group is for developers. Other group is for testers. Right? Now since I have created this user and gave him ec2 and s3 access. What I'll have to do here is give the access to all the users. But then I'll need to go to each one and provide the policies separately. It is so time-consuming when ultimately all the developers are going to have the same permissions. So doing the same thing over and over again is an overhead. What I can do is create a group, give the permissions to this particular group itself, like access to ec2 and s3. Now what that means is this particular group cna access ec2 and s3 and what I'll do now is just pick all those users and put them into this particular group of developers. And the same I'll do with testers with a separate group where suppose I just want to give ec2 access and not s3 access.

Now we have IAM Roles, right? What exactly are roles? Basically these are a set of permissions that anyone can assume temporarily to do a specific task. So this is basically a temporary permission to a user in order to do some task in aws, right? For example, let's say I am a user, and I want to see a billing, what exactly is the billing of this aws account? But I don't have permission. I don't have this particular policy.

So a user belongs to a group, and that user has been assigned policies as per the group permissions. Now suppose if a user wants special permissions separately, then it can use roles and get the access in a termporary manner. So these roles have policies attached to it, which will be used for users to give temporary permissions.

AWS S3 [Simple Storage Service]

Amazon S3 is a highly scalable, durable, and secur eobject storage service. It allows you to store any amount of data such as files, images, videos, logs, backups etc. That means we can store any kind of object here and as large as we want. So we want to do everything here right for storing files for fast retrieval.

Let's quickly see the key concepts related with it. So what exactly is a bucket? Buckets are like folders, which is kind of a top level container for your files (objects). And what exactly is an object? Any file that you want to upload (with metadata and key). Now what is this key? Key is basically the unique name each file is associated with. So key is like the name for the object in a bucket. So like in this manner, there are multiple files we can store in s3 with same names and segregate them among the folders as well, but they in fact would be having different keys. After that we have region which is basically where your bucket resides. That means it is basically geo specific region. So your buckets are actually residing in specific regions of the world. Right? So AWS regions are geological regions where you can store the files for faster access from your current location. After that, we have storage classes, it has different cost/durability options like standard, intelligent-tiering etc. After that, we have public access, which basically controls who can access the bucket or files.

Let's look at the diagram. So we have something called as aws s3 service. Inside that, you'll have different buckets. Bucket is basiaclly a container or a folder which is a root level folder. Let's say in that bucket you can have a different objects like object 1, object 2 and object 3. You can even create different folders and you can put the files in that particular folder as well within a particular bucket.

Creating a bucket is pretty much easy, and similar to windows folder structure within the bucket. The interesting thing is to understand the different types of S3 services provided by amazon and their use cases. Here is it. The cost is on GBs per month model.

Now suppose we have our spring application here. After that, we have to connect to AWS. In order to connect to aws from your local application, what you need is a SDK. Now what is SDK? It is basically software development kit. This is provided by aws which contains various tools, libraries and various api calls in order to communicate with aws from your application. So first thing we need is aws sdk. Now what you can do is connect to different clients in order to connect to different services inside our aws. Now we want to connect to aws s3. So what we are going to do? We are going to create s3 client. It is basically a class provided by aws sdk in order to perform operations with s3 bucket. And by using s3 client you can do a lot of stuff like creating a bucket, you can even upload files and read files and update files.

Now, lets' see the code for aws sdk to integrate s3 into spring boot.

First we need the aws sdk dependency from maven into pom file. You'll do it by yourself.

Then we'll see the configurations we need to connect to our aws account.

@Configuration
public class S3Config{
@Value("${cloud.aws.credentials.access-key}")
private String accessKey;
@Value("${cloud.aws.credentials.secret-key}")
private String secretKey;
@Value("${cloud.aws.region.static}")
private String region;
@Bean
public S3Client s3Client(){
AwsBasicCredentials awsBasicCredentials = AwsBasicCredentials.create(accessKey, secretKey);
return S3Client.builder()
.region(Region.of(region))
.credentialsProvider(StaticCredentialsProvider.create(awsBasicCredentials))
.build();
}
}

Now we need the service that will either upload or download files using the aws client and bucket in the aws account.

@Service
public class S3Service{
@Autowired
private S3Client s3Client;
@Value("${aws.bucket.name}")
private String bucketName;
public void uploadFile(MultipartFile file) throws IOException{
s3Client.putObject(PutObjectRequest.builder()
.bucket(bucketName)
.key(file.getOriginalFilename())
.build(),
RequestBody.fromBytes(file.getBytes()));
}
public byte[] downloadFile(String key){
ResponseBytes<GetObjectResponse> objectAsBytes = s3Client.getObjectAsBytes(GetObjectRequest)
.bucket(bucketName)
.key(key)
.build());
return objectAsBytes.asByteArray();
}
}
@RestController
public class S3Controller {
@Autowired
private S3Service s3Service;
@PostMapping("/upload")
public ResponseEntity<String> upload (@RequestParam("file") MultipartFile file) throws IOException
s3Service.uploadFile(file);
return ResponseEntity.ok( body: "File uploaded successfully!");
｝
@GetMapping("/download/{filename)") no usages
public ResponseEntity<byte[] > download(@PathVariable String filename) {
bytell data = s3Service.downloadFile(filename) ;
return ResponseEntity.ok()
.header(HttpHeaders.CONTENT_DISPOSITION, "attachment")
.body (data);
}
}

At the end, you need some configurations which you will get when you'll create a user and give it permissions to access our app through IAM. Then you'll get the access key, secret key, and the region it is in. Also the bucket name should be known.

There is another way, you can use MinIO server in your local environment to test the functionality of your codebase in spring with aws sdk for s3 integration because it supports aws sdk and the same code can be used here to test locally. Just in the credentials, put the access and secret keys as minioadmin and you're good to go.

AWS EC2

Amazon Elastic Compute Cloud (Amazon EC2) is a web service that lets you launch and manage virtual servers-called instances-in the AWS Cloud. It delivers secure, on-demand and scalable compute capacity, so you can add or remove servers within minutes and pay only for the resources you actually use.

As we can see in the diagram, elastic as the name suggests, means that it is scalable, and we can scale it as much as we want. Compute means that it gives oyu a procressing power like your computer. So your computer is again a machine or some kind of server which you are using locally, Right? So think of EC2 instance as a separate computer which is running in aws. After that we have cloud that means it will be running in aws. That means aws will maintain the infrastructure,

Now let's say when we have a spring application, and we want to host it so that anyone will be able to access it from some other location. What I will do ? I will go ahead and deploy it on a server. Now this particular server is a physical server which actually have RAM, ROM, CPU and all those things and it will have OS system as well so that you can go ahead and connect to it. So what you will do? You will go ahead and put this application on this server and make it available on over the internet. Right. So that is something you can do? Now what is the problem over here? Here, we need to maintain this particular infrastructure and you need to buy all these hardware things and maintain it. That is the problem right? Basically you cannot buy entire server just because you want to host a website. Right? It's not feasible. Well, it's feasible for companies who have their own product and they are earning too much from their product and they are hosting their product on their server. So few companies will have their actual servers hosted in different cities and they will be deploying thier applications on that particular server and they will maintain the server as well, they don't have any problem, but maintaince is going to be difficult again, and there are many problems over here. What if this guy goes down? If there is any electricity failure then this will just go down, right? So what we can do is same server we can create inside aws? Now how we can do it? The answer is EC2.

Now same application you can create inside EC2 and this will guive you same virtual machine as the server. It will have operating system. It will have your RAM. It will have CPUs. It will have everything that you need that your computer actually have. It's a virtual computer hosted inside aws. Now for us it's a virtual machine but for aws, they will have actual infrastructure for it. This particular infrastructure and they will maintain it for us. And for maintaining that, they will cost us some money. So when you start your EC2 virtual machine, which they call it as instance. You will be able to deploy your application over there.

So AWS EC2 has something known as AMI [Amazon Machine Image], through that we can choose which OS we want for our instance. By default, aws chooses Amazon Linux, but there are windows, ubuntu os we can choose in free tier. Then we have something called as Instance type, through which we can choose the Cpu power and the Ram we need for our instance and accordingly the bill will be generated per hour. For example, there is nano instance with 1 cpu 0.5gb ram, then micro instance with 1 cpu 1gb ram, and then small instance with 2 cpu and 2gb ram, and likewise we can have even 48 core cpu 196gb ram instance as well. Aws truly has a lot of options available for EC2 instance. Then we have Key Pairs through which our application will be able to connect with our device using SSH keys. And then we have something called as Security Group. Let's look into it.

Let's say we have this particular house, and this particular house have many doors. This is one door then you'll have one door at the back, many doors basically. What I will do to protect my house, I will hire a security guard, and I will ask this guy to secure my house that dude, there may be lot of people who wants to enter my house, don't let them enter until I know them. So what I will do, I will go to this security guard and give him some rules. Someone who is coming if that is my friend or family or someone who I know then let them pass through front door. If someone who is coming they are servant people right who are going to do some job at my house ike cleaning or stuff then ask them to come through back door so that they can go to kitchen and do their stuff. A rael list I will provide to this security guard in order to enter my house through different doors. Similar to this example, now let's see the aws diagram.

Now here in this case, your ec2 is basically your house and your application is basically running on ec2 instance. There should be some entry point of this particular application. Like in this house we have doors, we have front door, we have back door. So in order to connect to any application, be it your spring boot application or any other application, you need to have an entry point which we call as ports. So usually we give server port on spring boot application, right? We deploy on 8080 porty inside our local host which is a port of http. Now for ssh also, we need a door that is port number 22. Now these are two doors for my ec2 instance. So I can connect to http via 8080 port, and I can connect to ssh via 22 port. Now, these two port doors, who is going to be my security guard and allow these two doors? Our security group in aws is going to be my security guard. It basically acts as a firewall. It's a firewall in front of my ec2. Security group is basically a group of rule which is acting as a firewall for your instance. Now this particular security group will have rules. So we give rules to this particular security group. Now we have have many rules, suppose if someone is coming from port 8080 or port 22 then allow him otherwise not.

SPRING SECURITY

First, we'll understand what exactly is spring security, and what exactly is the architecture. Then we'll see what is authentication and authorisation.

Spring security is basically a framework designed inside spring in order to secure your application right. Now how it will secure? It will protect our apis, or web applications, or microservicse from unauthorized access or attacks or security threats. We are writing our applications and managing everything, and we are storing data inside database as well, but what if our application is not secure. What if the user data that we are storing inside databases is not secure? That is the problem right. Anyone could attack your application, a group of people called hackers would attack your application and get whatever data they want right. They have many ways to do that. To prevent that point something called as spring security comes into picture. It is very important for our application.

Now what is authentication? Authentication is basically identity verification, and a process of verifying who you are. When we say authentication, a user will be authenticated by who the user is, and it ensures that the user is legitimate before granting access. So basically we will check if the user is valid or not. After that, what is authorization? Authorization is basically access control. And this is a next step once your authentication is successful. Once the user is authenticated, after that, the authorization comes into picture which defines what you can do inside your application. So there may be thousand features inside your application, but which feature you can access, that is something which will be defined by your authorization. And it ensures user only accesses what they are allowed to. For example, if the user is admin, he will be allowed to access everything or if the user is basically a normal user then they have access to limited features. So that is basically your authorization.

So when we add spring security dependency, we get passwords, and when we try to access any rest endpoint, it'll basically ask for username and password to developer. So this is what happens by adding spring security dependency and my application is magically secured. So now we can only access our application by using this password that this spring printed inside our console. And it is saying the generated password is for development purpose only. And your security configurations must be updated before running your application in production. The default user is basically just the word user. But what is happening behind htis magic? We'll look into that.

Let's understand the architecture of spring security. As we have undertood spring filters, which execute before the request reaches your application controller, we have something known as spring filter chain which is added with the spring security dependency in the already existing filters we have. In this filter chain, we do have multiple other filters as well, but spring security adds more filters to your list of filters, so this happens when you add support for spring security. Now, if you go to this particular architecture, that is spring documentation then you will find many parts over here so first it is saying a review of filters right. What exactly are filter chain? This is something which we have already seen and this is part of separate api right.

Now there is something called as delegating filter proxy, so basically we have a servlet api, which is basically a separate life cycle from your spring application. So you have spring application and you have servlet api, both are different things right. We are integrating those now and filter is a part of this guy. Servlet api have its own life cycle and your spring beanas have its own life cycle. Your filters will not have access to any of the beans so these two are separate things. What we want is we want a bridge between these two. We want something that will connect our servlet api life cycle to our spring application. So that is where something called as delegation filter proxy comes into picture.

In official documentation, it says spring provides a filter implementation named DelegatingFilterProxy that allows bridging between the Servlet container's lifecycle and Spring's ApplicationContext. So basically servlet container allows registering filter instances by using its own standards. So we need something which will bridge the gap between these two so they provide a solution for that which is delegating filter proxy which will get added to your standard servlet container so this guy delegatinf filter proxy will get added to your servlet api container. What it'll do is delegate all the work to spring bean that implements filter.

So to simply understand what the documentation is trying to say, it says in order to connect your servlet api to your spring application context, we have something called as delegation filter proxy, and when look deep into it, it has something called as filter chain proxy inside your delegating filter proxy, which again will have your security filter chain and if you look closely, it'll have security filters within it. so there will be multiple security filters.

In development, spring has generated username and password and telling you to use it, but in production you may be using database or in-memory storage of your application, that is basically one method of doing it, or you can make use of something called as OAuth2, or you can also use JWT authentication or LDAP authentication, so we have multiple ways.

Now since spring is providing all of these ways of authentication and each way of authentication would be having its own filter mechanism, then do you think spring should add all of these filters for every authentication way all at one place, that won't be feasible right. Now since the default filter of spring security filter is actually username and password authentication filter, then it would be tedious process in order to handle that auth filter for each of this particular type of authentication. For this reason, spring provides its own authentication provider. So if you are making use of username and password, then spring provides authentication provider which will do that kind of authentication which is dao authentication provider. If you are using OAuth2 login then spring will provide authentication provider for that only. So spring segregates this authentication provider from your filter and each method or each tech of filtering will have its own authentication provider.

Let's say you have username and authentication filter, your request is coming over here then what this guy will do it will delegate your request to respective authentication provider which will authenticate the request for you right. The actual authentication part is in hands of your authentication provider depending on which method of authentication you're using right. Now in this case, username and password this guy will give the authentication task to this particular dao aithentication provider and this guy will do the task for you. But here we have multiple filters right, and we have multiple authentication providers. Now how spring would know that which authentication provider to use for each filter right. There will be multiple filters right. So how spring would know which particular authentication provider to to pick among these? In order to solve this problem, spring has introduced something called as authentication manager, which bridges the gap between your authentication provider and your filters. Now this particular filter will delegate the task to authentication manager that dude, I don't know which provider to use, this is basically the information that I have, you choose whatever authentication provider you want to choose and authenticate the request. Now this authentication manager is basically abstraction, and this has an implementation which is called as provider manager, which basically iterates through each of these authentication provider and check which one supports the incoming request right. So this guy authentication provider actually have one supports() method which returns if this particular authentication provider which we are looking into currently supports this particular request or not. If it supports then it will delegate the task to that particular authentication provider so that is basically your authentication manager and that is basically your provider manager right.

Now we know that spring security has provided us with a password, and it says that this auto generated password is for development purposes only, but in your production application, you need to have your own mechanism in order to do your username password validation and I am not responsible for that. Now that particular username and password needs to be validated and that particular username and password will be different in each environment that is local or production. And it may be stored inside your database. Now, how your authentication provider is going to retrive this particular user information from database. That is a question in front of this authentication provider? Because we are not going to write much code just to do that right. Now in order to solve this problem, we have a solution. Spring has something called as UserDetailsService provided by spring security. Now this authentication provider will connect to your user details service and this will have interfaces, for example, if you're storing inside memory, then you'll have InMemoryUserDetailsManager or otherwise it'll handle JDBC UserDetailsManager which will actually connect to your database and fetch the user information and return it to your user interface, and with that this user details service guy will return the user information to your authentication provider. Now another problemm arises here. If you're aware, we don't directly put password values inside your database, and instead we encode the password values and save it. Now suppose the password is encoded, then how will authentication provider know the actual value of password. Because from your user, you'll get actual values, and you've to validate according to that. So that is when something called as PasswordEncoder comes into picture. So this password encoder is part of authentication provider which will encode and decode your passwords which are stored inside your database and after that, decoding it will evaluate the password from your incoming request and return whatever is the result. So that is when something called as PasswordEncoder is used inside your spring security. Now once your authenication provider authenticates request, what it'll do? It will return something to your authentication manager right. it'll return the object of authentication to authentication manager and from authentication manager, it'll be returned to your filters. So this authentication object needs to be stored somewhere so that other part of your spring application will be able to access it to check all the details of your authentication. So that all other beans can access it inside your application to check the the authentication object. Now spring has a solution for that as well, which they call it as a SecurityContext right. So this particular authentication object will be stored inside your security context. So this security context will store your authentication object right. Your authentication object or also called as principal object right. And to access that, our spring application has provided some kind of abstraction which they call it as security context holder, which has its own methods such as get context, which will return you the authentication or principal object. That is when security context comes into picture, which will hold your principal object which can be used inside other parts of your application.

As we can see in this diagram, there are two more additional filters apart from the username and password authentication filter, which is security context holder filter which basically remembers that you have already been authenticated and does not reauthenticates again and again, and the other which is exception translation filter, whose job is to catch all the exception or authentication failures inside our filter and throw the respective error to client.

Since the default authentication behaviour is form based auth which we do not want because our application is purely backend oriented. So we'll look into spring security basic authentication for authentication without forms. In our official documentation, we can see the diagrams how they are explaining the flow.

This diagram explains what'll happen if user makes an unauthenticated request. So when the GET request is being read by this security filter, since you've no access it'll throw AccessDeniedException which will be recorded by ExceptionTranslationFilter, which'll send the response back.

Now this diagram explains what'll happen if user is making an authenticated request through basic authentication filter. So what it'll do is it'll generate some username password authentication token, then it'll pass that token to authentication manager, and once the request is authenticated, if it is success then we'll store inside security context holder and we'll allow application to continue, but if it is a failure then we'll again make use of security context holder to store the respective failure details, and we'll not let the application to continue.

Now when we add this dependency inside our spring application. By default, spring enables form based authentication.

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-security</artifactId>

</dependency>

Now we have to tell spring security here that dude, I want basic authentication through http itself. I don't want form based authentication. So for everything that has been running in default inside spring security architecture. We can modify that at every level to ensure that we are using basic authentication right now.

@Configuration

@EnableWebSecurity

public class SecurityConfig {

@Bean

public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

http

.authorizeHttpRequests (auth->

auth.anyRequest) .authenticated)

. httpBasic(withDefaults());

return http.build();

}

}

Now configuring basic authentication filter requires you to implement the UserDetails interface while creating user entity, UserDetailsService interface while creating service, and requires yout to use Authentication Manager, And Authentication Provider classse. Now what you have to do is try to find out how to do all this by yourself. This is a single assignment for spring seccurity that'll help you revise everything related to security.

JWT Authentication

Now let's say there is one employee and this employee visits his office on daily basis, probably 3 days a week because people are lazy now a days. Now when this guy is going to office, he needs to authenticate himself, by saying that I'm the employee of this office right. Any random people cannot just go inside this office right. They need to be authenticated. Now what office can do? They can put a security guard over here. Now what this security guy will do? This guy will validate this particular employee. Now how this guy is goign to validate? This guy don't know this employee or let's say even if this guy is knowing this employee and even if this security guy changes tomorrow, this new security guard will not know this employee right. So this security guard needs something so this guy can validate this particular employee right. Now this employee can go to this particular security guard, he can show his ID and this guy can validate that ID right. Let's say there is soem register over here, in which they have entries of all the employees, and what this security guy will do? He will ask the ID of this guy and validate that ID against this particular register right? If that register contains the name and the details of this particular employee, if that is present then this guy will be allowed this particular employee to go to office. Right? Now, every time this guy is going to office, he needs to validate and go through all these entire process. Now this will happen for each day, right? Because this security guard cannot just let anyone pass through so he needs to validate as well.

Now this scenario is very similar to basic authentication. Security guard is basically spring security, and his register is basically your database where your username and password is stored. Now in order to access this office, we are giving this username and password to this security, and this security is validating us based on data inside the database. So because your database stores username and password, this situation is stateful. Because you are actually storing the details inside the database, and each time user is trying to access you are validating that particular request inside your database.

Now one of the problems with basic authentication is each time thsi guy is going to office, he needs ot validate right. Each time your client is sending request to your application, that client needs to send username and password, each time, so that is basically the problem with basic authentication. And let's say this employee is traveling right. Now let's say this is bangalore office. Now this compnay opens office in delhi as well. But this guy used to go only to bangalore and this security guard validates it against this register and allows this guy to go to bangalore office. Now this guy went to this delhi office. Now there will be some security guard and some other register. Now this guy will give its username and password, and the security guard of delhi office will try to find it in its register, but guess what? It's not there. Rather, it is present only inside your particular register. So that is again a problem. Now even if this employee belongs to this office. He cannot go inside because his details are missing inside this register. That is the problem with scalability.

So inside production, you scale your application right. You create multiple instances of your application. So that is basically another problem. Now what we to do is maintain these registers on a centralized database and all these instances can accese the same database. So that is basically one solution to this problem. So basically point overe here is that your basic authentication will not suit when it comes to microservices architecture or your stateless architecture. Now one more problem is this guy entered bangalore office right. Bangalore office may have multiple things right. Now how do we know this guy can access what department? His access again needs to be validated inside your office as well. So handling your roles and permissions is again a difficult thing when it comes to username and password authentication. Now what is the solution over here? What can be done? Now what if this guy is the employee of this office. He goes to the security guard and authenticates himself first, that hey I am the new employee of the company and here is my id. Now this security guard will check inside database, and if this is authenticated employee then what security guard will do is it'll issue access card to this particular employee. That dude this is your access card and this card will now contain all the details about this particular employee. Like what part of the office he can access. Now next time he visists the office, he doesn't need to go to the securiy gaurd right. What this employee needs to do is just carry this access card with him. So he can go to this office and just swiple his access card in the office door. And if that is authorized, he can go inside that office flawlessly. Now suppose he's going to delhi then he can just swiple the same access card inside the delhi office. So if this guy is authorized to access that department then the door will open automatically right. Now suppose somebody else gets the card that we issued to that guy, now we cannot just let anyone have access to office just because they got the card right. So we need to validate something inside the office when this guy is swiping at the door. So that is when your particular access card will be validated inside your office by using something called as a signature. So, in this case, this particular access card will be considered as, let's say some kind of token right? And when your client is sending the request to your application, they will just send this token along with it. Now there are multiple approaches to send this particular token right. Now we can do this with either XML or JSON. XMLs are very bulky right, so they are not preferred. Since json are easily compressable, and it is very easy to flow inside your web requests, and it's lightweight as well, and it's flowing through web so they call it as json web tokens. So that is basically the full form of JWT, that is Json Web Token. And that is how we use Json web tokens. And this token is not stored inside your database. Now this Jwt token will be shared to your client right. And your client should store it somewhere so that it's not accessible to anyone right, otherwise if other person finds the same access card and try to access, then they will be able to access right. Even then, people are using jwt widely, and this JWT token also have an expiry time. So after some amount of time, this token will be expired and your client will need to reissue the token right. So that is basically JWT.

So, how does the JWT Token looks like? It looks something like this. You may be able to see three colors over here separated by dot. These are actually three parts. Each part of this token has a significance. And here they are highlighting what is the significance. So first part over here is basically your decoded header. This means they will use some kind of algorithm. In this case, they're using HS256 which is pretty famous algorithm for encryption to encrypt this particular JWT token. And those encryption details are stored inside this first part. So first part will contain the type of your algorithm so your server could decode it. Now the second part will have actual information about your client. What is the subscriber id and name like that stuff. We can define issue at and expire at ids as well here. And third part over here is basically the signature verification, so I was talking about the signature over here right. That the signature will be validated when your jwt token is coming to your client. The signature will be validated, right? This is basically that signature and this signature will be validated when your request comes to your application. And this can be anything right? I can add any stuff over here, just that I need to verify it with my application so that is basically the signature.

Now let's look into how JWT comes into the flow of authentication. Now when your client is sending the request to the server. In basic authentication, you need to send username and password with each request. So first you need to login, and each request you need to send username and password. But that is not needed because we are already authenticated. So here in this case what we need to do, user needs to be authenticated only once and needs to send this post request, let's say /login only once, then it'll do the authentication, and once the user is authenticated, then for that particular user, what we do is we create a JWT token, and we send it back to the client. Now your client has the JWT token because this guy has been authenticated once right, and need not to be authenticated again and again. So this guy have token your client can store this tokne somewhere in the memoy, and whenever your client is sending subsequent requests, then this guy will send the JWT authorization token that client has, as Authorization Bearer token, this request will not come to your application right. And how they can pass it. For example, if you go inside your postman then here in the authorization, you'll have multiple type of authentication right. You can see post selects basic auth type as default. But there is a option of bearer token as well, that we need here. And that token will be received by your application end. Once your application gets that token for any request, this applicaiton will first extract the jwt token from your authorization header. Once the token is extracted, that particular token will be decoded, through header.payload.signature. After that this particular signature needs to be verified, if the verification fails, we will send failure request which is 403 unauthorized error. If the veriifcation is successful we need to check the expiry of this particular token. And once all this process is completed, then finally your request will be processed to this particular controller, and that controller will send the response back. Now suppsoe if the token is expired, then we'll send the message to client that your token is expired, please login again. Now what this guy has to do is again send the authenticate request and issue a new jwt token, which can be used again in the same manner.

Now with jwt tokens what we want to do is we only want to authenticate once right. We don't want to authenticate again and again that also by using login or authenticate api right. How can we achieve that if we send the authenticate request to get the token and if the filter comes into picture, that filter will try to authenticate that particular request and for each request, that filter will keep on doing that, but what we want is we don't want this basic authentication filter provided by spring right. We want to directly call the authenticate api without any authentication. So what will we do is directly call the authenticate api and directly call the controller of authenticate api right. And we'll skip this particular basic auth filter for now. Because we are implementating jwt over here and we don't need basic auth filter. What we need is JWT authentication filter. But that will not come into picture while implementing your authenticate or login api. Your login api's purpose is to return the jwt authentication token right. Once user gets token and user sends the subsequent request then the jwt authentication filter will come into picture.

So we'll make changes to our spring security diagram. And here we got the authenticate flow for jwt authentication. Now when client sends the request to your application, we will skip the filter for only authenticate api. For only authenticate api we will skip this filter, and we will send the request directly to our AuthController. Now what is the job of AuthController? AuthController will create JWT token for our user, so that this user can send that particular token in other apis right. Now, this client will send the request to AuthController with username and password right. So here in this case, we are skipping the filter, but we still need to authenticate this particular request. This username and password we need to authenticate. Because how do we know that this particular username and password is correct? Once we authenticate that after that only we can generate jwt tokens right. We cannot generate jwt token and send to any user right irrespective of their username and password. We need to first authenticate them. But now here if you see in the AuthController, our request already came to the AuthController. Now how we are going to validate or how we are going to authenticate the user. Because in the request we'll have username and password. But we need somone to validate that right. Now what happens in the normal case is filter delegates the task to Authentication Manager. What we can do here is do the same thing, since filter is not there, we can directly tell authentication manager that dude, I have this username and password, please authenticate it. So we'll delegate the request to this authentication manager with the username and password and this guy will authenticate by using this same flow. This guy will call the dao authentication provider and fetch the data from our database, and then password encoder will decode it, and authentication will be completed, and the output of authentication will be sent back to our controller. And once that process is done, and user is authenticated. After that only, what we'll do we'll just create a JWT token right. Now this JWT Utility and libraries are just used for creating the jwt token. That is the simple flow of your jwt authentication.

Now suppose you have the token, we don't want to authenticate the user as long as he has a valid token, so all these things from authentication manager to authentication provider will not come into picture now. Now request is already authenticated, and we need to just check the token that we are getting from the user right. That will be done by Jwt Auth Filter. Now what this Jwt Auth Filter will do is, it'll talk to our Jwt Utility, which is our custom implementation that will talk to the jjwt library inside our application. So this filter will directly talk to Jwt Utility, and this utility will again have other methods related to validating your jwt auth token. Once this token is validated, then this jwt auth filter will directly call the security context holder, and add this particular principal object, that dude this particular user is verified and I'm adding this to security context. Now when next filter comes into picture that is the default username and password filter, it'll see that dude the principal object is already added into security context. So I don't need to validate it again. So it'll just skip that. And your call will directly go to your controller. So that is basically the flow of your subsequent requests.

JWT Authentication And Authorization is your final assessment. You need to have a hands-on experience in order to understand it.

After that, you can go with KeyCloak or OAuth2 Implementation to better understand enterprise ready security implementation.

SPRING BOOT ADVANCED TOPICS

[To Read After This Course]

1. Kafka / RabbitMQ
2. Eureka Service Discovery
3. API Gateway Using Spring Cloud
4. Authentication Using Keycloak
5. Microservice Communication Using FeignClient
6. Centralized Configurations With Spring Cloud Config

AWS

1. Deploy MySQL Into AWS RDS
2. AWS ECR & ECS For Docker Images
3. AWS VPC And Configurations

ASSIGNMENT

Create A Microservices Multi-Brand E-Commerce Platform In Spring Boot Where Buyers Can Purchase, Sellers Can Add Products, And Admin Can Manage Both Buyers And Sellers. Store Data In Mysql. Dockerize And Deploy To AWS. Implement Kafka, Eureka, Api Gateway, Authentication.