What are the advantages of a client/server architecture in webapplications as opposed to a server generated frontend application

In our company, we need to build a web interface onto an embedded Linux platform. I kind of see 2 options: You use a technology where the HTML and JavaScript is generated on the server side (Think JSP, Grails, but is is something that is using C++ and generates HTML/JavaScript) or you create a HTML5 ‘client’ application that talks to a JSON or XML generating backend.

I have the feeling that web applications currently tend to go with the latter, but what are the advantages of doing so (The developers on the project choose the former, mainly based on the fact that they know C++ much better then HTML and Javascript)

AJAX

I think your question boils down to, “Should my web application generate HTML on the client side or on the server side?” Client-side generation communicates to the server using AJAX, although the X (XML) has generally been replaced with JSON, but most people still call it AJAX because it sounds better. Server-side, the server just makes HTML on the server.

I have a lot of experience with XML and almost none with JSON. Everything I know about XML makes me suggest that you use JSON if at all possible.

AJAX Pros:

Send less data over HTTP(S) so they can run faster.
The server is essentially a web service so that other people (or you) can write their own clients. This may help when creating a mobile version of your site. Also, many inventions become popular for reasons their creator never intended. Services are friendlier to people finding new uses for your code.
Looks like a newer application

AJAX Cons:

Debugging JavaScript
Complexity?
The stuff you can do with JavaScript is often completely impossible for blind or handicapped people to use.
May require more code total (bigger overall storage on your embedded device)

Client/Server

All web applications use client-server architecture. The HTTP protocol forces web applications to behave that way. AJAX uses a work-around for that design limitation, but the basic underlying model of HTTP is still client-server. I wouldn’t get hung up on the whole thing about the best way to apply MVC to web applications. If you have to do MVC for political reasons, look at how Ruby/Rails does it. Actually, Rails is a great architecture to copy (or use).

Service vs. App.

A good service is almost always better than an application. But making a good service is hard! You may need to make the application before you can write a well-enough designed spec for a service. Don’t make your job more difficult than it needs to be. For version 1, focus on making a great application. Until your application is relatively stable and you are sure it meets your user’s requirements, having a service probably won’t do you any good anyway. Designing the wrong service too early is a waste of time that keeps on wasting as you try to fix your service interface, and deal with the massive refactoring of both server and client code that will follow.

C/Web

Wow. I worked in C and Assembly for 3 years before I switched to web development. I cannot think of a worse language to write a web application in – especially from a security point of view. Input validation and output escaping are so critical… SANS releases a list of the most common errors every year. Buffer overflows, injections, cross-site issues (improper output encoding)… All of these errors are really easy to make in C or assembly. At least a language like Java has a String which is immune to overflows and an exception handling mechanism that generally prevents off-by-one errors from allowing malicious code to access system memory. Not to mention handling international character sets (use UTF-8 when possible).

If you need to use C for memory or firmware reasons, then that’s what you have to do. Just be careful!

Browser Support

The first step to making a web application is discovering which browsers will be used by your clients? W3Schools and Wikipedia are both good sources of general statistics, but YMMV.

Where I work now we currently validate that our application only creates valid XHTML 1.0 transitional HTML. We also use the specific Doctype and formatting necessary to avoid Quirks Mode in IE, which makes cross-browser HTML easier to write (see tips on my blog). We test on the latest 3 versions of IE, plus Firefox and Chrome on Windows and Linux (Safari uses the same rendering engine as Chrome). With that validation and testing, our application pretty much works everywhere (Windows, Mac, Linux, iPhone, Android, etc.) except the BlackBerry.

The BlackBerry has never had a real browser with JavaScript, so we don’t support it. BlackBerry users are used to not having a real web browser, so they don’t complain. Maybe that’s changing? I would try to ask a few clients what browsers they are using and make sure to test with those browsers.

Summary

All web sites are built on HTML and HTTP. Have a good reference for these technologies at hand while you are making your application. In the course of making an application, even with a toolkit, you will run across issues that require a basic understanding these technologies in order to solve them.

You probably also need to be comfortable with CSS, and image compression in order to make something that looks decent and responds quickly. JavaScript, web-servers, and browsers are additional areas of knowledge that you will ultimately need.

If you build your HTML on the server-side, your code base will probably be smaller and you may not need to learn JavaScript. The server-side model means your programmers will be writing (C?) code that generates HTML that they can look at directly before it is sent to the client. The AJAX model means your programmers will be writing JavaScript that generates HTML. I’m not aware of a lot of tools for validating or even viewing the HTML code generated by JavaScript within a browser, making it more difficult to program correctly.

Where I work now, we use a hybrid approach which occasionally involves Java code that generates JavaScript that generates HTML. If you guys are new to web development, that’s not the place to start. I guess I would have to say that unless you have compelling reasons to use an AJAX model, I’d start with the older server-side-HTML-generation model and see how far it gets you.

The latter has the advantage that it makes your “back end” a generic “data service” (whatever that may mean in your context).

Your HTML client is then just one of the many possible consumers of that data. Think iOS app, Andriod app, Windows 8 app, APIs, etc. — as other consumers.

A growing common way of a web application is a mix of both, tending one or other side.

The first approach is more traditional, has been there for years and its well documented, (although c++ is not generally a language popular for that).

The second option is more modern, and is present in the development blogs and forums nowadays. One of the reasons for that, is the growing need to serve the same application to other interfaces, mobile and services API. The second approach tends towards a client richer and more responsive.

All in all, that depends of other constraints, like the team familiarity, and business case.

Some questions that can help you assess your options:

Does the team have experience in the language and platform?
Is the team willing to learn new approach and technologies?
Does the application takes advantages of being more easily programmable for other devices (iPhone, android, windows 8, etc)
Will other, internal or external app integrated with services or data availble to application?

For such “intranet” applications I use the fat-client (JavaScript/HTML5-app + JSON) approach with ExtJS4.

For normal “internet” websites I would use a more “classical” approach.

The clients have to render the site anyway, so why not charging them with the whole process and just give them the data to fill in. It simplyfies the server code for generating responses (just plain JSON or XML), which saves performance. Also the since there are always more clients than servers, the whole system scales much better if more of the work gets done by clients.

The client-code gets delivered with HTTP, you can still easily send new versions to the users without any obscure update mechanism. (Just replace the HMTL/JS/CSS)

The only reason I would prefere a classical approach on normal websites, are search engines.

Filed under: softwareengineering - @ 23:59

Thẻ: client-server, technology

Thiết kế website giá rẻ

Danh mục