> For the complete documentation index, see [llms.txt](https://blockchain-journal-hope-mabuza.gitbook.io/blockchain-journal-hope-mabuza-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://blockchain-journal-hope-mabuza.gitbook.io/blockchain-journal-hope-mabuza-docs/backend/understanding-node.js.md).

# Understanding Node.js and Servers

**Why Node.js Exists**

I had been using JavaScript on VS Code to write deploy scripts and unit tests for my smart contracts without ever stopping to understand how it actually works. Now that I'm learning backend, I want to fix that.

JavaScript was initially created to run in the browser, which meant developers couldn't run or test their code locally. The only way to see it work was to attach it to an HTML file and open it in a browser. That was limiting. Developers eventually built a way for computers to understand JavaScript outside the browser, and that's where Node.js came from. It's a runtime environment that executes JavaScript locally and gives it tools to interact with the outside world.

**What Node.js Makes Possible**

<figure><img src="/files/7MbZrZ5GZTga9lh9Hy3N" alt=""><figcaption></figcaption></figure>

Node.js allows us to use **packages** (tools others built so we don't have to), **frameworks** that give structure to an app, **servers** to handle requests and responses, and **databases** to store data, all using JavaScript.

That's also why I had to install Node before building my smart contracts. But the piece that matters most for this part of the journey is **servers**, and before writing one I had to understand how servers actually communicate.

**HTTP**

Servers use HTTP (HyperText Transfer Protocol), which is a set of rules for how a client like a browser or a dApp frontend sends a request, and how a server sends back a response. Every time your dApp calls a backend or reads from the blockchain through a provider, that's HTTP under the hood.

**HTTP Requests**

HTTP requests come in different types depending on what you want to do. Think of it like interacting with a blockchain explorer: you're either reading data or writing it.

* **GET** — read something. (Fetch a wallet's token balance)
* **POST** — create something new. (Submit a new NFT listing)
* **PUT** — update something that already exists. (Update a user's wallet profile)
* **DELETE** — remove something. (Remove a wallet from a watchlist)

**Status Codes**

The server always replies with a status code, a number that tells you whether things went well or not. The ones I kept seeing:

* **200** — OK. Request worked.
* **201** — Created. Something new was made.
* **400** — Bad request. You sent something wrong.
* **401** — Unauthorised. Not logged in or wallet not verified.
* **404** — Not found. That route or resource doesn't exist.
* **500** — Server error. Something broke on the backend.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://blockchain-journal-hope-mabuza.gitbook.io/blockchain-journal-hope-mabuza-docs/backend/understanding-node.js.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.