When building with Claude Code or AI tools, they write real code.

There’s a difference between asking “build me an app” and understanding what was built. Without the fundamentals - it’s hard to know what to ask for and make it work.

In this article:

  • Communication interfaces (CLI vs GUI)
  • Client-server architecture
  • Communication protocols (HTTP vs WebSocket)
  • Runtime environments
  • Code organization (module systems)

CLI vs GUI - Two Ways to Talk to Your Computer

First, the basics of basics - computers can receive commands in two ways: through GUI (graphical interface) and through CLI (command line).

The terminal is where you write CLI commands - like a chat window with your computer. It’s how you communicate with software through text commands instead of buttons.

For example, mkdir project to create a new folder instead of clicking through menus, or cp to copy a file instead of right-click and paste.

Claude Code is a CLI program - you talk to it through the terminal. More examples of CLI programs: video processing with ffmpeg, package management with npm/bun, and version control with git.

What makes software a CLI? You run it with text in the terminal.

Example From My Project

I built a CLI and GUI that talk to the same data with a shared web UI. Both work on the same data and sync via WebSocket.

How the Application Works - The Server

Every application needs a server - software that listens for requests and responds. The browser (client) sends a request to the server, the CLI (client) sends a request to the server, and the server listens, processes, and responds.

The application server has two protocols:

HTTP protocol - request-response communication. The server listens for requests on a port and returns responses. A port is like an apartment number - the computer can run multiple servers in parallel, each listening on a different port.

WebSocket protocol - real-time update communication.

What Does the Server Do?

An HTTP server serves the browser two things: static files (images, CSS, HTML) and dynamic requests through an API - a standardized way for programs to communicate.

For example, an API in a task management app:

  • GET /tasks - returns task list
  • POST /tasks - creates a new task
  • DELETE /tasks/5 - deletes a task

What is WebSocket?

HTTP protocol works like letters: you send a request, get a response, the connection closes. If I want to know what changed I need to keep asking “anything new? anything new?” - this is called polling and it’s inefficient.

A WebSocket server is like a phone call: you open the line once, and it stays open. Now both sides can talk whenever they want without “calling again”.

The server can say “someone added a task!” the moment it happens, without the browser asking. All server clients receive the update simultaneously - this is called broadcast.

One Server, Two Protocols

WebSocket and HTTP complement each other: API for actions (adding tasks) and WebSocket for updates (displaying changes in the interface).

How is the server started? A server command in CLI that spins it up - starts HTTP server to handle API and files, starts WebSocket for syncing, and serves the graphical interface.

How Files Talk to Each Other - Module System

When you have many files in a program you need to export and import code between them. Doesn’t matter if it’s a website, CLI or server - whenever there’s more than one file and you need to import a function, that’s a module system.

CommonJS - the old Node.js way.

ESM (ECMAScript Modules) - the new official JavaScript standard.

Shared code between frontend and backend should use ESM because it’s the standard that works everywhere.

Where Code Runs - Runtime

Something needs to read and execute the code - Runtime is the software that does that.

Server side (backend) - code that runs on the remote server. For example, Node.js and Bun are JS runtimes on the server side.

Client side (frontend) - code that runs on the user’s machine, what they see and click. The browser is a JS runtime on the client side.

How This Shows Up in My CLI

The terminal - client (sends commands). The Web UI - client (in browser). The server - server (receives, processes, broadcasts to everyone).

I have two clients of the same server, so they stay in sync.

Beyond development, CLI has its own advantages: speed, control, working with AI agents and more - worth trying.