I'm currently researching on Grails, if it would be a good choice to go with a Web Service client project. It is said Grails is highly beneficial for developing Admin Portals and Prototypes. However my concern is to use Grails for an Admin Portal where the Admin Portal is driven by the Rest-API calls. Therefore, I can consider that as a Web Service Client application. Hence, I won't be able get much use of Grails scaffolding feature to generate controllers or its related test cases. And also the Object Relational Mapping via Hibernate as well. But still I can get the views generated according to the domain objects that I'm defining. Considering the above concerns is Grails still reasonably beneficial than going with traditional Java/Spring and Spring RestTemplate approach ?
This is a bit of a subjective question, but IMO yes, a Grails web application that is primarily a web service consumer is still a fine choice. Groovy's remote API functionality is very productive and clean, and the view layer and controllers are high quality regardless of what the domain/service layer looks like.
In my current project one of our Grails apps is acting just like how you're describing, and it's been a success in terms of quality, performance, and productivity.
Related
I have a theoretical (and probably foolish) question about web api and an mvc webapp in .Net Core.Seeing as they overlap in Core, it's even easier to have an api and visual app in the same project, responding to different routes - great!
But, there's something architecturally fundamental which I always struggle with : Let's say I had a web api, which other services use to do some data things and some custom actions etc. Then, I also have a big mvc app, this is the central app (let's say for argument).. Here's the question.
1) Should the mvc app be making webapi calls over http(even though they will likely run on the same box - they dont have to of course), 2) Should the mvc app be sharing the service and repository classes with the webapi?3) Should the mvc app be programatically calling webapi from mvc?(i.e. injecting the webapi classes into mvc controllers - therefore having a dependency on deployment, but abstracting the api logic and avoiding http)
Please don't let me know if this is stupid question...
It looks like the performance of Spring (Boot) is relatively low compare to other frameworks at "Web Framework Benchmarks" website Web Framework Benchmarks. I looked at the source code (JSON serialization) and could not find anything odd. So I am wondering whether the low performance is caused by Tomcat or by the framework itself?
Slow? It seems to be more or less in the middle of the ranks. Which doesn't seem too bad considering that it is actually a framework. The definition of framework for that set of benchmarks is very liberal, given that it includes benchmarks for a pretty raw Undertow application and another for a raw Servlet.
But given that the Spring benchmark itself is running on Undertow, it wouldn't be Tomcat causing the issue. :)
Looking at the source for the various benchmarks, they are really not comparing like for like. For example, the Spring benchmark project builds a reasonably standard multi-tiered application with ORM entities mapped with JPA and Hibernate, re-usable repository classes, etc.
On the other hand the Wicket application just has a controller with a JDBC call. It even uses a hand-cranked template for generating JSON. You could write a Spring application that way if you wanted to, but nobody would be impressed.
The Undertow benchmark again does little more than query a database with JDBC and spit out a response. It's not surprising that it would be faster than itself with a full stack framework running on it.
Of course, they hopefully get you to think about your priorities in writing an application. Do you want a full stack framework, which lets you write less code, provides various security features, helps you to achieve code re-use, and make your application more testable and maintainable? Or are you willing to sacrifice all that for speed?
I'm going to start the development of an web application system with multiple modules. The system will be built over Springframework, which is the reason why I'm going to use Spring Security. However, I have doubts about the choice of the authentication system.
The idea is to create restufull services that will be consumed by extjs pages (in case of web application) and mobile application.
Please suggest alternative authentication systems (more current). I have minimal expertise in system security and I'm worried about how to protect user credentials while maintaining a high level of response speed.
Even though you have no prior experience with Spring Security, I would still recomend that you use it:
It works very well out of the box with minumum configuration effort.
There is alot of support available because it has become the de facto standard security implementation on many full stack solutions. It is unlikely that you will run into a problem that has not been solved before
Spring Security is very robust and well tested.
out-of-the box integration for almost anything i can think of
finally, spring-security is ment for the springframework. The integration is flawless. Why give up the best part the framework has to offer?
Response speed should not be a criteria when selecting security framwork. Usually repsonse speed is slow due to bad software design or configuration issues. I have never ecountered a system that was slow due to the selected security framework.
I started using Spring Security a few years ago. It took me less than a week to set it up and It has worked properly ever since.
If you need to go for simple authentication then this can easily be achieved mentioning it in Deployment Descriptors , you can specify Authorization Constraint, Security Constraints for Resources, Authentication mechanism and all . pls have a look at this link :
http://docs.oracle.com/javaee/6/tutorial/doc/gkbaa.html
We have a rich web application based in Java & Spring framework which have many functionalities and classes. recently something sparked in my mind that why not we provide modularity to make it even better.
what I mean by modularity is to provide a section inside the web application that the authenticated user can contribute with us using plugins or extensions. exactly like joomla, wordpress and the other cms's around.
I want to separate each part one to another and while a user upload a plugin, that does not break down the entire system and core. also I want to provide the plugin/extension tester in the backend that the system won't accept malicious plugins.
The system should be able to uninstall each plugins and extensions without harming the core as well
How do I make this functionalities, and from where we have to start?
I'd say this depends on a couple things.
One way of achieving this could be having a Modular Framework like either Wicket or Vaadin, use those with OSGi mechanisms like Services provided through blueprint or DS and you should be able to have a fine modular web-application. For example take a look at the Pax-Wicket project it does have a sample application that does exactly this.
Spring mvc is a framework that has been long time out there, it is well documented and proven technology. A lot of web sites are using spring.
Seam is a framework based on jsf - rich faces implementation.
It has a lot of ajax based components.
It uses some heavy stuff like EJB, JPA.
All of this is prone to errors and this framework is so slow (at my computer it is almost impossible do develop something because it is really slow, especially redeploying on jboss)
But is is very good for back office applications.
Does someone have a professional experience with this two frameworks?
Can you recommend the better one ?
Why?
Regards
I use both: Spring-MVC (2.5) and Seam
Because Seam uses Java Server Faces Technology (A server-side based Technology), behind the scenes, It is better designed for small and medium applications. (Each JSF view Tree is stored on Session - You can store on client side, but be aware bandwidth issues). But it has some advantages:
Typically web application uses the following path
view >> controller >> service >> domain
With Seam, you can get
view >> service >> domain
Or even (by using mediator pattern provided by Seam Framework)
No controller, No service
view >> domain
Besides that,
JSF 2 supports JSR 303 - Bean Validation
You can use Wicket instead of JSF if you want
Conversation and Business process management support
Use can use Spring DI if you want
Spring-MVC
It has a powerful web-Tier infrastructure
Handler Mapping (It chooses which Controller should handle the request)
View resolver (It chooses which View should render the response)
It can be used for large applications
Powerful data-binding
Spring 3.0 supports Annotation-based Controller (JSR 303 - Bean Validation, coming soon)
But i still not use Spring 3.0 because
By using (and extending when needed) MultiActionController, i can get convention over configuration without no xml settings to define your Controller (You just need to set up your MultiActionController as #Component)
SimpleFormController provides similar behavior found in Spring 3.0 annotation based controller
...
About The learning path, i think both are similar.
I have worked professionally with Seam and it is a killer framework. It really boosts up your productivity. You can use POJOs instead of EJBs, if you think EJBs are slowing you down. About the deployment, just consider deploying to Tomcat instead of JBoss. On my machine redeployment in Tomcat is done in a couple of seconds. But I still haven't used Spring MVC to compare them.
We have been using Seam for a very large site using POJOS and communicated with web services or Hibernate deployed on Tomcat. We have found that the back button support does not work well or is prone to being specific to implementation patterns. Additionally, there is a tendency for sessions to grow very large if using server side state. Attempts to reduce the session size impact back button support or iframe usage due to reduce number of view states stored in session. More or less, our issue have all been performance related. The tomcat requires more memory and supports less users when compared to a struts 1.2 or spring mvc. We are using around 50 tomcats to support our userbase.
I have used both SEAM and Spring MVC for a few months.
I prefer Spring MVC to SEAM. BTW I noticed JBoss halted the SEAM3 development.
I found a interesting article about comparison of SEAM and Spring MVC.
The link is
http://java.dzone.com/articles/why-java-ee-lost-and-spring?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+%28Javalobby+%2F+Java+Zone%29&utm_content=Google+Reader
Thanks
I have used both Seam 3 and Spring 3 frameworks.While Seam 3 is easier to code and has a lot of features supporting session management and transaction management ,the performance is slow.Spring is much faster.