The web is just a delivery mechanism

TL;DR – The web is just a delivery mechanism and your web browser is just another I/O device.

 

Disclaimer:

Some people argue that this is all very nice in theory, but in practicality those ideas are not feasible. Well, those are not draconic rules that every developer must obey, rather this gives us a common language for further discussion. It gives us a frame of reference.

 

The thought:

Lately it got me thinking, why do developers have such a hard time separating the notion of the web from the actual business application?

I am currently working at a start-up building tools that can take your legacy application, say VB6 desktop app, and automatically rewrite/re-architect that desktop app into anything modern from the 21 century whether it’s a web MVC application, GWT or maybe one of the popular desktop frameworks.

We work mostly with huge companies that have hundreds of old desktop applications and most of our clients strive to migrate from the desktop to the web and the cloud.

During the rearchitecting process, the developers that are involved in the project often bind their way of thinking about the architecture of the program to a specific paradigm, and so the sentence that i hear  often and that kind of bugs me is:   “…well, because it is a web application!”.

Should i care about the web and the web browser? Maybe. Should the web browser become my No’ 1 concern in my architecture? Definitely not! Maybe we don’t learn from history after all…

 

History:

Do you remember the Unix days? I mean, can you recall what were the groundbreaking innovative features Unix brought to the table when it first appeared?

I want to talk about one specific point – Unix’s I/O abstraction.

Prior to Unix, hooking up an input or an output device to a computer was hard. It was very explicit. There were no defaults. Every operating system had it’s own prerequisites and caprices.

Unix made our lives simpler, it abstracted the I/O device hookup and most importantly it gave us a default setting: keyboard for input, monitor for output. As simple as that.

When you were writing C code, you didn’t have to care about the input or output channels, you just used “stdin” and “stdout” whenever you wanted to create some input to the program or spit out some output.

 

And then came “The Web”:

Some years after the Unix system was released, the web came in to our lives, and along with the web we also got the web browsers.

Ok, so now i want to ask you a question: Why is the web and your browser are playing such a major role in your architecture? Why is your architecture screams “WEB”?  At the basic level, your browser is just an I/O device, and the web is just a delivery mechanism! Nothing more and nothing less.

Just like 50 years ago, with the help of Unix, the software industry realized that your I/O channel should be abstracted away from your program, it should still hold true today.

 

Why is this important?

Why is it so important to accept the fact that the web is just a delivery mechanism? Well, think about testing. You should be able to test your business rules and your model without thinking about the web, because it is not relevant. When testing your business rules you should not be thinking about http requests and responses or about web servers or any of the web related software components. The web should serve as a plugin, and as a plugin there should be a way to replace the web with any other mechanism. Should you desire turning your application in to a console app? A service? This should all be possible without changing the application itself.

Here is an amazing talk by Robert Martin i suggest you to watch at least 2 times.

For further reading i suggest you read “Screaming architecture” post from the one and only.

 

If you are angry, mad or just happy about this post and want to share it with me – leave a comment.

Happy coding,
Shonn Lyga.