This article takes you by the hand and shows which client and server side components you need and what ways exist in order to successfully build a database supported web application.
The overall architecture
First of all, let’s take a look at the overall architecture we’re dealing with while developing:
Then, still on our client, we either have an editor to create our files locally, or a terminal application which lets us develop code remotely. I will cover this in a second.
That transfer from our developer client to the server is done using file transfer client tools such as WinSCP (Windows) or Cyberduck (OSX). They support different protocols such as FTP or SSH, depending on your preferred way of communication and the abilities of your server.
Now let’s take a look at how your development can take place.
The client-driven way to develop
There are various ways to develop. One way is in favor of the client. You can use a local editor application at your desktop in order to create all kinds of code, e.g. Textpad. You then need to transfer that code to the server using your file transfer client, e.g. WinSCP. That application then contacts the file service on the server you want to send files to, possibly running an ProFTPd (the counterpart of your file transfer process, which is not interesting for you unless you need to setup your own file server).
That file server then puts all of the files received to the hardware of the server, where it can be accessed by the webserver, for example — which is want we want, isn’t it :)
The server-driven way to develop
Another method of developing is in favor of the server. You can use a client-side application like Putty (Windows) or Terminal (OSX) to connect to your server using SSH. Once connected, you can use server-side editing tools like VI. I will cover VI handling in another article.
The advantage here is that you do not have to transfer any code to the server, since you’re writing files directly to the servers hard drive.
The disadvantage is that you have to maintain a stable internet connection all the time, which can be difficult in crowded WLAN environments.
The user-server interaction roundtrip
Now let’s see what happens if you or another user tries to access files you created. The browser sends a request against a specific file, which is also the case if the address being accessed is just “www.domain.com”, since the webserver, receiving that request then searches for a file called index.php or index.html. Once that file is found, what happens next depends on the kind of file being accessed.
Server-side script interpretation
If the file is of PHP or any other server side script language, the webserver needs interpreter modules installed which enables it to further process that script. Every script processing results in yet another markup output (HTML, for example) which can be interpreted by the client’s browser after transfer. The way in which that markup was created, however, is not visible by the outside world.
Server-side script and database interaction
Having a PHP or other server side script, a database can also play a role when it comes to accessing structured data, like processing login information. The webserver then needs further components to interpret DBS connections. If the script in question is PHP and the database system is MySQL, the PHP script needs both correct database connection parameters in place and a well defined SQL statement. Both of that can be thrown against the MySQL server instance which then deals with the query and sends the result set back to the webserver. The webserver then does the same as it always does, creating markup and sending it back to the client’s browser.
That would be a full roundtrip, and it is important to understand that interaction in order to successfully build a standalone web application — which is what we’re aiming at.