6 ms·

"The Play framework makes it easier to build Web applications with Java" Maybe you should not be building web applications with Java or C# or <insert language

by kls 17y ago

"The Play framework makes it easier to build Web applications with Java" 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.

dasil003 17y ago
YES! You seem to have gotten a lot of disagreement here, but I know exactly what you're talking about. Someone suggested that this would be bad for scalability, but in fact I was pushed in this direction precisely for scalability purposes. Consider this: 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.
- kls 17y ago
  "YES! You seem to have gotten a lot of disagreement here" 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.
bad_user 17y ago
A web service isn't a web application?
- kls 17y ago
  Neither is an IPhone app, but I can guarantee you that most of the logic I use for my "Web Application" will be reused by my IPhone application. With the exception of my templating, work-flow and UI specific logic, so it begs the question why am I implementing my templating, workflow UI specific logic, in my "Web Application" (it's not reusable). Unless it really is a web UI to my enterprise application in which my UI should be worried about its concern? I see so many new companies fall into this trap and then have to do major rewrites when they realize they have boxed themselves into a "Web Application"
  - bad_user 17y ago
    Because this is a premature optimization. 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).
    - kls 17y ago
      No XSLT was an attempt to make the UI generic, either you accept that UI are a custom tailored to be optimized for the platform or you accept the dumb terminal philosophy where you try to generalize the UI to adapt to all platforms. 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.
modoc 17y ago
In my experience breaking everything down into a bunch of uncoupled services, ala SOA, adds a significant amount of performance overhead making all these web service calls to build up a semi-complex page. Performing all the logic within a single process/JVM is MUCH more efficient. 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.
- kls 17y ago
  No one said that they have to be micro services. One should provide composite services that provide all of the data for a work-flow. Then use a pub-sub event based model to notify the UI of available data. This way components stay loosely coupled and are only listening for an event that injects the relevant data that they need. This results in a single call to a composite service yet the micro services are available should a different UI need a more microscopic flow or data load (for example, limited memory on a mobile device). 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.
  - modoc 17y ago
    Building/maintaining that sounds way more complex than writing a JSP. 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.
greentree 17y ago
The "way we've always done it" in my brain does not like the thought of putting all the client stuff in, well, the client. I'd like to hear more about this style of development. Do you have examples of this being done, postmortems, blogs espousing this, more info, etc?
- kls 17y ago
  http://highscalability.com/amazon-architecture http://highscalability.com/amazon-architecture Being a large company Amazon is in different stages of a transition to this form of architecture, but for the most part most all of the large companies are moving towards it IBM is embracing it as a UI development philosophy. Google pioneered it, Yahoo is well on it's way. http://blog.jeffhaynie.us/service-oriented-ui-architecture-in-the-world-of-web-desktop-and-mobile-applications.html http://blog.jeffhaynie.us/service-oriented-ui-architecture-i...
- kls 17y ago
  This has allot of links into the concepts behind the architecture: http://www.it-eye.nl/weblog/2008/09/05/client-server-20/ http://www.it-eye.nl/weblog/2008/09/05/client-server-20/
- kls 17y ago
  One more to add the the list: http://www.eweek.com/c/a/Application-Development/How-to-Architect-NextGeneration-Web-Applications/ http://www.eweek.com/c/a/Application-Development/How-to-Arch...
steveklabnik 17y ago
> A CMS can deliver already templated, flat HTML files, to the web server during build time. 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.
- kls 17y ago
  Thanks for the tip, I am always looking for a good CMS that does not try to be yet another app server.
volida 17y ago
Maybe you should just use what makes the job best for you?
- kls 17y ago
  That is a developer mindset and flawed at it's core. You should use what is easiest for the person that relies on your work to use.
simonw 17y ago
The Web I fell in love with is the Web of URLs that respond to a GET request with a page full of HTML.
- kls 17y ago
  I liked it when we figured our how to POST to a C application and then Perl came along and ruined the party. I had to learn a new language just to keep doing CGI. After that, no one but yahoo would hire a CGI C developer.
hernan7 17y ago
Hi, which client-side toolkits would you recommend? I haven't programmed JS in a while...
- kls 17y ago
  The majority prefer JQuery, I will try to not impose my bias on you but to answer you question as best I can, I prefer Dojo. Out off all of them, I would say try both of these and see which one is for you. Given my preference for a decoupled UI, Dojo provides the complete box, but JQuery is far easier to learn. Their is an elegance to both so I urge you to do the due diligence and at least spend a week working with both before you make your decision.
  - hernan7 17y ago
    Thanks, will do.

by kls 17y ago

dasil003 17y ago

YES! You seem to have gotten a lot of disagreement here, but I know exactly what you're talking about. Someone suggested that this would be bad for scalability, but in fact I was pushed in this direction precisely for scalability purposes. Consider this: 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.

kls 17y ago
"YES! You seem to have gotten a lot of disagreement here" 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.

bad_user 17y ago

A web service isn't a web application?

kls 17y ago
Neither is an IPhone app, but I can guarantee you that most of the logic I use for my "Web Application" will be reused by my IPhone application. With the exception of my templating, work-flow and UI specific logic, so it begs the question why am I implementing my templating, workflow UI specific logic, in my "Web Application" (it's not reusable). Unless it really is a web UI to my enterprise application in which my UI should be worried about its concern? I see so many new companies fall into this trap and then have to do major rewrites when they realize they have boxed themselves into a "Web Application"
- bad_user 17y ago
  Because this is a premature optimization. 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).
  - kls 17y ago
    No XSLT was an attempt to make the UI generic, either you accept that UI are a custom tailored to be optimized for the platform or you accept the dumb terminal philosophy where you try to generalize the UI to adapt to all platforms. 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.

modoc 17y ago

In my experience breaking everything down into a bunch of uncoupled services, ala SOA, adds a significant amount of performance overhead making all these web service calls to build up a semi-complex page. Performing all the logic within a single process/JVM is MUCH more efficient. 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.

kls 17y ago
No one said that they have to be micro services. One should provide composite services that provide all of the data for a work-flow. Then use a pub-sub event based model to notify the UI of available data. This way components stay loosely coupled and are only listening for an event that injects the relevant data that they need. This results in a single call to a composite service yet the micro services are available should a different UI need a more microscopic flow or data load (for example, limited memory on a mobile device). 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.
- modoc 17y ago
  Building/maintaining that sounds way more complex than writing a JSP. 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.

greentree 17y ago

The "way we've always done it" in my brain does not like the thought of putting all the client stuff in, well, the client. I'd like to hear more about this style of development. Do you have examples of this being done, postmortems, blogs espousing this, more info, etc?

kls 17y ago
http://highscalability.com/amazon-architecture http://highscalability.com/amazon-architecture Being a large company Amazon is in different stages of a transition to this form of architecture, but for the most part most all of the large companies are moving towards it IBM is embracing it as a UI development philosophy. Google pioneered it, Yahoo is well on it's way. http://blog.jeffhaynie.us/service-oriented-ui-architecture-in-the-world-of-web-desktop-and-mobile-applications.html http://blog.jeffhaynie.us/service-oriented-ui-architecture-i...
kls 17y ago
This has allot of links into the concepts behind the architecture: http://www.it-eye.nl/weblog/2008/09/05/client-server-20/ http://www.it-eye.nl/weblog/2008/09/05/client-server-20/
kls 17y ago
One more to add the the list: http://www.eweek.com/c/a/Application-Development/How-to-Architect-NextGeneration-Web-Applications/ http://www.eweek.com/c/a/Application-Development/How-to-Arch...

steveklabnik 17y ago

> A CMS can deliver already templated, flat HTML files, to the web server during build time. 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.

kls 17y ago
Thanks for the tip, I am always looking for a good CMS that does not try to be yet another app server.

volida 17y ago

Maybe you should just use what makes the job best for you?

kls 17y ago
That is a developer mindset and flawed at it's core. You should use what is easiest for the person that relies on your work to use.

simonw 17y ago

The Web I fell in love with is the Web of URLs that respond to a GET request with a page full of HTML.

kls 17y ago
I liked it when we figured our how to POST to a C application and then Perl came along and ruined the party. I had to learn a new language just to keep doing CGI. After that, no one but yahoo would hire a CGI C developer.

hernan7 17y ago

Hi, which client-side toolkits would you recommend? I haven't programmed JS in a while...

kls 17y ago
The majority prefer JQuery, I will try to not impose my bias on you but to answer you question as best I can, I prefer Dojo. Out off all of them, I would say try both of these and see which one is for you. Given my preference for a decoupled UI, Dojo provides the complete box, but JQuery is far easier to learn. Their is an elegance to both so I urge you to do the due diligence and at least spend a week working with both before you make your decision.
- hernan7 17y ago
  Thanks, will do.