Anna J McDougall's Blog

Anna J McDougall's Blog

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

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

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.

 
Share this