Basic Pieces of a Web Application

Posted by scott_auge on 18-Jan-2016 13:08

Abstract

This is written for programmers and management considering a new application written with a web interface or the conversion/addition to an existing character or GUI application to a web interface. It is the beginning – the basic thoughts needed by every and any web application. As I wrote it, I was in a duel over time to read vs completeness.

I am surprised how many people are still wondering about how to write web applications or that it involves more than using a web editor and drawing up the screens. Like GUI applications (or even “green screen” i.e. character applications) they will have a database, algorithms and data structures behind the scenes that actually “do the work.” Web applications should be thought of the same as GUI, web services, RPC, or character applications talking to the database. They just have a web front end for the user to use.

It is written in a way that will apply to whatever technology one uses – whether Webspeed/Progress, JSP/Java, or PHP, etc.

The User Interface

For programming the user interface, there are basically two styles: Classic and AJAX.

Classic is the fastest to develop – very little javascript, most of the validation happens on the server. One can pretty draw it up with an HTML editor and get something going. The bad point – not a lot of values based on another set of values kind of work can happen.

AJAX is the modern way to develop web application – but it tends to be very javascript centric. Many places have hired Javascript programmers and server side programmers. One has to write the browser code as well as the server code. It is growing more rare to find programmers on both sides of the network.

A good thing is that one can start with the classic web style and as it proves it's usefulness, then add AJAX.

Session

Sessions are used for state free connections – that is the browser and the server completely forget about each other. But – something can be done – a cookie can be set on the browser to remember a value. When the web first started, it would be the variable that is to be “remembered.” Now days, the cookie is set to some hard to duplicate value and the variables are “remembered” in a database table – after all, that is where the variable is used! In the end, while you do not see it on the screen, sessions are very much the basics one needs.

Users

This can be obvious – but there are some things that one needs to take into consideration. Some users have permissions that other users do not. If you are running on a cloud, perhaps one user can even create other users. So saying “OK, I know who you are” isn't the only thing to deal with. Users will also be stored in the sessions of the above explanation.

Background Processes

There can be many internet devices and processes between the browser and the process that actually runs the code. There can be routers, web servers, firewalls, etc. that will begin a count down on a web connection. Once that count down reaches zero, the connection breaks. It is after all, state free connections between the browser and the server. (Stateful can be achieved with http 1.1, but is very expensive compared to state-free.)

So for algorithms that are known for taking time, such as applying Bills of Material against inventory with creating factory orders and supplier orders; or calling out to another's system (such as UPS, the federal government, or a banking system) – having these happen outside the browser/transaction processor is a good idea. Stack up the job for another process to handle and report it on a web page how things are going.

Useful on multiple OS' and Devices

Having a browser from the user's perspective allows one to use many devices and operating systems, from Windows on a PC, to Android on a smartphone, to iOS on a tablet. The user can decide what device they want to use and the developer isn't dictating the device to use. Heck, I have even seen web applications used on bar code readers.

But more importantly, the background process infrastructure needs to run on multiple OS' with a client server connection to the DB. While it is becoming more rare, some third parties who you may want to integrate with your program (credit cards, Word for invoicing, etc.) will run on one or a small subset of operating systems.

You will also want your background process to be multi-process/multi-threaded (though process means it is easier to shut down and spread over multiple computers). Having processes on different operating systems and have a type of job they look for can be important for specialized interfaces.

It is also important for load processing – for example a mortgage system I worked on had 24 computers dedicated to background processes.

Conclusion

Always remember the rule: Fast, Cheap or Quality – pick two.

All Replies

Posted by Marian Edu on 19-Jan-2016 01:17

Nice briefing Scott, would just add a few things if you don't mind much...

- html 5 is more than just ajax (that through rest interface is a big part of the data transport though)

- use a web-framework, as annoying and restrictive those might be at some point will still give you most of the boiler plate

- give node.js a try, it might just work for your case and can use some of the JS front-end guys to help exposing REST services, add features like authentication (AD/LDAP, facebook, google, ...) and push notification to only name a few

- webspeed doesn't necessarily equal 'classical', that can well be used for REST services so if you have it in house and have experience with it might worth not to trash it away

- local storage, might be useful if offline mode is required... some framework's datasources have that functionality already

HTML, JS, CSS might look frightening but as it turned out this is still the only standard we have so better overcome your fear and get to it... no other proprietary solution proved valid so far and eventually faded away (flash, silverlight, ...) so I would stay away jumping in bandwagons unless there is a standard set-up upfront but we already have one so will expect this to still be HTML :)

Have fun, take the leap and start the adventure.

This thread is closed