Some Real Beginner's Questions

[Pedro]

Hi, I'm learning programming, I studied some different languages and ways to do things. I'm interested in PHP, and most tutorials seem to focus on how to do things with the language. Somehow I feel kind of stupid asking for this, but let me try to explain the problem and please forgive me for my probable misunderstanding of things and for how I'm somewhat lost.

As I (kind of) dealt with Java/Spring (hate it) and Node.js (this one is ok for me) for back-end, when I started trying stuff with PHP I stumbled on some code embedded in html. With Spring and Node, I usually made all the server code in separate files, but PHP is embedded, I am not sure of how should I look at it.

My question here is: should I build a back-end program/server separate in PHP? Should I start looking for some examples for it (I didn't find too many things about it, really)? Or should I just use embedded code and accept it will be processed in the server and there are good ways to deal with the situations that come with it?

For instance, I'm trying to work with pure PHP, no frameworks and libraries at this stage (do you call it vanilla?).

Thanks in advance.

[mac_gyver]

the code for any php page should be laid out in this general order -

1. initialization
2. post method form processing
3. get method business logic - get/produce data needed to display the page
4. html document

the code for any particular section can all be in the main file or divided between the main file and any number of separate files that get 'required' when needed. the html document should only contain simple php code, acting like a template engine, that operates on the input data supplied to the html document from the other sections of code OR more simply just use a 3rd party template engine.

 

Edited August 28, 2022 by mac_gyver

[requinix]

All languages that power websites, including PHP and Java and Node.js/Javascript, share the same two aspects: that there is code running on the server which creates some output, and (typically) that there is code running on the client to perform additional actions.

That duality is a lot more apparent with PHP than it is, say, Node.js and React, but only because that's the more traditional (and easier) style of mixing your server-side code with your output. If you wanted to use React to handle the interface instead then you could do that with PHP too, even if the approach would be different.

[gizmola]

You already have some useful answers, but I'll throw in my 2 cents which includes a bit of history.

When the world wide web was first evolving, all HTML pages were static.  The HTTP protocol, which enables the WWW, describes how a client (browser) can use a URL to reach a server, and request a resource (html document).  I would hope that at this point you are familiar with the HTTP methods available -- GET, POST, PUT, PATCH & DELETE.  

So a browser made a get request via HTTP, and the first servers would resolve the location of a static html document and return that to the client.  Again, somewhat obviously, an html document can specify a number of pieces, which again in the early days were images, as Javascript and css had not been invented/formalized yet.    The job of the browser is to parse and assemble the html document and display it to the user, and handle hyperlinks.

Eventually, people wanted to provide a more interactive experience.  A simple example, would be a page that showed all the latest news stories of the day.  Either someone had to manually update the index page, and add static html pages for all the stories, or a program running on the server could be enlisted to create html on the fly.

Sophisticated software existed for a long time to do all of this, and in many ways the WWW was a huge step backwards.  Client/Server and terminal applications had existed for years prior to the first browser and web server, and people were used to using online services like Compuserve and AOL, which had their own client/server protocol and content rendering client software.

The WWW was an attempt to democratize this and provide standards that anyone could use.  HTTP itself came from scientific organizations who wanted a way to easily share research papers.  Much of what we know as the Internet also came from this process, where people would publish standards in the form of "Request for comment" ie RFC's.  A few groups that had been involved in the creation of the first web servers got a working group together and published RFC 3875 which describes the "common gateway interface" (CGI) which standardized the way a web server could invoke a program, accepting input from the web server in the form of environment variables with specific names and purposes, and then return the results (in the form of html) to the web server, which would then return that "computed" html to the user.  

This was the birth of "server side" web programming, and the basic structure of that continues to this day. 

• Web Server accepts an HTTP request with a URL
• If Web server detects that the URL requires a "CGI program" be run, it passes variables (user input and standardized CGI web server variables) to the program through the Operating system environment
• Local server program runs, returns a "response type" data structure + the actual data to the web server
• Web server returns html (or any other valid resource type) to the client
  • I mention this, because the URL might have been an image, which could be generated on the fly by a server side program as in the case of a computed graph image

 

So this brings us to the various popular server side languages.  In the early days of the web, people would often write their CGI programs in C, as the primary server operating system of choice by most people involved in running servers in the early days of the WWW was Unix. 

As C is terse, and requires compilation, early web developers started looking for ways to simplify coding.  CGI allowed any "program" to be used, which meant that early developers could use something as simple as a bash script which chained together various unix commands.   The Perl scripting language was extremely popular at the time, due to its interpreted nature, advanced data structures and many available libraries.  For example it had a relational database client interface (DBI/DBD) that allowed a developer to write simple code to make SQL calls to a relational database.  Commercial databases like Sybase SQL server and Oracle were popular at the time, and the open source MySQL database was seeing a lot of adoption, as the commercial databases were expensive and hard to obtain.  

Perl, like other interpreted languages, is evaluated when the script is run (at runtime).  Most developers found this highly preferable to developing in a compiled language like c or c++, which required a compilation/build process anytime you changed so much as a single line of code.

It was in this time, when PHP first appeared, and it was intended to be a language/toolkit specifically aimed at making the development of serverside web scripting simpler.  So one of its features as the ability to intermix HTML and php scripting blocks in an html script.  This is somewhat in the spirit of a competing standard at the time, called "Server Side Includes" which had a similar objective of taking something that was mostly pure HTML and augmenting it with some markup that the server would act upon when the page was requested.

With that said, PHP like Perl, is interpreted, and thus required a runtime process to parse the PHP code and execute it at runtime.

Java also has a runtime, although the main difference in the case of Java is that the Runtime engine (the JVM) was designed to be a persistent server process/daemon.  

In the case of Perl & PHP, a web server running a Perl or PHP script needed to invoke the perl or php runtime program, which would then load the script code and run it.  This script code could of course also load/include perl or PHP libraries, and do all sorts of things while running, but unlike java, it was not intended to have any persistence.  This is very different from java where you can create objects and have them persist in the JVM (or in the case of Java EE, a Java application server).  PHP programs are run when requested, and when the PHP script is done running, all the variables and objects that might have been created are disposed of when the script ends and has returned the response data to the web server.

As PHP became popular, people wanting more performance and less overhead began to look for ways to reduce the overhead of starting up the PHP process each time.  By this time, the open source Apache web server had become hugely popular, and apache was designed to be a collection of modules, with a specification for anyone who wanted to add a new feature to the server via development of a custom module.   Developers within the PHP project community created an apache module (mod_php) which essentially made PHP a part of the Apache Web server.  This meant that instead of the web server having to fork a child program and pass all the variables through the environment, a PHP script could receive that data and access web server variables directly from Apache's shared memory structures.

The problem with this idea is complicated and has to do with how Apache services requests.  I wrote about this issue on my blog if you want to read more about the underlying issues.  Around this same time servers had appeared to challenge Apache, most notably the NGINX web server.  NGINX has a fundamentally different architecture to Apache, and had no support for mod_php or something similar.  NGINX was designed to be a highly performant proxy server, so it supports a variety of ways to proxy a request to a server process for handling.  NGINX implements "Fastcgi" which was developed as an alternative to CGI.  Essentially, fastcgi sought to get around the same problems that apache modules were designed to get around -- the overhead of having to create and destroy an os program for every request to a server side script.

NGINX and other servers that support fastcgi  (which even includes apache now, via an optional fastcgi module) assumes that there is a persistent operating system process that supports the fastcgi protocol.  This was ideal for languages with a persistent runtime application server process like java.  In order to make this work for php, a persistent php application server was developed within the PHP project, that supports fastcgi.  This php application server is called php-fpm.   Internally php-fpm maintains a number of persistent php processes which can be used to run a php script.  A proxy web server like Nginx can be configured to send requests for php script to php-fpm via fastcgi protocol, and return the results to the client.

I hope this somewhat long and verbose history of web servers helps answer your question and give you some background to clarify how PHP works.  At the end of the day, a PHP script is a PHP script.  There aren't a lot of different types of PHP files -- there is only .php.  Frameworks have introduced template languages, and PHP can parse files of various flavors, but in all cases the end result is the execution of PHP code.  Unlike Java, there was never an effort to define specific file formats to do different things as in the case of Java servlets/vs JSP vs JSTL. 

PHP was designed with the intention of being a language that would work with and be integrated with a web server via CGI.  It has many design features focused on that, and is not generally considered a generic scripting language like perl or Ruby or Java, Nodejs or more recently, Python.   

Any one of those languages (including PHP) could be used to create a "socket server" that can run on a server and handle HTTP requests.  There are other types of protocol servers (Websockets in particular) that have become popular as the web has evolved.  The performance of PHP interpretation has been improved in recent years, and there are also projects that add some valuable features like "event driven non-blocking IO" which are beneficial if you are developing a server process in PHP, but that is not the typical reason people use PHP.  For the most part they are using it to create server-side web applications.

 

[Pedro]

Thanks, you helped a lot, I really appreciate it, and now I have some direction. It's funny, tho, how I can get stuck in some seemingly simple things.

[gizmola]

4 hours ago, Pedro said:

Thanks, you helped a lot, I really appreciate it, and now I have some direction. It's funny, tho, how I can get stuck in some seemingly simple things.

The web is a complicated and confusing interdependent set of technologies, and is often underestimated.  Most people get confused as to how specific things actually work.  There are better tools now, like the chrome web tools for example, which are great aids to figuring out how a web application actually works.  Javascript with its frameworks and SPA's continues to add to the complexity and role of client side code running in the browser, but I do believe that if you really understand the fundamentals, like where code actually runs, and the overall architecture of the various processes involved, you have a better chance of avoiding confusion.  HTTP is very important to understand.  Using the dev tools Network tab is a great way to explore this.  

A lot of times people just assume that something described in abstract, like cookies for example, are obvious, but if you don't understand where cookie data lives, and in what circumstances the server has access to cookie data, and what restrictions might exist for that data, it can just seem like magic, which leads to confusion.  A good understanding of HTTP helps demystify things.  When you look at HTTP it then helps to understand that HTTP is built on top of TCP protocol.  So you can continue to delve into the intricacies of how things work, and gain a deeper understanding as you see fit.