"What does it mean to write/run a server?" Answering My Own Questions About NodeJS
It's a new year, and I am thrilled to finally be dipping my toes into the waters of back-end development as my class begins to explore NodeJS. Switching mindset from front-end to back-end can be a difficult task, and I had so many questions about what Node.JS is and does in the wider field of web development.
In this post, I want to answer the questions about servers and Node.JS that the 'Anna of Yesterday' had, using the wisdom 'Anna of Today' has obtained. Hopefully, this helps others with similar questions stumbling upon this in their Google searches. Keep in mind that I myself am still new to this field and therefore, as always, the NodeJS learning platform is the best place to get official, up-to-date info.
1. I thought a server was a physical piece of hardware. What does it mean to write/run my own server?
Although the internet as a whole does involve enormous server infrastructure, there has been a move to what are called 'Virtual Machines' which are smaller, rentable units of physical server space into which you can "plug" your own server.
Nowadays, when the term 'server' is used, we are usually instead referring to a programme which, like all programmes, can be written, changed, maintained, etc. This programme's role is to interface all sorts of separate entities we need to run an effective and secure website. This includes the things we've already worked with before (i.e. the front end: click events, UI, the DOM); but also includes the myriad of items we may not be as familiar with (i.e. databases, authentication, encryption, etc.).
This was the big takeaway from me: reimagining servers not as physical locations for the storage of data, but as programmes designed to interface multiple systems which may not otherwise be capable of interacting with each other.
2. Why do we need NodeJS to do this stuff?
3. Is this the same as web hosting services?
When I think about 'virual machines' and 'interfacing', my instinct is to think in the front-end way: between us and the user. As a result, I was under the impression that the stuff described in Question 1 above was similar to paying for web hosting services. Domain hosting is actually a completely separate entity and is unrelated to writing/maintaining servers: the domain simply acts as a "mask" or entry point for the user.
4. Do I have to pay to run my own server?
As mentioned earlier, you can pay to rent virtual machines and plug your server in there. However, most people reading this are not representatives of corporations who are going to be needing that level of infrastructure. There are many smaller options for people learning, making personal projects, or just looking to host a small business website. I'll be talking more about this in the near future, but one hugely popular option is Heroku. As I've never used it before, I can't speak much to it, but you can be sure that I'll be experimenting and coming back to you with more information. The same can be said for Docker, which works differently but again, I'll bring you more in future.
5. What is the relationship between NPM and NodeJS?
If you're familiar with front-end development, and particularly if you've used React or another front-end framework, you'll already be familiar with NPM, and you may even know that NPM stands for "Node Package Manager". However, the relationship between the two might still feel nebulous.
When we use NPM in front-end development, we are (perhaps unknowingly) already using Node to bind together different features we wouldn't otherwise have access to.
6. OK fine, so we can do lots of stuff with NodeJS but... What, exactly?
I'll try to fill in some pieces to the puzzle if I may. Bear in mind I'm still learning myself so the following might not be totally correct, and maybe a little long-winded. But hopefully, you or anyone else reading will find it useful. I found understanding how servers, databases, and everything else worked to be the hardest part of learning backend development.
I find a good way to think of a server is as a program that is always running in an idle state. It waits for instructions from a client program and then processes those instructions. A client program on the other hand is started by a user, the user uses it to interact with the server, and then the user closes or stops the client program when they are done.
In the case of websites, your NodeJS server would be the server program and the client program would be the browser. Your server is always running waiting for a request. A user opens their browser and sends a request to your server by navigating to your URL. Then the server responds, typically with a webpage. The user closes their browser when they are done.
The reason the term 'server' is associated with physical hardware is that typically a server program, or programs, are the only things being run on that computer. This way the entirety of the computer's hardware can be dedicated to running the server.
You could run multiple servers on a single computer running a single operating system. The downsides to this though are that they are not isolated from each other. A security breach on one server that allows a hacker to gain access to the underlying system would also give that hacker access to any other servers running on the computer.
There is also a problem that the servers would be sharing resources such as ram, CPU, and hard drive space. This could result in a situation where one server hogs resources at the expense of another server.
This is where virtual machines come in. A virtual machine allows you to run multiple different operating systems on the same physical computer. A server running on a virtual machine is completely isolated from any of the other virtual machines running on the same hardware. Each VM can also be allotted a certain amount of ram and hard disk space to prevent any one VM hogging all the computer's resources.
usually the built-in servers are for development only. So whenever you run something along the lines of
npm run serve (or
yarn serve) it's for your work on the site, not for actual hosting.
For actual hosting of sites, you go with a different approach. Static sites are usually pre-built by the hosting service. You can also run it locally with
npm run build (or
Sites which are more dynamic are often run behind a so-called "reverse proxy" (e.g. nginx). This one is accepting connecting from the web and is calling your node app on your behalf (all on the actual web-server). No need to keep your machine running.
Terms: It pays to name things by their correct names: For example, I would refer to the local dev server as "development server" and to the server doing the actual hosting as "production or web server".
Just thought I clarify some ideas hoping to help, Peter