Servers……eek! I often heard terms like ‘client’ and ‘server’ being thrown around when getting into coding. Because I was mostly focused on learning front-end development, or basically the part of a web app that the user sees and interacts with (aka, the ‘client’), I never thought about the backend, or server-side until about two weeks ago. I’m going to attempt to break down what I’ve learned.
Let’s say you’ve been working on a web application for weeks. It has some basic functionality that you are able to use by opening it up in the browser. You feel proud of yourself, and your friends who’ve seen it think it’s pretty great too. But, how can you get it to a wider audience?
A server is basically a computer that is responsible for holding onto a website (or ‘hosting’ it). As people visit that website and interact with it, that server is responsible for getting and sending out data that the people visiting the site want to use. People using the site (sometimes referred to as clients) request data from the server. The server responds to requests with a response.
Pretend your app is a site for browsing and sharing cat pictures. When you visit the site, you can browse cats in a variety of categories (“Mischievous Cats,” “Cats Sleeping,” “Cat Loaves”, “Kittens at Play,” and “Cat Hunting Conquests”). If you’re really into cats causing mischief, you might click on that album. The server is hit with a request for those pictures, and will respond with showing you all the pictures of cats causing mischief it has.
Alternately, maybe you have a cat picture you want to share on the site, such as the example to the right. In this case when you upload the photo on the website, the server is hit with a request to get your photo and store it somewhere (probably in a database). Now, other people visiting the site can enjoy the cute cat photo you posted too.
This is a basic overview, but it is essentially what happens between a server and a client. Clients can send GET requests to the server, when they are asking for data, or POST requests when they are asking the server to handle data for them.
Zoom In: Local Server
I jumped ahead to talking about external servers in the previous example. Let’s turn back the clock in the development of our cat pictures site a few weeks. Before finding an external server to host your site, most developers will want to test their site locally. This allows them to fine tune the way their app handles different types of requests, and debug anything that might change functionality when refactoring code to have a server.
When developing the front-end, you might test functionality of the site by just opening up the index.html file in your browser. But, once you develop a server, you will run it in the browser through your local host and port number. It turns out that each computer has its own server! This initially confused me because I had an image in my mind that a server was just one of those box-like machines in a datacenter somewhere. Nope, you have a local server too.
My Foray into NodeJS
I have spent the past few weeks learning how to use NodeJS to make a server. There are many resources on how to make a basic server with Node, but once it came time to actually use it I realized that I was missing some fundamentals about how they work!
Things to Remember
- Your machine’s server has a special address, http://localhost, which resolves to the IP address http://127.0.0.1.
- You must specify a port number when you make a server. Ports help computers communicate across networks. There are some port numbers that have certain rules and specifications surrounding them, but many others you can use for developing your apps at home and testing them out.
- To test out if your app is working once you’ve written it to include a server, you must START THE SERVER!!!!! This usually involves going into your command line and starting it up from the directory where your project is located. This depends on what you are using to create the server, but in Node you would type in
node app.js, where the app.js is the file where your server code is located.
In this example, you can see that this application is connected to localhost at port 3000, and it happens to be routed to the login page:
The server on your machine is great for testing out your project, but it can’t handle a bunch of visitors from the outside. In order to get your app to a wider audience, you need to basically contract out the services of another company where your project can live on its servers. I hope to discuss deploying to a server in an upcoming post.