We have a Spring application which exposes all the business logic as RESTful web services, which is consumed by the jQuery front end. Our jQuery front end code is becoming unmanageable with javascript manipulating the html files. So we are planning to use grails with jquery/bootstrap to overcome these issues. Right now, we are doing a Poc to understand the implications of moving to new stack.
Our current understanding is that we will run two applications - one for grails and one for Spring backend. We can implement CAS to maintain the session between these two apps. Grails will use spring for all data as well as business logic. Our front end communicates only with grails, which in turn connects to Spring as need basis.
I am not sure what are the potential things to look for in the new approach. Can someone provide
feedback on our approach?
Thanks
--Venky
I would suggest to create only one app, in grails. Plug all your existing code into src/java and use groovy domains/services to get data from you existing business logic.
In this way you will not have the overhead to run 2 webapps that will communicate over http to serve one client request.
Related
I am not asking if it is possible, I know it is but I would like to know what's the best way to offer a rest service while having a front end in my application.
I'm developing a Spring Boot application, I currently have a controller that calls jsp pages, and a separate RestController. I want to be able to consume it with an Android application.
So is it correct to have both a Controller and a separate Restcontroller in my application? For example the Rest controller methods will be called from /api/*.
Edit :
I know the difference between the two, but since I want to be able to return a view ( and I shouldn't do that with a RestController) and I want to have a rest service I am wondering if I can have both of them (separately of course).
Thank you so much in advance.
I'd say that it's possible, but considered a bad practice (except for corner cases like a controller for Swagger in a REST application) in a typical, layered, spring app (will get back to that)
you may want to create a multi-module project, that may look like that:
parent project
-- core
-- web api (jsp based)
-- rest api (for android)
both web api and rest api depend on the core.
web api and rest api are separate deployment units. you can deploy them on the same server or run as separate applications (for example using spring boot). Depends on your usecase.
with that you can have your business logic in one place (core).
you may also want to read about ports and adapters architecture, which may give you an idea how to solve this in a more organized way than just having Controllers and RestControllers sitting side by side
I'm stuck with a mess of a web application. The previous developer started porting the Spring MVC/Apache Tiles application to Backbone, there wasn't a RESTful API to support the port however and it's stuck in this funky state where JSPs are rendering the HTML and some JS which then loads a Backbone View. About half the API has been ported to REST but the application is still far being a true SPA and even further from being done properly.
I've got a strong background in Angular and little with Backbone but next to nothing with Spring & Apache Tiles. The application either needs to go back to server side templating or be rewritten to truly become a SPA with proper organization/testing.
If I start (properly) porting to Angular or Backbone, is it possible for the two frameworks to work together (Spring / Angular or Backbone)? I've done a port like this in the past from Django to Angular on Google App Engine and it wasn't too bad but the application has significantly smaller. Has anyone done something similar to this, if so I've been unable to find anything on how to go about doing so or if I should even try.
Well, if you don't have a background in Spring & Tiles, it'll be difficult to learn & then port.
But if you're up for it :
1. Read about Spring (Dependency Injection & Configuration)
2. Read about Spring-MVC
3. Read about Tiles
Since, you already know about Django, you should be able to spot the similarities very soon. Once you become comfortable with Spring & Tiles, follow this approach :
1. Take a controller
2. Convert the JSP (which is returned by this controller) to a html template (used by Angular/Backbone)
3. Convert the model (data sent to the JSP) to JSON & start returning this JSON instead of the JSP
4. Create a route & test
5. Pick another controller
JSP is just a template & then model(data) is passed to create the actual html response, same as we do in case of Backbone (underscore template & then pass data to create the actual html).
This should be enough to start.
Regarding to the best way to design a system using spring-mvc (REST services) and jQuery . I think exists the following approaches.
One war file in which you have spring services and jQuery stuff, with this approach we have all the domain objects available to be used with spring-mvc, we can create initial jsp pages and then refresh some elements using jQuery calls to our services.
Two war files, one having the spring services and the other contains spring-mvc stuff and jquery, in this case the creation of pages could be done by jsp pages and also refresh elements with jquery calls to our services, but to make this possible we need to have a common library of domain objects to be used in the second war, also internally use restTemplate in some controllers that need to be created (It sounds like duplicate code).
Have one war file running the REST services and a other “package” without any java or spring stuff only jquery, it means all the call and information retrieval must to be done using jquery, initial jsp pages creation cannot be done with this option and all the content are obtained via REST services. (no need of use internal controllers to call services by java)
Thinking about it I realized that one and second have the following disadvantages.
Have services and web stuff in the same war file sound like a bad idea thinking in SOA, the movement of this war will result in move unneeded jquery and web stuff.
Have jsp and jquery stuff mixed not sound like a good idea but I think is a common practice (I wonder why?), using this I think we need to create some controllers in the second war to initially create the web pages, go using restTemplate to obtain initial information and then update or refresh using jquery calls. It feels that a have a controller just to retrieve data to the services, why don’t go directly …
I just want to implement the third approach but the question is: there is any disadvantages that I’m not seeing or any
advice that I should know before use that approach? Also there is any suggestion to handle this kind of systems it will be great to hear something from you, coming from java and jquery developers
I agree with you that version 3 gives you the most flexibility and is what you would typically see in the design world.
Treat the rest and the front end as separate applications entirely. If done correctly, you can have a very robust application capable of proper agility.
Version 1: Load the page in an initial controller call, and use jquery to make subsequent service calls. All code exists within one package.
The disadvantage is tight coupling. You are now restricted to the language of your api, and no longer providing a service based approach to your data and services.
I have seen this version applied mostly when the application developer cares more about async front end calls than a SOA based language.
Version 2: Have a war containing Spring Services, and a war for the JS.
The issues with this method can be overcome with the use of a jar instead of another server application. Though this approach is commonly used, the draw backs are still reliance on external packaging.
Using a jar that contains all the code to hit databases and create domain objects separate from the code that the controllers use to serialize and respond to web requests creates a very clean way to manage your api, however this creates a complexity and an extra component that can be avoided using version 3. It also gives the same odd behavior you see in version 1.
I have seen this approach taken by teams developing pure api applications. I have not seen this done on teams that also require a front end component. Method one or three has been used in these cases.
Version 3: Create an application that deals with just the front end responsibility Create an application that handles the server side responsibility.
In both version 2 and version 3, separate your service calls from your http calls. Make them different because it allows modularity.
For instance, we need to respond to http Requests
#Controller
class MyController{
#Autowired
private MyService service;
#GET
public String getData(String dataId){
return service.getData(dataId);
}
}
and we need to respond to active mq requests
Message m = queueReceiver.receive();
if (m instanceof DataRequest) {
DataRequest message = (DataRequest) request;
queueSender.send(service.getData(request.getDataId())); //service call
} else {
// Handle error
}
Also, it gives you the ability to manage what you need to handle on the http side different from your service side.
#GET
public String getData(HttpRequest request, String dataId){
if(!this.handleAuth(request)){
throw new 403();
}
try{
return service.getData(dataId);
catch(Exception e){
throw new WrappedErrorInProperHttpException(e);
}
}
This allows your service layer to handle tasks meaningful to just those services without needing to handle all the http crap. And lets you deal with all the HTTP crap separate from your service layer.
Here's my situation: I'm running a JBoss 7 in Domain Mode with several nodes. One node is in charge of my Liferay 6.2 another one runs several other web applications. Now I'd like to implement some kine of Single Sign On routine. So to use my web applications you have to go through liferay first. Authenticate agains liferay, then go one to one of the web applications.
So the question is whether there is a way to expose some of liferays methods to access the user store and check if the user, who's accessing a web application is the same as logged in on liferay. Developing some sort of bridge is fine with me. I'm thinking of a portlet which does all the interaction with liferay and exposes some methods like readUser(). Maybe I can do a jndi lookup for this portlet or a component embedded in this portlet to call readUser() from my other web applications. I think this sounds a bit like EJB stuff.
Using Liferays API, Services and LocalServices to read user information etc. shouldn't be that difficult (already played a little with that). I just don't know how to establish a communication between a web application and liferay.
If it's not working this way, I would settle for something else, maybe a webservice or an other way that makes sense but I'd like to try the EJB/JNDI approach first (except this makes completely no sense). Maybe someone can point me in the right direction.
Turning my applications into portlets is not really an option because these applicaions are quite large and already exsist for quite some time. So I'd like to leave them mostly unchanged - outside of auth stuff.
Thanks and regards
Sebastian
You can use a service builder and you expose your service as remote.
Several Options:
Just access Liferay's API methods from your applications. You can access the JSON API at http://www.example.com/api/jsonws.
There's also a SOAP interface (http://www.example.com/api/axis), that's typically available only from localhost (you can configure otherwise in portal-ext.properties)
You can encapsulate calls to those services by creating your own services. Use the tool of your choice or Liferay's servicebuilder. You can create empty entities and just refer to Liferay's own entities. Servicebuilder will generate JSON or SOAP WS if you let it. (what Slimen Belhajali mentioned)
As you specifically talk about the check for user identity, you might even want to think of a completely different solution and just look at single-sign-on (SSO) solutions. This way you'd sign in only once (to the SSO server) and automatically (implicitly) to your webapp as well as to Liferay. This works best if both access the same userstore, e.g. on LDAP.
I have a general question about the correct (or maybe: the best) way to handle data from GUI to DAO.
I built a project where GUI input is being validated and sent directly to a DAO class which handles (via Hibernate) the database updates/inserts.
Now I decided to split DAO and GUI up into two separate projects and use a REST WS with Spring integration to handle the data. I considered this, because I thought this might be a good idea for future projects (advantage of course being the complete separation of the GUI from DAO).
For the moment I have a bit of a problem of making this all work (Spring error creating bean xStreamMarshaller). But before I try unnecessarily I wanted to know: Is that really a good approach?
Is this really a correct way or am I doing something completely unnecessary?
I think this post can be useful for you:
Spring MVC RESTful multiple view - 404 Not Found
I like the idea to work with restful, because you can really split the application not just in the back-end, but in the front-end as well. This way you can just get JSON in your javascript. But of course each case is different each other.
Follows a video about the subject: Designing a REST-ful API Using Spring 3