I have the below question asked in the interview but could not able to find any straight answers to the below questions.
What design pattern do we follow while creating the REST API in Spring boot application?
Microservices uses which design pattern?
for your question one, we're using the (MVC) pattern to create a REST API but in the REST API we're not using View instead we're using a JSON responses, and also other patterns that may be used while building REST API including Command Query Responsibility Segregation (CQRS) pattern, its also worth to be mentioned that Microservices also use this pattern which we mentioned now since the Microservices uses an architectural style that involves building a large, complex application as a collection of small, independent services, The design pattern that is commonly used when building microservices is the Command Query Responsibility Segregation (CQRS) pattern because This pattern involves separating the responsibilities of reading and writing data into separate components which gives single responsibility to the component as they already are.
The questions that the interviewer has covered are fairly broad questions. Anyway, I believe that it is important to show your basic knowledge based on the Spring MVC pattern, and how the embedded Tomcat Servlet container in the Spring Boot operates. (So basically it is the main role of the Spring Boot Controller)
In the Spring MVC, you use various controllers to handle HTTP requests and create REST APIs, by adding spring-boot-starter-web dependency. This dependency includes some key libraries including the Spring MVC framework and the Tomcat servlet container. Then, you got two options either #Controller or #RestController, to create your own servlet for your web application.
Since the interviewer is asking about REST API design, I would prefer to use
#RestController, because this annotation is capable to produce RESTful response entities.
As for the second question, I am prudent to answer it, because Microservice Architecture is a type of "Architecture Pattern", which is a more complicated and sophisticated backend structure for the business service. Overall, I believe that the Event-driven design pattern is a good option as a fundamental one for implementing a successful MSA.
In the MSA, the event-driven design pattern is useful for enabling communication between different microservices projects. Because microservices are designed to be small, independent, and loosely coupled, they often communicate with each other using asynchronous messages(a.k.a. events). By using an event-driven design pattern, you can create a publish-subscribe model of communication between microservices, which can make it easier to scale the system and add new microservices over time.
BUT don't forget that MSA contains various design patterns that are useful as well!
Related
I am a Spring newbie and I would like to have a proper understanding of how a Spring based web application works end-to-end. Good'ol CGI, PHP, servlets and JSP have been around long enough that I believe I have a decent understanding of the end-to-flow for those technologies. I am seeking a similar clarity for Spring.
Specifically my question is whether Spring also follows a "container" architecture, similar to servlets (i.e. whether there is an execution environment within the context of the web server within which the business logic runs) or whether there is a different flow altogether.
There is undoubtedly literature out there but I find that it focuses mainly on POJOs, metadata, configuration files, annotations etc.
Based on the comment from #JB Nizet, I did some search on the Dispatcher Servlet and I found the following graphic which seems to very clearly show the end-to-end flow for Spring applications:
I recently worked on a project which uses Spring Data REST with Spring Boot. While it is GREAT to harness the power of Spring Data REST and build a powerful web service in no time, I have come to regret one thing: how tightly coupled the "presentation" layer (JSON returns) is to the underlying data structure.
Sure, I have used Projections and ResourceProcessors to manipulate the JSON, but that still does not completely sever ties with the database structure.
I want to introduce Controllers to the project, to integrate some of the "old" ways of building a web service in Spring. But how should I draw the line? I don't want to eradicate Spring Data REST from my project.
I am sure many of you have faced similar decisions, so any advice would be most appreciated!
What the terms added into the AOP, so that we are calling it Cross Cutting Concern.
Difference between Interceptor and AOP.
-This question is for lil bit discussion on AOP and Interceptor but please elobarate.
Interceptors are part of Spring framework which allow you to write logic by intercepting requests/calls in between the route. There are mainly 2 kinds of Interceptors in Spring.
Handler Interceptors, present in Spring MVC framework, are used to include your interceptor logic for web requests, whereas Method Interceptors, within Spring AOP framework, are generic in nature and not just limited to intercept HTTP requests.
When comparing AOP with Interceptors, I can say, in one line, that these Method Interceptors are the base understanding behind writing aspects in AOP.
AOP, aka Aspect Oriented Programing, is a bit complex subject to be explained in a StackOverflow answer. I would suggest you to read for it on internet and make yourself comfortable with the basics & AOP terminology before entering into Aspect Oriented Programing.
Below is one good resource to understand the dynamic proxy in Spring AOP and fundamentals of it.
Understanding Dynamic Proxy: Spring AOP Basics
Update
Wikipedia has a very simple yet effective definition & example for Cross-Cutting Concern.
In Aspect-oriented software development, cross-cutting concerns are
aspects of a program that affect other concerns. These concerns often
cannot be cleanly decomposed from the rest of the system in both the
design and implementation, and can result in either scattering (code
duplication), tangling (significant dependencies between systems), or
both.
For instance, if writing an application for handling medical records,
the indexing of such records is a core concern, while logging a
history of changes to the record database or user database, or an
authentication system, would be cross-cutting concerns since they
touch more parts of the program.
AOP with Spring Framework is described in a very simple manner at this article of TutorialsPoint which would help you get familiar with all the basic terminologies of Spring AOP.
I have a design problem at hand. Traditionally I had been developing Spring MVC/Struts/jsf applications with either REST/SOAP service serving the data.
Now we have HTML5 and other javascript frameworks. In this light, do we still need to create Spring MVC applicationS as such (assume that the data is served from a RESTful service)
If I go ahead with pure HTML5, CSS UI (with Ajax calls to RESTful services), what are the possible issues that I may get into? does this approach have security holes like being prone to cross site scripting?
Is it a good approach to start off with? Would this approach be called a single page app?
You still need to serve your single page app from somewhere, along w images and css files. This could be a Spring MVC servlet, or whatever.
I'd look into Spring Data REST which is a servlet that creates RESTful HATEOAS endpoints for you.
It's probably easier if your SPA and REST service are on the same domain, so you don't have to worry about cross-domain restrictions.
They are still vulnerable to XSS, as is any system unless you take counter-measures. Spring security can help here. Make sure you follow the OWASP guidelines.
Use Hibernate Validator's #SafeHTML annotation to prevent unsafe HTML input into your database. Use Spring Security's <content-type-options/> , <xss-protection/> , and <header name="Content-Security-Policy" value="..."/> settings to help fight XSS.
Spring MVC, Struts, etc. provide two core functions: Routing, and Binding.
Routing is dispatching an HTTP request to the relevant piece of code.
Binding is converting the world of Strings that the HTTP request sends you in to something more useful, such as a generic Java bean with not just Strings, but integers and dates.
Along for the ride are aspects such as validation.
Finally, they provide an environment that's particularly friendly to your view layer.
None of these aspects, per se, are obsolete in a world where all you have is JSON coming up and JSON heading back. You still need routing, but now you may care to route not simply on the request url itself, but on HTTP verb. You still need binding, having the framework marshal the JSON payload into some easier for java to work with is very handy.
But, (and I speak in general terms, not specifics as I don't know Spring or Struts well at all), while the MVC frameworks can fill the role of a backend system for a more JSON oriented and raw HTTP world, the specific REST frameworks do the job better.
There's no mistake that the MVC frameworks were a significant step up over raw Servlets. Raw Servlets are functional, but simply too primitive for real work. But with design decisions made from a world 10 years ago, some parts show their age and get in the way in the new world of more raw HTTP requests.
If you're doing a mixed app, some MVC, and some HTTP/Ajax methods, then it's better to work with your MVC framework than adopt a new one.
If you're doing a pure singe page app, then it's worth your while to adopt a framework that tends to that niche. They'll simply be a better fit.
Mind, also, they can live side by side. You can have both co-habitate in a single WAR if you wish, particularly if you're adding SPA features to a legacy application. It doesn't have to be an either/or situation.
But I wouldn't introduce an entire new infrastructure component simply to handle a couple of ajax calls. In the end, they're just HTTP calls, and the MVC frameworks (in contrast to most component frameworks) do just fine with raw HTTP for the most part.
I m a newbie & i m good at Struts framework. Today i tried a tutorial for Spring MVC Framework.
The example url that i tried following is as below:
http://static.springsource.org/docs/Spring-MVC-step-by-step/part6.html
I think they have made this tutorial much more complex especially near its end. I saw some errors mainly typos in part 5, part 6 of tutorial. I found Spring framework as not properly organized and how would we know what classes to extend especially when their names are so weird (pardon my language) e.g. AbstractTransactionalDataSourceSpringContextTests.
Overall i found that Spring is making things much more complex than it should be. I'm surprised why there is such a hype about Springs being very easy to learn.
any suggestion how to learn spring easily ? how to judge what to extend ? is there a quick reference or something?
The tutorial you have referred to covers all the layers of the application - data access, business logic and web. For someone who is looking to only get a feel of Spring MVC, which addresses concerns specific to the web layer of the application, this could be more information than required. Probably that is why you got the feeling that the tutorial is complex.
To answer your questions, Spring is easy to learn because the whole framework is designed to work with POJOs, instead of relying on special interfaces, abstract classes or such. Developers can write software as normal Java applications - interfaces, classes and enums and use Spring to wire the components up, without having to go out of the way to achieve the wiring. The tutorial you have referred to tries to explain things in a little bit more detail than experienced programmers would typically do in a real application, probably because the authors wanted the readers to get enough insight into how Spring works so that concepts are understood well.
In most applications (regardless of their size or nature), there is typically no need to extend Spring classes or to implement specialised classes. The Spring community is quite large and an even larger ecosystem of readily available components exists that integrate with Spring. It is therefore very rare that one has to implement a Spring component to achieve something. For example, let us take the example of the data access layer. Different teams like using different approaches to accessing databases. Some like raw JDBC, others like third-party ORMs like iBatis or Hibernate while some others like JPA. Spring distributions contain classes to support all these approaches. Similarly, lets say someone was looking to incorporate declarative transaction management in their application. Again, transaction management can be done in many different ways and a large number of transaction management products are available for people to use. Spring integration is available for most of these products, allowing teams to simply choose which product they want to use and configure it in their Spring application.
Recent Spring releases have mostly done away with extensive XML based configuration files, which being external to the Java code did make Spring application a bit cumbersome to understand. Many things can be done nowadays with annotations. For example,
#Controller
public class AuthenticationController
{
...
}
Indicates that AuthenticationController is a web MVC controller class. There are even ways to avoid using the Controller annotation and follow a convention-over-configuration approach to simplify coding even further.
A good and simple tutorial to Spring MVC is available at http://www.vaannila.com/spring/spring-mvc-tutorial-1.html. This tutorial uses XML based configuration for Spring beans instead of annotations but the concepts remain the same.
I have seen tutorial you follow , Its seems you have follow wrong one first , you first tried to simple one, Instead of tutorials you should go for book first
I recommend you two books to understand the power of Spring
spring in action and spring recipes.
For practical you can use STS a special ide for spring project development.Its have some predefined template you dont't need to write whole configuration yourself.
In starting just see simple tutorials like Spring mvc hello world , form controller than go for big ones
Spring is very cool , All the best.