I need to design a simple web app which has only 3 pages, namely log in, a page to enter new data and view previously entered data, and one to manage what the users entered. There are a few more constraints, but that's the general idea.
I was wondering what you think of the following design:
one single (!) static html page, with a little bit jquery render and communication logic
a RESTful web service (Jersey, for example), which would accept data send by jquery and process it (java-json conversion would be ensured using jackson)
a java model persisted in a database
basically, the HTML + CSS would be the view, jquery + jersey my controler, and then the java model. Everything would be done using good programming principles, etc.
From what I understand, this would allow to very quickly develop my stuff, have a very modular design, be highly compatible (regular DB-java-jquery-html), be easily able to scale out if needed, and have blazingly fast response times.
Since I'm not out of college yet, and I'm on my own to do this (thus have no one to talk about on this design) I'm not sure how good my design is. Namely, I wonder about the following questions:
Are there any flaws I am overseeing?
Am I over-engineering/complicating this?
Is there any security flaw I didn't see (from the design, not from the implementation)
Thanks;
P.
Your design is pretty good. You can have a look at my proof of concept that works exactly as you've design, except that it uses jqGrid to handle all CRUD operations and has a mocked DAO.
Security is not an issue, HTML and JavaScript can be served anonymously, but all REST operations need to be secured. You have to login first to obtain JSESSIONID cookie and pass it with every AJAX call (this should actually happen automatically).
This is a good design. In fact, you can just release your API this way, the way Facebook, Twitter do. All you need to do is to explain what your RESTful service expects and what returns. And anyone can develop an app over it. So, this is good part. Lets answer your specific questions:
Are there any flaws I am overseeing?
No. In fact, these are simple CRUD operation, pretty standard stuff. You could get the same done quickly (called fast flash to bang), if you use a framework (Wicket, Play!, Struts-2) that handles many things for you. What you are doing is developing components by your own.
Am I over-engineering/complicating this?
Yeah, a little. If it's just a college project, and you're in control. I would suggest just go with a web-framework that will be the fastest thing, probably. They might hide a lot of implementation details that you may have to do with your current design.
Is there any security flaw I didn't see.
Nope. As long as you are taking care of authentication and authorization on URLs that need it, you are safe. You could consider HTTPS, but that's too much.
Related
I've been reading about Jodd(java) framework and it looks interesting to me. But I see that it seems to be jsp/servlet based. Can you develop strictly html/html5 dynamic website without jsps with it?
Absolutely. As you can see, in Jodd Madvoc you have this concept of Result : each (java) action returns it. Results are the one that defines how you are going to render the page. By default, there are JSP results, as this is a standard, right; but nothing stops you to simply have a i.e. Freemarker result or to use any other template engine. People are doing this often. Moreover, Results are made to be configured. See: http://jodd.org/doc/madvoc/results.html
Result does not need only to return HTML content. There is a JsonResult for example, or RawResult that can return a JSON or any string.
If you want REST-ish interface that only results with JSONs, you can do that as well, checkout: http://jodd.org/doc/madvoc/rest.html
Madvoc should be configurable enough to fit your needs. Just don't think of it as a 'solution-in-a-box', but a real framework, that you need to dig just a little, but you will find what you need :)
You can develop strictly html/html5 dynamic Websites without JSPs for sure, there are many ways to do it, but in my personal opinion, I believe that you can use AngularJS for your front-end development (HTML5/CSS3). This framework will allow you to implement all your client side without minor issues. It is based on HTML5, so no JSP files will be required. If you are used to MVC or MVVM, well this framework will allow you to work with any of these two approaches.
Dynamic Web Application? Need to show data from a database or store records? No problem, Angular supports AJAX calls to REST Web Services which you can implement with the programming language you feel more comfortable. If it is Java, then you can go for some REST Web Services using Jersey.
Hope this information is useful for you.
Happy coding.
REST webservices imply the server-side is stateless (for the most part) and urls correspond to resources and HTTP GET/POST/DELETE/PUT methods correspond to operations on those resources.
I am planning to work on a JSON services layer that is dependent on server-side state, having urls that correspond to resources and having urls like /add /update /delete corresponding to different operations and all of those urls using HTTP POST.
What is the right terminology for this? Should this be called JSON
web services? Is there any specific term for this?
It looks like Jersey+JAX-RS would be very useful for this purpose. Is it ok?
Would it make sense to use Struts for this kind of application?
JSON is a file format which your rest service may (or may not) use to send its answers. If you use this format to communicate with your webservice, you cann say that your service is a JSON web service.
Indeed, Jersey is a good JAX-RS implementation. However it is not the only one.
If you need a webapp to interact with the webservice you can use Struts. However, you can use any other tool (included some more recent technology, struts is really old) for the front-end of your system.
Well, it's not REST. However trying to defeat that tide of general misunderstanding just isn't going to happen.
What you are describing is actually what most of the world views as REST and therefor should be mostly OK with just calling it as such.
In the presence of a true Restifarian, you will get some push-back because they will be correct - however, there isn't really much need to add a tremendous amount of confusion to your daily life as the distinctions (and the MASSIVE benefits they afford...) are largely lost on anyone you work with.
(1) is accurate enough, or simply rest. (2) is redundant but it is a good framework for the technology. (3) I would say no, but noticing when this question was asked, I'm sure you already decided.
I have what I think might be a strange question to ask.
Recently I was playing with some java web frameworks (jsf with primefaces) and I noticed that it's quite good at handling form data or when you play along with the jsf components. I also did a project using grails and again it was useful for form data.
But the moment you want to do something which requires a little deviation; then I found myself doing weird things (examples are tag clouds with large strength values using primefaces and single page webapp forms with grails).
This resulted in some very messy html+javascript code for my grails things(which I blame on my inexperience with javascript). This was done because I was using expression language (grails in this case) to populate some of the javascript. The worst part was that I had a bunch of custom javascript code inline with my server pages (I could of refactored a little out but I think one would still have alot of javascript calls inside a single page).
So now to the question(s) :)
[main question] Are there any resources that demonstrates how to design or at least implement maintainable javascript with server pages (gsp, xhtml, etc) ?
The reason is that I find that there are some neat javascript frameworks, but using them with server pages seems a bit unnatural if one takes into account the expression languages for server side frameworks? Unless it's normal to do this type of thing :) ?
Are there appropriate frameworks for Single page webapps using java?
My current answer is that GWT, Vaadin (based off GWT) and perhaps JavaFX qualify. Maybe ZK, Flex and (Grails/Roo + Flex/GWT) also qualify as well?
Are java web frameworks still useful for presentation layers?
My current answer is that they might be when you are dealing with portal type webapps or Web 1.0 apps for lack of a better word. The other case is that they could be when you use alot of role based security and you want to filter things out based on roles, but even that has counter arguments.
My other answer to this is that it might be better to use a java server to provide your web services and then rely on something else to do the front end?
This might be OP, but for single page apps, it's easier to serve up data from the server via JSON(P)/XML/whatever and then use things like Backbone to process and modify the view(s) accordingly. That way, the server can use REST/SOAP/websockets/whatever, and the browser app becomes a full-fledged app.
I haven't actually done this, so don't quote me, but I imagine that it should make sense.
I was wondering if someone who was experienced in both technologies could give an objective comparison between the two, assuming you were building a complex web application that would be both very rich in on the server and in the browser.
One problem with the older paradigm, for me, is testability of the Spring MVC layer. I find that there's a lot of bugs that can creep into your application due to untestable annotations. This model also slows development cycles because you have to restart the server to make changes to the annotations/controller code... which is something I personally find very annoying.
I also don't want to deal with the complexity of javascript. Working with and testing an application all in Java sounds appealing to me. I don't really want to master another language, and learn all of its quirks, weird design decisions, idiosyncracies and the full history of browser incompatibilities.
So for a complex application, would GWT offer a superior approach? Are there any serious limitations to this approach over Spring MVC, which would probably be more flexible although harder to work with? Are there any gotchas and road blocks that are common for building complex applications?
I would really appreciate a comparison between the two. Please keep in mind that I have no experience with GWT, but about 10+ years experience with Spring. Thank you!
The truth is that also GWT has a learning curve and also at least at the time I looked at it, two years ago, you're not doing much with the basic controls, you need external libraries and that means more learning.
After trying to learn GWT without much success, I opted for a webservice plus either jQuery or ExtJS, which also gives a very clean separation of the roles. I sat down and learnt JavaScript, it wasn't easy but it was immensely more fun than using GWT.
As for browser compatibility, once you use a modern library, you'll have very few of them. My code works in all browsers without too many problems, including IE 6. Also when I am too busy, I write the services only and outsource the JavaScript interface part, which allows increased productivity.
Anyway, this is fairly subjective, another person fluent with GWT, can have an opposite point of view of mine. I will anyway reject the following reasons:
ease of debugging. Not true anymore: it's very easy to debug JavaScript with FireBug, plus there won't be any business logic in JavaScript, only services call and display.
browser compatibility. There are very few quirks to remember, the most common one is that IE doesn't accept trailing commas in lists, which is anyway not in the standard, but Firefox tolerates them. Any modern JavaScript library will take care of compatibility for you.
Speed. To start with I will state that JavaScript is very fast for any reasonable computation within the browser. What is slower is DOM manipulation and of course anything involving the network, like AJAX calls. Your page will perform just right if you don't do design mistakes, like stuffing too many things or other problems that can arise when adding many elements directly to the DOM, instead of building your structure and then attaching it all at once.
As far as I can think now, the only valid reason is, I already know Java, I don't want to study another language.
As for your comment on Spring MVC. I am using Spring MVC and I don't feel the pain of restarting the server. The whole point of Spring is that everything should be easy to work with outside the container! In the Spring controllers I've very minimal code that just call the underlying services. What I need to unit test well are the services.
The controllers have very few code to test, I could just call them and test them within JUnit, but, at least for now, my approach is having a simple external test done through a web page with jQuery calls that check their response (it's not unit test, it's an integration test, but I feel there is a very little value to unit test a controller, if it's written properly).
I am using GWT for more than a year now in a complex project (200 KLOC for the whole project), and I recommend you to give GWT a try.
In my opinion GWT is quite easy to learn, there are really good tutorials about how one should use this technology.
The advantage of using GWT is that one can build nice, fast, maintainable web apps, without knowing very little about browsers or javascript. You can also debug your client side code with a Java debugger and in complex apps this is huge.
Although GWT offers the possibility to properly unit test the client side code, this requires a good understanding of GWT's MVP paradigm and careful planning. If you mess up your code (which is not that hard, because GWT gives you total freedom) then you are going to end up losing this feature, but this is your fault, not GWT's.
It took me a couple of months to learn Spring well enough to create fairly basice MVC apps. It took me about a month to master GWT. (It could be that it was easier because I had already worked with Android for three years and it works similar. It even has the exact same unobvious solutions to some of its problems.) So for me, GWT was definitely much easier to learn than Spring.
We are green fielding a mobile web app against an existing Java web app --the database of that app, at least.
We are only using the database of the original app because the original app is built on a custom ORM solution and Struts 1.1 that is showing its age. So this is going to be a bit of a proof of concept for what can be done with modern tools.
We have decided to utilize JQuery mobile on the front end to leverage device cross compatibility. On the back end we are going to go with JPA for now...maybe moving to Hibernate down the road. But we'd like to expose our model with a RESTful service to kill two birds with one stone (the original app interfaces with a number of third party's that we'd like to give access over a simple REST interface that happens to have a lot of overlap, data wise, with the mobile module.)
So, the question is which controller layer will best tie the JQuery mobile front end with the RESTful back end?
We'd like a controller framework that:
Is not too intrusive. i.e. we don't have to lock ourselves into that particular implementation because of hard set dependencies spread all over the code.
Is annotation based or heavy on convention over config. or both so we are not writing reams of XML glue
Doesn't bring along cruft that we won't be using... i.e. it sticks to the controller layer as much as possible
Can handle REST from one end and AJAX from the other without too much trouble
The larger the community the better
The simpler to get up an running without compromising any of the other points, the better.
We've begun exploring Struts2, SpringMVC, Stripes, Play! etc. but I am hoping for some sage advice from the erudite SO community to help narrow the field.
If you need anything clarified, I will be happy to do that.
It seems to me that you're searching in the wrong direction.
Your Java App is producing JSON/XML through REST web services.
Your jQuery client is consuming those web services to publish them to an interface
You seem to search a controller server side. Why? Producing REST web services is not the only goal of a REST server?
Take a look at BackboneJS — it's not the only one in the category, but the one I know better — it's a client-side controller. It fits perfectly with jQuery and allows to access REST resources with HTTP verb — GET, PUT, DELETE, POST — in a compact and generic way.
If you choose so, I'll help you further.