OPIE and the Web and PHP

Posted on Posted in Computer Science 101, PHP Dev, WordPress

In this post I will explain various features of the Web, PHP, the internet, from a computer science point of view, and especially with reference to my theory of OPIE (Output Equals Process of Input, O = P(I), with the E being an optional “plus Error”) as the foundation of comp sci. To make things more fun, this blog post features a series of slides, each one showing OPIE as applied to a particular area.

Our first slide shows the typical architecture of a web application. The software lives in a server (a web server or app server) that the user interacts with over the internet. The process is the software that lives on the server, and the output that is delivered to the user thru his web browser or smartphone app consists of nothing other than the input that he submitted to the server, processed by whatever software logic lives in the code on the server. The output is defined by the process plus the user’s specific individual input.

Slide two shows the process with a focus on what happens inside the server. This is what is known as the three-tier architecture: The first tier is the client, the software on the end user’s hardware, be it a web browser or smartphone app. The second tier is the web server or app server, which lives on the server and could be coded in PHP, for example. The third tier is the data server, more commonly viewed as the database, which could be MySQL for example. The output is the result of the process comprised of user input from the client going to the web server and then being processed by the web server in conjunction with data from the database. A typical process goes from the client, to the web server, to the database to retrieve relevant data, back to the web server to be processed and formatted, and then back to the client, ending in output to the end user. If a user clicks a link and sees a web page, this entire process happened behind the scenes to make that happen.

The above slide is a diagram of what is known as the four-tier architecture (which is actually something completely different from and unrelated to the three tier architecture). It is otherwise known as the four-layer architecture. This is how the internet works in terms of hardware. Software lives at the application layer, such as a web browser, and then travels down to the next layer, the transport layer, which wraps it up (possibly with encryption or tunneling), then sends it down to the internet layer where it is converted into a series of data packets each with an HTTP header, and these data packets are sent through the actual internet, which is a series of routers and fiber wires that stretch hundreds of miles all around the world (as well as undersea fiber cables, satellite transmission, etc.). The data packets are routed based on the IP address in their HTTP header that tells the internet where to send them. The fourth layer, the “link” layer, is the actual pieces of hardware connected by the fiber etc., i.e. the actual backbone routers. The data is then collected at the endpoint identified by the IP address and assembled into the request that was send, then processed (e.g. by the server, as in the previous diagram), and then the response is sent back out through the internet, as a series of data packets with an IP header and UDP header, collected at the IP address end point (the user) and assembled into the request send to the user, to the transport layer where it is decrypted, and then sent up to the application layer, as, for example, a web page. The communication between the client and the server appears to exist but it in fact an illusion, and the real communication goes through four layers of complexity, the lower two layers of which happen completely out of sight. The major innovation of the internet that makes the internet possible was to split data into packets with an IP address, which allows data to be routed in a decentralized and highly efficient manner, whereas a physical direct connection between two end points would be slow and expensive.

Now I will explain OPIE and PHP. PHP is widely known to have four advantages as a computer programming language. First, there are a lot of free open source frameworks and packages to use for it (think WordPress and plugins) that make development cheap and fast. Second, it is good at generating websites and web pages, making it ideal for web development. Third, it is (perhaps erroneously) viewed as merely a thin layer of abstraction between a database and an end user to make database output dynamic (more on that in the next slide). Fourth, and this is what the above diagram shows, PHP has a magical superpower called “interpolation” that lets the developer mix PHP code with HTML code in the same file, and when the file is executed the PHP code evaluates to HTML code that is inserted into its proper place in the file and then that entire file of HTML is sent to the end user.

The interesting thing about this is that the HTML web page outputted to the user, the O in OPIE, is the result of the user’s I (a click of a link requesting a web page, for example) but the P is quite interesting, in that the PHP will dynamically evaluate within the file that is called (i.e. within the PHP script that is executed). This, at its most basic, makes it easy to interpolate dynamically changing content into static web pages, which is, when you use it, really a magical, powerful feature, that, I think, drove and continues to drive the popularity of PHP.

This feature, of course, is specific to HTML, in other words, websites (Cordova smartphones apps to the contrary notwithstanding). With the rise of smartphone apps, PHP may seem less relevant. But, web pages have advantages that smartphone apps lack: they are consistent across web browsers for all devices, can be developed cheaply and cost-effectively, and a website for a small business listed on Google continues to be a good solution for a small business to have a “face” that it presents to the world on the web, which could be ten times more expensive to produce as a high quality app. So the web will endure, and while it does, so too will PHP, which solves a problem with interpolation that makes it highly efficient for web dev.

This slide demonstrates something that I call “the Prism Effect”: The user (e.g. the WordPress website admin) enters data into the PHP, and the PHP stores this data in the database–think WordPress plugin settings. But then, when the PHP executes scripts subsequently, it reads this data in the database, and the settings–the data in the database–can make the PHP itself behave differently based on what is in the database. This makes the PHP execution dynamic–one PHP program, e.g. WordPress or a plugin or theme, can behave in many, many different ways, and the dynamic behavior-modification can be iterated, as subsequent script executions can then add data to the database that further modifies the next iteration. In this way, when the PHP reads data from the database and renders it into web content for the end user, this is not, I think, merely a thin layer of abstraction above the database, it is output that has been dynamically generated by iterations of behavior-modifying data. In other words, in generating a website, there is a complication dance between the PHP and the MySQL, the end result of which is the HTML generated by the PHP that was dynamically behavior-modified by the MySQL that was added to the database by the PHP upon input from the end user.

In my next comp sci 101 post, I will explain the OPIE analysis of WordPress and Laravel, the two most popular PHP frameworks. As a preface to Laravel, here I will briefly mention the MVC architecture (I know, a lot of architecture, right?) in terms of OPIE. The MVC framework is the process which takes in the user request and processes the request and then outputs a response that is a function of the process processing that request. Inside of that process is where the MVC fun happens. The input goes to the controller where the software business logic is, and the controller then processes the input by reference to the data in the model, and then populates a view based on the result of processing the input from the request with the data from the model. This then outputs a response, a view, to the user. This adds yet another layer of iterative PHP-modifying behavior on top of the basic prism effect I detailed above: the Controller and Model can interact in an iterative sequence, with the Controller writing data to the Model and this data being applied by the Model to modify the Controller, and the View can also dynamically contribute to the end result.

I hope this blog post has been illuminating and informative! Stay tuned for more to come!

Leave a Reply

Your email address will not be published. Required fields are marked *