: Advantages/disadvantages of "separated" web applications I'm in the process of designing a (soon-to-be) rather large PHP/MySQL web application. I've come to a fork in the road as far as internal

@Murray155

First, no offense if this answer is too obvious or basic. Your use of "separated" instead of terms like Ajax or jQuery makes me assume less experience with this topic. Of course i could be misreading the question, so my apologies if that's the case.

Use both, but wisely

Think of your choice of server-side or client-side tasks in terms of where and how a task is most efficiently done. This will help you render pages quickly (on the server), but offload work to the browser where it makes sense to do so. And, there will be gray areas where you just have to make a judgment call. Your job is to find a smart division of labor.

What belongs server side?

(This is an extreme example to illustrate the point.) Say you're writing a web app that does some type of searching. You don't write browser-side Javascript to call a server-side PHP web service to retrieve an entire 2GB database to "free up your server" and offload searching to the user's machine. What you do is get the search terms from the user with a form, POST it back to the server to query the database directly, then send the results back from the server to the browser.

The logic here is that the DB itself knows how to best do the query, the server is closer to the source data, and less data has to be moved around between components. The browser only needs what it displays, so don't send it all to the browser. (Not to mention relative language performance.)

What belongs at the browser?

Browser side code is your "separated" scenario (if i understand correctly). But for the browser to do most anything intelligent, it has to have server cooperation.

Okay, you've got your search app working but you want to spruce it up with some fancy pants Ajax. Write a PHP web service to take a few letters and return matching search terms, a la the "search suggest" feature of Bing, Google, etc. Write your browser code to only suggest terms after the user's typed in three or four letters, so your suggest list is small. Back at the server, index your database on that field so the search is fast fast fast.

Here the thinking is that "search suggest" is a feature that must be split between the server and client. The browser can quickly deal with targeted, small-ish piles of data. The server can get that targeted, small-ish pile of data and give it to the client. A poor division would be for the server to render a monster list (of say, 500,000 items) of possible field values as an XML island embedded in the HTML page, then have the browser search that as the user types. (a) sending all that data to the browser is slow, (b) searching it in Javascript will never be as fast as letting the DB search it, and (c) you're likely to blow up a user's machine by cramming all that data into their browser app space. On the other hand, you need to make sure that the Ajax call to the server, and the subsequent query and return are super-fast. No dilly-dallying around.

Where's the gray area?

Here again it's a judgment call. Above, i talked about the server doing the search, then sending the results to the browser. But, the question arises, do you let the browser submit the search terms with the form and have the server render the result page, or do you use client-side Ajax/Javascript to send the search terms and retrieve the results, then render it in a DIV to avoid a page refresh? Both are valid. Resource-wise, there's no real benefit either way. The Ajax way can provide a better user experience but, depending on your app and the circumstances, might present some other challenges (e.g. security).

Bottom line

Use both appropriately. Don't skimp on thinking and learning about architectural performance and efficiency. Move less data, fewer times. You'll take a load off your servers, your databases, and your users' browsers.

Vote Up Vote Down

@Nimeshi995

In order to be able to re-use code you can always look at XSLT for the generation of landing pages and then have XML/JSON interfaces for AJAX (utilising the XML interface for the XSLT landing pages).

You would normally allow the content and interaction to work on a RESTful interface with a /json/... and /xml/... prefix and host your main content, converted into mark-up via XSLT on /...

This way people can land on any page and suddenly have the full blown AJAX website. Spiders can crawl your site and you have concentrated on the content/interfaces first and foremost - seems like a win/win.

Mobile websites sometimes need different layouts (bespoke iPhone only sites anyone?) a simple XSLT conversion here or there for different user clients can re-use everything you've done so far.

Remember to design for simple HTML output and navigation, the AJAX simplifications can follow.

PS - Do the XSLT transformations server side

Vote Up Vote Down

@Welton855

First off, whether you go with an Asynchronous heavy website or not won't have much affect on your ability to build iPhone/Mobile and desktop apps because it has nothing to do with them. Either way you won't be able to reuse your code.

Also, Asynchronous sites can be just as slow or slower than normal sites. Usually, that kind of functionality is added for a reason, specifically for enriched user experience. Using JavaScript tends to hurt you on SEO because webcrawlers cannot fully understand the intent of the JavaScript and so ignore it mostly.

I think what you are looking for is a way to reduce your development overhead by only writing your functional(middle) tier once and using the same one for all of your apps. In this case I think there is value but frankly these kinds of architectures are harder to setup and take a lot of time. I would be of the opinion that you should develop your website as best you can and keep your middle tier code as strong as you can. That way when it comes time to add an iPhone app or whatever you will be able to move to a model with a common middle level more easily

What I am really advocating here is taking baby steps. Don't try to write code now to handle things you don't know about yet. Just write the code you need and make it as flexible as possible.

Vote Up Vote Down

@Jamie184

I think the idea of a "separated" application that relies heavily on JavaScript/AJAX is going to get you into a lot of trouble. A few things off the top of my head:


It's going to be bad for SEO since Google will have a hard time indexing anything.
It's going to be hard to make it "bookmarkable"
You'll have a hard time with mobile devices as many of them have very limited (or broken) javascript support.

Vote Up Vote Down