"What does it mean to write/run a server?" Answering My Own Questions About NodeJS

UpdatedJanuary 4, 2021

Comments (3)

The main difference between host and server is that host is a computer or another device that connects to the network while a server is a software or a hardware device that provides services to other programs or devices in the network.

Olivia Parker, IT BPO OBP IT Services

Deactivated User5y ago

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.

Anna J McDougall5y ago

Thank you! This is also very useful and well-written. For me, I was always confused as to whether 'writing/running a server' meant I had to keep my own computer on 24/7, but the existence of virtual machines seemed to be the missing piece for me.

Peter Thaleikis5y ago

Hey Anna J McDougall and Jordan Craig,

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 build or prod: npm run build (or yarn build).

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

Anna J McDougall5y ago

Thank you Peter Thaleikis!

Vivek Tiwari5y ago

Great article. Thanks for sharing, Anna.

More from this blog

How to Support Junior Developers

Ten Crucial Tips for Seniors and Leads

Jun 13, 202113 min read3.2K

Dockerising a MongoDB Microservice in Kotlin/Maven/Spring Boot

As part of my training, I'm working on creating a smaller user microservice for a fake property website. After crafting the basic controller/service/repository and the testing alongside it, we were tasked with dockerising both the application and the...

Apr 12, 20219 min read1.5K

Dockerising a MongoDB Microservice in Kotlin/Maven/Spring Boot

Learning Docker: My Tutorial Experience Part 1

I have been so excited to learn Docker. For so long, it's been a name floating around every tech space I've inhabited, but I haven't had the time to sit down and look into the details of what it is or how it works in a practical sense. Today, I took...

Feb 18, 202112 min read492

Learning Docker: My Tutorial Experience Part 1

How I Became a Junior Software Engineer in Under a Year

Today I announced my first official job as a developer after accepting a position as Junior Software Engineer with Novatec GmbH. I see this job as a long time coming, and the culmination of years of interest in technology and coding, but the truth is...

Feb 1, 202119 min read5.0K

How I Became a Junior Software Engineer in Under a Year

Interact with the Command Line using "process.argv" in NodeJS

Follow Me on Twitter @AnnaJMcDougall One of the really cool things I'm discovering about NodeJS is that it allows us to interact more directly with computers, and enables the production of tools using the CLI (Command Line Interface: you may know it ...

Jan 6, 20214 min read1.2K

Interact with the Command Line using "process.argv" in NodeJS

Anna J McDougall's Blog

25 posts

Energetic. Quirky. Helpful.

Follow Me on Twitter @AnnaJMcDougall

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?

The simplest reason, as I understand it, is that JavaScript is not a natural server-side language. Previously, we would have needed knowledge of other programming languages to do the kind of tasks we can today achieve with NodeJS. Part of the reason for this, is that NodeJS has taken the V8 JavaScript engine and put it in its own environment. Behind the scenes it uses C++ to help achieve the features which aren't native to JavaScript, but from our side JavaScript is the only thing we need to know. This is awesome because... well, it's less work to just stick to one language and it means we're able to use JavaScript alone to achieve our entire website infrastructure.

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.

Simply put, NPM uses Node to bind together features/packages/modules which can expand the abilities of our JavaScript code. NodeJS allows us to use modules in much the same way as vanilla JavaScript, including: "core modules" (globally available modules native to Node) which give us access to systems, data, and network tasks which are otherwise inaccessible; our own modules which we can write and export/import as usual; and external modules which are often commonly known as packages.

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?

Oh my sweet summer child... SO much. Not only does Node allow us to work with databases in a way which would be difficult, impractical, or downright impossible with plain client-side JavaScript, but it also allows us to work with contemporaneously unmissable features of the internet, such as user authentication. Most highly interactive and responsive web services are made significantly simpler with the use of Node: chat rooms, video streaming, and much more.

Conclusion

I'm sure I'll be writing more about NodeJS soon, because I plan to use it a lot in future, but for now let's just bask in the fact that Node allows us to bring together a whole host of features and implement them all in JavaScript. This is precisely the technological leap that was needed to allow JavaScript developers to work across the entire spectrum of web development, and for those of us who love JavaScript (hi!) that is a big deal.