Node.js and My First Web Server: Hello From the Terminal

From Tukuk-OS Wiki, the free knowledge base.

Installing Node.js, writing a ten-line web server, and discovering why using one language for browser and server changed how I build software.

For years I only built things that ran in the browser. My JavaScript was limited to static pages. When I wrote my first web server with Node.js and saw Hello from my terminal displayed on someone else's screen over the network, the boundary between "user" and "builder" collapsed at once.

Why Node.js?

My choice was simple: I already knew JavaScript. Alternatives like Python and PHP always felt heavy because I had to learn new syntax, new libraries, and new ways to deploy. Node.js let me use the functions, objects, and async/await I already knew — only this time running outside the browser.

I also liked that Node was light and fast to start. One node server.js and the server is alive. No build step, no heavy control panel. For someone learning while working with limited hardware, that time-to-start matters enormously.

Ten Lines That Changed Everything

My first server was roughly this: import http, create a server, listen on a port, send text. I ran it, opened localhost:3000, and saw my text. Then I changed the host to 0.0.0.0 so other devices on the network could access it, and my phone displayed the same page. I had my own server.

An hour later I realised anyone could access my server if they knew the IP address. That was the first time I learned about firewalls and, much later, about tunnels like Cloudflare Tunnel that eventually became the way Tukuk-OS is hosted on the internet today.

Express: The Framework That Makes Life Easy

After playing with raw http I installed Express. The first lesson: routes. app.get('/hello', handler) — that statement reads like an English sentence. I started building APIs: /api/time, /api/greet, and then APIs that called external APIs.

I also learned middleware — functions that run before a response is sent. The concept initially seemed like unnecessary layering, until I needed it for logging and rate limiting. Middleware is where my server changed from a toy into a dependable system.

Handling Errors Without Crashing

My first server would die on any error. One uncaught throw and the whole process ended. I learned try/catch not as syntax but as etiquette: every external call — API call, file read, database connection — can fail, and the server is responsible for staying alive no matter what happens.

That pattern now applies everywhere in Tukuk-OS. Every call to NASA, Bing, YouTube, or Meilisearch is wrapped in a try/catch with its own fallback, because I have seen a server die over one failed fetch in the morning.

Secrets and the .env File

In my first week I stored API keys directly in source code. It worked until I wanted to share my code with others, and at that point I had to decide whether to expose my keys to the world. The third option — moving secrets to a separate file that never enters version control — did not occur to me until I read a security guide.

The solution was a .env file: a plain text file containing KEY=value pairs, read by the server at startup, and added to .gitignore so it never enters version history. Since then every project of mine — Tukuk-OS included — uses the same pattern.

I also learned that secrets are not only API keys. Database passwords, webhook tokens, and cloud storage access keys all deserve the same treatment. And I learned that rotating a leaked key is tedious work — so avoid getting there in the first place.

How I Test a Server

At first my testing was opening a browser and seeing whether the page appeared. That worked for two or three routes, but when my server had twenty routes the method failed because I no longer remembered everything that needed checking.

I started writing a simple checklist: every time I added a new route I would test the most fragile old ones — the main search, the blog page, and the health endpoint. I also put curl into my routine, testing every route straight from the terminal without opening a browser.

One simple spread changed everything: when I added a new feature I also wrote a quick check ensuring old features still worked. Even a few basic tests gave me confidence to change code without fear of breaking something stable. The concept of "testing" I built at night later grew into a full test suite that now protects every important Tukuk-OS route.

Express in Tukuk-OS

When I started building Tukuk-OS I did not think twice about the framework. Express carries dozens of routes: search, blog, NASA, experiments, contact forms, and internal APIs. My middleware stack — rate limiting, API keys, logging — all grew out of the experience of building that ten-line server.

If you are starting out, do not wait to understand the whole Node ecosystem. Write a server that displays text, then one that reads a JSON file, then one that calls an external API. Those three steps alone will take you further than any book.

See also

• HTTP and APIs: The First Language My Server Spoke
• The Tukuk-OS Contact Form: From Click to Your Inbox
• Why I Chose Node.js and Express for Tukuk-OS