Play framework for Java - a radical rethink of Java web app development?
playframework.org
playframework.org
The example app was very useful. Including some real world jquery ajax functionality was a big bonus and a great way to compare functionality with other frameworks. (render methods and routing specifically).
But with Scala support coming in Play 1.1, I'm officially excited.
Maybe you should not be building web applications with Java or C# or <insert language of choice>.
Maybe you should be building web services with these languages and using AJAX, a client side toolkit, Javscript, HTML and CSS to build a UI that communicates with said services.
Maybe this decouples your UI implementation from your business logic implementation so you can go mobile, IVR, Mind Jacking, without having to build the back end again.
Maybe server side templating was wrong and a CMS is your best choice for static templating. Given that assembling templates during run-time as opposed to build time seems to be a waste of resources. A CMS can deliver already templated, flat HTML files, to the web server during build time. As well Ajax is your best bet for delivering dynamic information.
It sure separates your concerns quite nicely, while allowing each developer to work in their domain of expertise.
Just a thought.
I've seen companies falling at the other extreme ... making the interface "totally" decoupled, so that they could replace the UI anytime they wanted. That's why monstrosities like XSLT appeared.
But I haven't seen any example of a good application yet that does this successfully, because whether you like it or not, the web UI will require backend logic that your iPhone app does not, and vice-versa. And you'll either create a common denominator, or two different branches.
Also, if your iPhone app is so similar, maybe it shouldn't be an app in the first place, but an iPhone-optimized website. It's Apple's fault if they aren't making the integration between websites and the iPhone easier.
Don't get me wrong, web services have their place, but make no mistake ... a website that assembles the page from web services is a lot trickier to scale (assuming you're the one providing those services).
The fact remains that human preference is for tailored UI and not until AJAX took hold was the desktops dominance as a platform threatened. Time and time again, tailored UI's are preferred. It is the reason for Apple's return to stardom as well as the rise of web 2.0.
Developers try to fight this mentality to work in their boxed solution and I understand it, but you have to clearly refute evidence to the contrary to believe that the user prefers application developed in this manner.
So If that is the case why not design an architecture that accounts for this reality and makes peoples jobs whose responsibility it is to assist the user instead of enforcing a developers domain on them.
As well, I do not agree that different UI's require different back end logic they require different work-flow logic and work-flow is not reusable. If they require different back end logic for say getCustomer, addCustomer, validateAddress then there is core architectural flaw in the solution. How a customer is then displayed is a problem for the UI e.g. Do I show all info in one screen do I show pivots to make room for more screen real-state.
It is not Apples fault, that is faulty logic, Apple is giving their users what they want and their last quarter clearly reflects that.
Web sites that rely on web services are not tricky to scale look at my document on amazon I referenced. It is essential to scaling. Google, Amazon et. al. are doing this precisely for that reason scalability and to not be locked into back-end or front end technologies. Not to mention you are distributing all work-flow and dynamic templating to the clients, which in practice has a large impact on resource utilization.
I know that they are using lots of web services, but the assembly is still mostly done on their servers (not in the browser), and you're talking about something else (or have I understood you wrong?).
I've seen a talk from an Amazon fellow. They are using web services for parallel processing ... their frontend servers are sending asynchronous requests to those services, which is a huge win.
But in a browser, for an Ajax frontend that happens to periodically request updates, one thing that happens is that the number of requests made from a single client is a lot larger. Surely it doesn't reload all the static files, but those are non-issues even for a reasonable high-traffic website ... just put something like Varnish to serve them and make sure they have expiration headers in the future.
My company did consultancy work in matters of scalability for http://www.erepublik.com/ and after we placed a Varnish in front (that also functions as a load-balancer for Apache servers) it could handle thousands of concurrent requests to static files. And their biggest problem was definitely not the load on their Apache servers (it was MySql).
And this is mostly what I was thinking about.
Most people are already doing it.
I think there are two important points here. First, that is at best a beta level proposal, and I wouldn't bet the well being of my family on it. I'll be very happy when it stabilizes, but I'd stick to outputting plain html for the engines.
Second, this sounds far more complicated than simply outputting html from your web app. This thread is about decoupling UI from the backend for a clean design. Using this approach is far less clean than outputting the html directly.
It would be just as valid to argue that a fire-walled web environment is more complicated than one that is not fire-walled, while true it ignores a host of realities, but it is accepted that the advantages of security outweigh the complexity of a firewall.
What I am saying is that much like a firewall, it is a task of configuration and not custom development and therefore given its ease of implementation, the advantages outweigh the marginal complexity (I am arguing that it is marginal) that it brings.
As well, I am arguing that much like a firewall ejecting this problem domain out of the application, creates a simpler solution. You can implement access security in your application, but it is commonly accepted that rolling your own is a bad idea. The advantages of dynamic user applications are clear and I am arguing that those advantage clearly outweigh the need for this simple solution, if SEO is even a problem domain of your application, it is not for some.
Please, leave this fantasy to me then, because I like real money :)
And that's with LAN based WS calls. I can't imaging doing that over the internet. You have a page that has 20 independent dynamic blocks, you really want to make 20 HTTP request/response calls over a 60+ ms latency connection? You really want your server cluster to have to handle 20 connections instead of one?
Maybe for a simple and/or low traffic site, but for a moderately complex website/webapp, you're better off serving out a single page.
As well another common mistake I see is services calling services to build a composite service. If at all possible services should be the facade into the system with logic wrapped up in a jar, DLL, etc. All services if possible should rely on said library and not rely on loosely coupled services for composting, inter-system communication is different than disparate system communication.
In my experience, if you architect your server-side components well, if/when you want to expose something as a web service you can prop up a web service that's basically just a thin wrapper around the relevant backend component(s). It avoids the "premature optimization" of building everything as a bunch of micro and aggregate services that you may or may not actually make use of in the future.
For building a complex web page for a normal browser, (assuming you're using Java on the backend) a JSP built using various local component objects is almost certainly the fastest performance solution, both server side performance and client side perceived performance.
For building other interfaces (iPhone app, dashboard widget, etc...), until you build them you're unlikely to know exactly what calls will make the most sense for them. When you do, just build those calls as wrappers to your existing components. Very fast to do. I've done it many times against Seam and ATG eCommerce applications.
With good frameworks most JSPs are very close to normal HTML and we actually usually have: designers/UX folks who provide PS docs/images/etc..., front end devs (JSP/JS/AJAX impl folks) who take those and make real working JSP pages out of them, and back-end devs who write the Java backing components.
You seem to be expecting these new developers who are just learning HTML to know how to build complex pages using aggregate web service calls via JS, based on a non-standard in-house system.
Even if you don't have separate designers and front-end devs, and I've worked at several places like that, helping HTML designers figure out JSP using a good framework (ATG, JSF) really isn't that bad, it's just a few new tags which are really well documented all over the web.
While I am a Java dev/arch, my "view point" is typically that of a lead architect, team lead, or project lead, so making sure people can get stuff done, regardless of what role they're in is key.
Do you have any live examples of websites built using your proposed method?
As well, I am not proposing anything any more non standard than say JSP or Struts and Tiles. Their are plenty of AJAX frameworks that provide all of the bolts to erect this style of system without building and in-house system. Further, JSP is only standard for web development it does not take into account the variety of UI possibilities and that is the point of the matter. The UI much like the database is only a portion of an overall system. Just as you would not write you data-storage in your logic tier you should not be coupling the UI tier to your business logic.
There are plenty of sites that use this development methodology. Pick almost any mature "Web 2.0" site and they will be somewhere along in this evolution. Google, Amazon, Yahoo et. al.
I apologize in advance for being vague, but I would prefer to not loose my anonymity on this site and referencing my work would do so.
Sorry I missed hitting on this one. I do not expect a designer to be doing service calls that is the point. You can write a JavaScript controller that grabs reference to any UI components that it needs, you do not write JavaScript in the HTML, the designer is then working in pure HTML CSS. The JavaScript developer is the one orchestrating the work-flow logic in a code-behind manner. Each person has their domain and once a developer feels comfortable they can graduate to the next domain. Just as I don't expect a HTML designer to have to know Java constructs I don't expect a Objective-C developer to know HTML constructs. It's not about constraining people, it's about re-usability of reusable components and isolating non-reusable components.
I wanted to touch on this real quick, The point of letting the client deal with it's concern, is that you can prototype and user acceptance test you application before you ever write a service. Then you only have to build what you need to support your UI and what ever batch processing you need. It is a far more agile process. Not only do you have a working UI but you have a service inventory of functionality that need to be implemented to support you UI. From there you can build out your service tier and if you so chose look at the next likely UI and do some due diligence to see if you are going to need more micro services to support you next endeavor. You may not chose to build them but you can at least architect the solution with the next endeavor in mind.
http://blog.jeffhaynie.us/service-oriented-ui-architecture-i...
http://www.eweek.com/c/a/Application-Development/How-to-Arch...
This is actually how Jekyll works, which is what I use for my blog. It's pretty awesome, actually. My pages load basically instantly, and Disqus plus some other Ajaxy stuff works for what absolutly has to be dynamic.
I haven't programmed JS in a while...
Say you have a page that shows basically the same content for everybody, but has a handful of user-specific elements in there. In a typical MVC setup you'll a controller as the gatekeeper with overall knowledge of the request, it will assemble the data needed for the request and pass it to the view. The view may be one template, or it may be comprised of many, including a layout and several sub-templates. In order to fetch all the content efficiently, you want to know everything up front, so there is no n+1 problem or similar. This works pretty well for the gross content of the page, but not nearly so well for the minutiae. Whether a specific piece of data is often not reasonably known until deep inside a nested template.
So you have a conundrum, do you make assumptions about or replicate the view logic in your controller in order to efficiently load everything? Or do you suffer the performance penalties of looking things up in an ad-hoc basis within the templates at the point their needed?
The answer is simple, you leverage the client. The controller loads the gross content and the templates puts placeholder values for all the other data (classes and maybe some custom attributes). Then you have a javascript library that scrapes up the references to the needed data and requests it directly from the server. This effectively converts your page into a static page that can be served to everybody, cached to your heart's content, etc, and it offloads a good chunk of your processing to client machines which of course by definition scale in constant time.
I've done this in Rails using resources and json, and the performance and scalability benefits are amazing. You just need to know how to write good Javascript and be aware of the security concerns. The only thing that's need to make this uber-efficient in Rails is some kind of request bundling so that if you have more than 2 or 3 resource types needed you don't need to send a separate request for each one.
To all the doubters, you need to open your mind about this. I'm guessing most of you just don't like Javascript, to which I simply direct you to Douglas Crockford.
Yes and I am somewhat regretting stiring this up, but I understand it, I was on that side of the fence for a long time, until I was dragged over to the other side.
The other posters are being very pragmatic, and that is a good trait to have. The problem is that we are creatures of habit and when we find something that works no matter how efficient we are hesitant to discard it.
I will tell you that when rich internet applications first came into popular use, I was one of the biggest detractors for the exact reasons that I am defending it's use today.
My initial reaction was that we have just added more convolution to the mix of technology soup that ASP, JSP, PHP have become. Now, not only does a developer need to know a server model but they have to understand a client model.
I thought to myself this is the worst of both worlds. It was not until someone more visionary than I, explained to me my wrong headed thinking. In that you have to abandon the server model for the picture of rich internet applications to become clear.
In the end we have had years of indoctrination to a certain model and it is hard to reason outside of that known reality. I was one of the most guilty of doing this, given that I have been doing this since the beginning.
"To all the doubters, you need to open your mind about this. I'm guessing most of you just don't like JavaScript"
This is a huge concern that I see time and time again, but what is funny is that this liberates the technology selection for so many other systems. No longer do I have to worry about trade-offs like Rails is faster to market but Java has a bigger library. With this form of architecture those decision decoupled. Services can be implemented in whatever language best fits the problem domain. You can use one or you can use many, it is a choice of each development house. Further, you can chose to third party provide whole sections of your application. This works very well at Google some systems are provided in python, some in Java and yet other are implemented in that team of choices language.
As for JavaScript as of now this is a limiting reality. Many of the browsers are working on alternative languages and there are converter that will allow you to write Ruby or Python or whatever and have it converted into JavaScript. But the reality is, yes web client programming is done in JavaScript. For me, it is not a big deal, as I find that UI development is best supported by a rapid prototyping language and JavaScript fits the bill. I am continually amazed at the flexibility of the language. Conversely, I prefer strong typed languages for services.
A difference is that the routes, model, controller and template/renderer are in separate directories. It's a bit awkward for the simple project of the one in the video, but essential for more complicated projects.
It even includes a captcha generator, and their examples seem to be of real (though very simple) applications - as opposed to toy academic ones. I get the feeling that its developers are very familiar with the real needs and problems of actual web development.
It almost makes me want to get into web development! The only thing is that combining HTML, Groovy templating, Javascript and JQuery looks a little complex - but they're probably very straightforward for common tasks.
Our favorite contractors and outsourcing providers also have (comparatively speaking) deep skills in Java and the related stacks. Some of them have forgotten more than I ever want to know about, e.g., serializing Java beans.
When I worked at ITA Software which writes much of their stuff in Lisp (not the web stuff though), there was often worry that it meant new programmers would have to learn the language and so wouldn't be productive at first. But learning the code base takes a lot longer than learning the language, at least enough of the language to get significant stuff done.
If you have 10 years worth of legacy code written by 12,000 employees, I assume you're in the same boat.
If you have developers that know other JVM languages, or who can learn, then I would say there is no advantage because any language on the JVM can refer to object built in any other. This is why things like Jython, JRuby, Rhino, and Clojure are cool.
Groovy is used cause it has closures (java doesn't) and is simpler and easier than Scala.
mvn:create can bring up an interface that's very smilar to CPAN's shell. What needs to be done is a shell that allows functionality such as "search /amazon/" or "search guice, jersey" or "info google-collections". Scala would be a great choice to make sort of a "REPL" shell :-)
Until mine is ready, you can try mvnrepository.com. The reason that I'm building my own is because mvnrepository.com is often down, slow, and is not very easy to use. But it's there until I'm finished with mine!
http://docs.codehaus.org/display/M2ECLIPSE/Quick+Search
Here's a big list of mavenized projects:
> "Play is designed to operate in a ‘share nothing’ architecture. The idea is to keep the application completely stateless. By doing this you will allow your application to run on as many server nodes as needed at the same time.
>What are the common traps you should avoid to keep the model stateless? Do not store any object on the Java heap for multiple requests"
If that's all they're talking about when they say "stateless", that's no different than a lot of other "stateless" MVC frameworks like Pylons, Django, Rails, etc.
Do you write/read all that into the db/memcached for each request?
Of course, if you keep that state in memory then you are fucked when you need more than one web app server to handle the load.
I know memcached is very fast. However it's at least an order of magnitude, or more, slower than in memory lookups. Given how simple sticky sessions are I guess I'm not sure why you'd want to incur the overhead of re-buildling your state via external network calls and object serialization/marshalling/etc... for every request, and doing it all backwards at the end of every request.
I'd like to see the Play server support fcgi rather than having it deployed behind a webserver acting as a proxy for load balanced deployment.
They are faster than forking processes though, but Java applications (because they share state between threads) are less scalable.
But I am not convinced with 'on the fly' compilation because most editors already do a better job there and refreshing the web page to look for compilation errors does not look productive.
I'll have to dive deeper into play to see how much more I would have to do in the Controller part to prepare the output for the template...
With play, you can just write:
Article article = Article.findById(id); User user = User.getConnected(); render(article, user);
And retrieve objects from their Java local name in the template. That saves a lot of useless lines of code...
Otherwise, I'd still either pick JRuby on Rails or go ugly early with idiomatic java.
update: Before do stupid down-voting: JNI sucks. It was not designed for today's high-loaded applications. JVM sucks for IO, even with its NIO2. It's not portable any more. There is NO JVM for ARM-based platforms. Even Python is more portable. Java is the corporate platform for internal business-related projects (same as .NET is). It is not an universal or even portable platform. The game is over.
Groovy runs on JVM, Wicket on Wings exists, I believe. What are other Java options?