Back-end Engineering Articles

I write and talk about backend stuff like Ruby, Ruby On Rails, Databases, Testing, Architecture / Infrastructure / System Design, Cloud, DevOps, Backgroud Jobs, and more...



Understanding The Communication Between Clients and Servers

Now that we know the basics about Ruby, Object-oriented programming, Text Editors, Git, GitHub, Consoles, AWS instances, and much more, it's time to explain how to connect all of these concepts. Probably this is one of the worst described things in programming, but I'll try to guide you through these complexities. 

The right questions to ask right now are:

  • * How can I show my friends the code I wrote in Ruby on the Internet?
  • * Where in the hell is my code going to live?
  • * What is a client, and what is a server?
  • * Do I need to buy a physical server?
  • * What is a host?
  • * What happens if I don't want to show my code 

Let me start with a story to explain all of these concepts. You are a Ruby developer, and you want to use Ruby On Rails to create an e-commerce site that sells cool t-shirts about Marvel. Of course, you want to have a perfect domain, like:, to show to your friends and promote through social media, but you don't know how to do that. 

Let's suppose that you have the application code ready; everything is working like a charm, but what's the next step?

Clients and Servers

First, we have to understand what is a Client and what is a Server. The Client is not the person who will buy your t-shirt, I mean, obviously, that's your Client, but in terms of computer science, a Client is a web or mobile browser. So, when you start to navigate the Internet, the first thing you do is open Google Chrome, Firefox, Microsoft Edge, or any other web browser. So, the browser is what we call the Client. 

Then when you type a search term like: "What is Ruby?" and you find a good result in Google that redirect to this link: Ruby Programming Language ( and you hit enter. Here your browser is acting as a Client, and is acting as a Server. So Ruby-lang is serving and responding with a web page. Then the web browser receives the response, and it can show you colors, buttons, links, text, images, and so on. 

So, if you want to show the world your excellent e-commerce in the link:, you've to have a server that can respond to a request made by a web browser. But what about the Domain?

Domain Names Vs. IPs

In the early Internet, instead of hitting, you had to share an IP address like: 192.345.678.1. When you shared that IP address, people could type it in the web browser and access the given page. For instance, you can use your command line to find the Facebook IP address, open your terminal, and type.

$ ping

You can see that the IP on my case is, and if I hit that number in the browser, I'll be redirected to, and I can see my Facebook timeline. 

We can say that a Domain is a mask for the IP addresses. The domains were easy to read and remember for humans, but we are hitting a given IP address behind the scenes. 

As you may already know, there are tons of domains and extensions you can buy, like:

And so on… there are tons of providers where you can buy any of these domains. There are free or even cheap domains from $12 to high-priced domains where the asking price is even a million dollars or more. Imagine how much can cost or domains. It's simple they are not for sale. Later we'll be talking deeply about domains; for now, let's suppose that we just want and is available to buy, and we make the investment. BTW, a good domain provider is NameCheap

Once we have the Domain, we can start thinking about the Server.


This is also a confusing term because your laptop or desktop computer can be set up as a server itself, so you already have the resources to host a server. However, to configure everything right and start serving on the web is not an easy task; for that reason, cloud providers like AWS, Azure, Google Cloud, and others offer these kinds of services. So what we have to do is to register there and reserve a space from a server, and then you need to "deploy" your Ruby/Rails code to that Server. 

These providers offer many different resources, but we are interested in just about instances. An instance is a space on the Server. This Server is always running, with low downtimes, and sometimes uses it for free or low prices. This is a modern and convenient way to approach today's solutions on the server-side. 

Once you create and set up the server correctly, you'll receive an IP address. Do you remember the IP addresses we show above? Here is where you can obtain one of them. Let's assume that the IP address given to you was:

It's fair to say that the Server also needs to host your database, so you have to install PostgreSQL, MySQL, or any other database Management system to keep your database there. 

How can we connect Domains and Servers?

This setup will need another blog post entry. However, we've to understand that we have to connect both of them: Domain with Server. Basically, from the domain provider (where you bought the Domain), you have to enter the IP address that was given to you in the last step. Let's assume that you purchased the Domain and you enter to NameCheap (domain provider), and you connect it with the IP

That's all; it will need a couple of minutes to propagate over the network, but once everything is ready, you can share the domain name with your friends, and they will see your fancy e-commerce and even buy something there!

Request/Response Cycle

Each time you hit enter on a link, URL, or route, you will be doing something called "request." There are many types of different requests. 

For instance, if you are displaying all the items in your eCommerce, we say that we are making a GET request because we're just reading the info hosted into the Server through our database management system (where we have all our products saved)

Seconds later, you'll receive a response with a success or a failure. 

Or, if you are in the admin section and want to create a new product for sale, you go through a form, fill out the correct data, and then save or submit the values. Here we are making three requests: 

  • * First: GET the form rendered with the fields you need to fill out. Seconds later, you'll receive a response with a success or a failure.
  • * Second: Once you hit save, we make a POST request, and that data is held on the database hosted on the Server. Seconds later, you'll receive a response with a success or a failure.
  • * Third: You'll be redirected to a confirmation page, which is a GET request because we're just reading info. Seconds later, you'll receive a response with a success or a failure.

Later you may want to update or delete a product's info, so you can go again to a GET request to display current information, then update the data and hit enter; right there, you're doing a PATCH or PUT request. Finally, suppose that you want to destroy the record, so you hit the delete button, so then you are making a DELETE request. 

Each request sends data to the server; this data can be something like this.

Method: GET
Endpoint: /all_products

200 OK

Other can be:

Method: POST
Endpoint: /admin/products/create
  •   Name: SpiderMan t-shirt
  •   Size: XL
  •   Price: 39.99
  •   Description: Lorem ipsum… 

Response 1:
Error 401 (authentication error)
This error is because we're not logged in as admin.

We log in, and then we resend the same info.

Response 2:
200 OK

As you can see, many things are happening under the hood each time you navigate through a webpage. 


What is really happening behind the scenes in each request? In the middle of the communication between the Clients (web browsers) and Servers (IP address), we have each request, and each request contains data, and one of the critical data is the protocol HTTP or HTTPS

Do you remember how to access our main page? Just hitting:, and we're there.

Let's inspect URLs

The HTTP protocol is just the way data is sent through the network. Therefore, it is unnecessary to go deeper into technical aspects because it is irrelevant. Remember is just the protocol used to send data from Clients to Servers. 

The difference between HTTP and HTTPS is the security of the last one. "S" stands for "Secure," so each client and server communication is encrypted. These encryptions are made in a secure and standard manner using an SSL issued by a Certificate Authority, so we don't have to go deeper on that either. The right message here is: if you're are going to be serious about the webpage, you have to get an SSL certificate from a certificate authority. An easy way to do this is using. Let's encrypt. Later we'll be writing something about it and doing this on our Server. 

A port is used by the Server to understand the type of protocol. This number tends to be static. For instance, for HTTP protocols, the port used by default is 80, and for HTTPS protocols, the default port is 443. 

Finally, in Rails, we'll be seeing the resource path and the queries in detail. 

What does back-end mean?

It is essential to be clear about these terms because beginners are confused. For example, all the technologies that involve the Client (web browsers) are called front-end tools and technologies. While all the technologies that affect the Server are called back-end tools and technologies. 

For this reason, front-end engineers pay more attention to design stuff, like colors, fonts, grids, usability, user experience, user interface, etc. While back-end engineers are more interested in Server stuff like cloud services, deploying code to production, saving data in databases, executing actions like Create, Read, Update or Delete resources, etc. So what's your preference here? Honestly, it depends on you! And here we're to help you understand the back-end tools and technologies a bit better. 

I think we have enough terms to study and remember, so let's keep this post simple because the only thing you need at this point is a high-level visual about the technologies and processes involved in the web page creation and usage. 

I hope you learned a lot.

Thanks for reading!
Daniel Morales