Basics – a user perspective on server-side scripting
So finally you have put together an HTML file peppered with some CSS. Nailed some JS on top of it to make it feel alive and the question is: what next? Well if you’ve read our previous articles *mhm shameless plug* you have already known the missing piece is the server. That almighty layer which allows us to share stuff over the internet enables us to stream content and is the only way to be a pirate unless you own a million-dollar wooden ship. Therefore, today’s diary piece is dedicated to comprehending where the server-side scripting stands hook, line and sinker.
Web server – the bastion of civilizations
Sir Tim Berners-Lee set out with the goal in mind to ease the exchange of information between scientists, which led him to create a web browser and the world’s first web server. The following years, the effectiveness of the system percolated several organizations and called for porting to different operating systems.
Hardware and software – a sweet collaboration
Throughout the years the notion of server became a merge of hardware and software. While they both contribute to the functionality of the system as a whole there is a difference to make.
Server as hardware refers to the metal part just like you and I have at our homes and offices. The tightly fit box contains a motherboard slotted with electronic parts. Its job is to host the server-software and web-documents (HTML, images, CSS, JS). It also features an ethernet port to allow data exchange with other devices through a network.
At the software side, a server includes all the parts that manage use and access to system resources. For example, an HTTP server at its’ core understands URL(Universal Resource Locator another fancy name for a web address, which you type in the search bar) and HTTP(HyperText Transport Protocol or the magic that occurs behind the scenes and present you with a web page). When you access a domain name, such as ebs-integrator.com, the software intercepts the request, gathers the required files and responds to the client.
Static vs Dynamic – where server-side scripting is born
Let us say that your website is just a text and an image. No matter who requests to view your website they will always get said text and image. Nothing changes. This is called hard-coded or static content. Find the diagram below.
In contrast, dynamic content is generated by the server. It can return different output based on information sent by the user (e.g ticking a box). The server pulls relevant information from the database and inserts it into HTML templates. To do that, the code must be run on the server. Thus, writing code for such interactions is called server-side scripting.
Server-side and client-side programming, what’s the catch?
Let’s review the general differences between these two layers of code:
- Different technology purposes
- Different programming languages (except JS which can now be run on the server-side scripting through node.js framework)
- Different system environments
Client-side code runs in the client’s environment – the browser. It is mostly preoccupied with changing the looks and behaviours of elements on a webpage: styling components, designing layouts and forms.
Server-side programming runs on the server environment with the general idea of sorting out which content is returned on a request. It uses the database layer to retrieve and store the needed information.
If you want a bigger bite of information regarding the layers that form a web-enabled software, you can head to “ a user perspective on web-enabled software.”
Server-side scripting code can be written in quite a lot of languages: PHP, Python, Java to sate your curiosity. This code sits on top of the operating system and enjoys full access to it. Moreover, the developer can choose which specific version of the language and OS they want to use.
Note: Languages and operating systems as any other piece of software receive updates. Some can deprecate or entirely cancel old functionalities, so if you decide to update on a whim your whole application can stop working. You must pay attention to what exactly is being done in the update, however, if it’s not broken don’t fix it. Might want to skip the last phrase and talk to a DevOps engineer.
The developers have a lot of freedom in how they can get things done. But, too many choices bring chaos to the development cycle. As a standardization measure, most of the coding is done through web frameworks: a collection of functions, objects, rules which aid teams in solving common problems through means that all can understand and adhere to.
Just as client-side and server-side code is concerned with different objectives so do the frameworks. Client-side frameworks are all about easing the layout presentation. For small projects, working the layout of the page through HTML and CSS is most welcomed, but sometimes(not all the time) those boxes just can’t seem to fit in. The developer has to spend close to hours playing with % in the CSS file.
Server-side frameworks enable the developer to avoid reinventing the wheel, as doing so for every web site can get tiresome. It’s all about making use of basic functionalities (session store, user authentication, database queries), without having to implement them through code.
What can the server give me?
Server-side programming is like a universal salesman. It gives you what you need when you need it. Its slogan is: “everything to improve your user experience”.
Storage & delivery
Creating a separate static page whenever someone writes a post or a comment can quickly lead to a shortage of memory which is simply not feasible.
Thanks to server-side programming, you can store and serve information from a database through various HTML templates as well as other types of files. It is also possible to send data to be rendered by a client browser in the scope of reducing server burden.
For instance, have you noticed that no matter what you search on Wikipedia the layout of the page is always the same? Well, all of this is achieved via server-side programming.
Refined user experience
Refined user experience is achieved via stored data. Perhaps you have noticed the “remember my card details for future purchases” check-box. If you search “Restaurants near me” in Google, it will retrieve your current location and give you a list of available restaurants pinned on Google Maps. Or maybe you recall that string of o’s representing the search result pages after you’ve googled something? All of these mechanisms are most of the time taken as granted, operated at the back-end of the app, to deliver the best application experience for its user.
Various algorithms can be devised to consume the data and offer assistance to users. For instance, remember that pop-up you get while binge-watching a Netflix show? The one that “asks” you if you’re still watching? It’s not that your app spies on you – in fact, that action is defined by a few lines of code in the back-end, that verifies how many times you’ve used your mouse, remote or other controls in the past few hours and triggers the message when you’ve gone MIA. If there’s anyone to hit “continue watching”, the party goes on, otherwise – the app puts your device to sleep saving you from a jump-scare heart attack while cutting on power consumption.
Server-side scripting allows control of the flow of information. That means you can restrict how and what information is being accessed.
As you are aware, if you create a profile on any site, only you have full control on how to change details. Other users can’t change your data nor view it if you choose the right options.
Bob wouldn’t be able to change your Facebook’s profile picture unless he has the login credentials saved on Facebook’s server. Similarly, pay-gated content will not be served unless you swipe your card.
Wikipedia servers also control access to user-content. While articles are indeed visible to everyone, only users that logged in and had their account verified can edit them. If you try to click the edit button, the server will check whether you have an active session. If there is none, you will be redirected to an account creation page(sign-up).
Another important aspect of server-side scripting is the availability of sessions – in essence, it’s a user-specific file that stores information on the current site and forwards pre-coded responses based on that information. If you were previously logged in on a website and you revisit the site in the future, you’ll still be logged in. The premise is that you pick up where you left.
Note: As long as you don’t delete cookies.
Servers can send programmed notifications either to specific users or the whole user base through the website, email, SMS and/or automated calls. Such behaviour can be observed on
social media which sends emails to notify you of new posts, SMS for verification purposes.
Streaming services such as Netflix, regularly send emails suggesting new shows to watch based on what you viewed previously. The web server itself can post various messages addressing security issues or failed connections. All of these, to create a communication illusion and deliver a sense of utility.
It’s not a secret to everyone that websites collect data about users. Every time you visit a website there is always a bar explaining the usage of cookies, thanks to GDPR.
What you search, what you buy, what you comment, how long you stay on a page, what pages you clicked in what order is all saved up and served to a data analysis software. The purpose is a further refining of interactions with the user, however, there is more to it below the surface.
All in all
Words fly and we turn yet another page in our basics diary with the hope that users are better informed of how web-enabled software spins its magic.
So a quick rundown is in order:
A web server is made of two parts: hardware (the metal part that hosts the software) and software (pieces of protocols that define interactions between server and client.
The main role of the server is to put a controlled leash on the information flow by using restriction levels of user-access as well as crafting a better user-experience through custom deployed interactions.
Lastly, server-side code can be written in different programming languages and you should choose one based on your needs. What you even have to choose which programming language to code your back-end? Heresy I call. Which one is better? What advantages do they have one over the other? All I can say is stay your finger on our blog page *wink.