History look
The first applications were running on “the” computer. There was nothing like “client” and “server”. There was the computer and the punch card input, printer output. Later the mainframe came and the clients were terminals. Looking back, we can say that this was a two tier architecture with lightweight clients. This was practically the same with the mini computers (PDP, VAX and their clones) until the PC was introduced.
The PC architecture introduced the two tier paradigm that contained a fat client and file server or database server. Three tier architecture was supposed to replace the two tier architecture to have a no-so-fat client, server supporting business logic and storage on the third tier. Then came the web and the browser and the client was replaced by web page. Thin client was invented. At least the terminology was born that time. And during the last 20 years the web technology evolved and with HTML5 we have something on the client side that is very powerful and in functionality and in capability comparable to the thick client of the early PC era. If we consider the memory and CPU power we currently have an HTML5 capable browser fairly overcomes any early PC fat client.
Time to think about what is implemented in what tier. As we see the functionality, storage and code were dangling back and forth between the client and various server components. The optimal distribution of functionality was determined by the distribution and availability of CPU power in the different tiers, storage capabilities and network latency as well as bandwidth. Technology evolving changing the ratio between these changed where we put parts of the functionality.
Today
Today clients are so powerful that we are tempted to put everything on the client. It is not only the available top-notch client, which is so powerful. We can also expect good cpu power, memory and bandwidth on the average client. Why not to put all functions on the client? Could we do all business logic on the client? Almost. There are some features, not mentioned above, that a client does not implement and is not likely to implement in the near future with the current architectures. Some of these are features like:
- persistence
- search
- transactions
- trust
Let us look at these features.
Persistence
You can not store data reliably on the client. Backup, archive, audit logging are functions that are naturally live on a server. If ever any of these are implemented on a client machine that machine is operated as a server some way. If not impossible then probably expensive to do it on a client. Individual clients can not simply backed up and they have to communicate with each other to see the same state of the data that reflects the actual state of the modeled world.
Search
Search is also something not likely to be implemented on the client. Search needs the data to search in. In some cases the data set can be copied to the client and thus the search can be implemented on the client, but in most of the cases the client will work only with a subset of the data, therefore search is implemented on the server.
Transaction
Transactions are tied to data. If you sell airplane tickets you may not want to have a system that asks all other client terminals if the seat A in row 13 is still free on a certain line. That would be a total noise like a room full of people. Perhaps something like the old stock trading rooms may resemble to that.
Trust
Clients are owned by the person having physical access to the machine. Steve Halls’ talking moose said: “Never trust a computer you can not lift.” When it comes to physical security it is crucial the other way around: Never trust a computer somebody else can lift. In an application you can not trust any communication that comes from a certain client unless you established some trust. Password, card access whatever. But the trust to maintain is up to the server, which some bad guy can not nick.
Where does it come?
Single page applications contain static HTML, CSS and JavaScript. The server communicates with the client using Ajax, REST, JSON. The users identify themselves using some authentication, probably OAuth. After that the client application displays whatever the functionality of the application needs and the server provides only data functionality. All the server should do is CRUD with access control. Whenever a client wants to access some data the server has to check if the said user has the rights to read and/or to write the data. Other than that the server need not know anything about the business functionality.
Persistence services, like MySQL or MongoDB (to name one of SQL and NoSQL) are providing REST interface and the interfaces obviously do require authentication. However the authorization scheme of these interfaces are very weak. The usual approach is: if you authenticate you are authorized. There is no document or record level access control, which I see will come in the future. First we will have applications that work as a front-end to these persistence applications that check the authorization and based on that let or deny the operation to perform. However this solution is not optimal from the performance point of view. The logical implementation of such logic is where the data is: in the database.
If and when the databases will support such a record level authorization schema we can write all our code, or almost all code in JavaScript running on the client. Applications will be developed in JavaScript. Java will only remain for enterprise integration, connection handling to legacy systems. Java will be what Cobol is today. Will it?
| Reference: | Do all business logic on the client using JavaScript? from our WCG partner Peter Verhas at the Java Deep blog. |
Do you really want to put all business logic including proprietary algorithms in Javascript code that is downloaded (and hence readable) by a client ? As you said : trust is a feature that must not be handled to the client.
Javascript is great for client-side development, but has yet to stand the test of time for full-fledged apps.