Programs and APIs — IT Fundamentals for Absolute Beginners

About this article

Thank you for visiting the site. This article is part 4 of the “IT Fundamentals” primers in the Architecture Crash Course for the Generative-AI Era series, and it covers programs and APIs.

In part 1 I called the part that does the work in response to an order “the kitchen”. This time we go inside it. What a program is, what people mean by programming language and framework, and what an API — one of the single most frequent words in the main series — actually is. Still with the restaurant.

What a program actually is

Roughly, a program is “an instruction sheet written for a computer”. In cooking terms, a recipe.

There is one decisive difference from a recipe for a human, though: no ambiguity is permitted at all. A human recipe can say “a pinch of salt” or “until golden brown”; a computer only ever does exactly what is written. Everything has to be pinned down: “add 1.2 grams of salt”, “heat for 180 seconds”.

The flip side is that once it is pinned down, the computer will carry out those steps hundreds of millions of times a second, without getting bored or making mistakes. Check stock, calculate the price, write it to the ledger, for every order that arrives. Running that kind of routine work at enormous speed is what a program is fundamentally worth.

Programming languages: the language of the instruction sheet

The languages you write those sheets in are programming languages.

The main series mentions TypeScript, Python, Java and others; those are all programming languages. Like natural languages, each has its own strengths and its own settings — one is good at browser-side behaviour, another at AI and data analysis, another has run enterprise systems for decades.

The main series article on “choosing a programming language” is essentially about “which language do we write this shop’s instruction sheets in”. A big deciding factor turns out to be whether you can hire cooks who write it — which makes sense the moment you picture instruction sheets written in a language almost nobody reads.

Frameworks: a commercial kitchen, pre-installed

The word you meet next most often after language is framework.

Roughly, a framework is “a commercial kitchen that arrives with the routine work already built in”.

Think about it: a great deal of what a web service does is the same in every shop. Accept an order, check whether this person is a member, shape the result into a page and return it. Writing that from scratch every time is like rebuilding the kitchen from scratch every time — obviously wasteful.

So there are prepared moulds with the routine work already in them, and the developer only writes the parts specific to their own shop. That is a framework. Names like Next.js and Rails are product names for these kitchens.

A neighbouring word is library. A library is “a box of tools for one particular job” — not the kitchen but an individual appliance. Something that only does date arithmetic; something that only draws charts. A framework “decides the structure of the kitchen”, whereas a library is “taken off the shelf when you need it”. Both appear constantly; grasping that difference in scale is enough.

APIs: the order window to another shop

The thing I most want you to take away from this article is the API. It is probably one of the most frequent words in the entire series.

Roughly, an API is “the window through which programs place orders with each other”.

In part 1 the browser placed an order (a request) with a server. That kind of exchange does not only happen between a human and a shop — it happens between shops too. Ordering in, or buying wholesale. Rather than making everything yourself, you ask a specialist.

Building your own card-payment machinery for an online shop, for instance, is hard and also dangerous. So the program places an order with a payment specialist — “please charge this amount” — and takes back only the result. Maps go to a mapping specialist, email to an email specialist. The window and the agreed format for those orders is the API.

Modern web services really are assembled out of “orders placed with specialists”. Almost nobody cooks everything in their own kitchen. When the main series says “API integration” or “calling an external API”, read it as “ah, they are ordering from a specialist”.

There are windows inside your own shop too

APIs are not only for the outside world; they are used within the shop as well.

As part 1 explained, the shop is divided between front of house (frontend) and the kitchen (backend). Handing orders from one to the other also goes through a window and a format defined as an API. Because “orders are written on this docket format” is agreed, front of house and the kitchen can be different people and still not trip over each other.

The main series has an article on “API design”, which is essentially about “how do we settle the docket format so that nobody argues about it later”. Picture a shop where the docket format was decided carelessly, and orders go astray constantly, and the importance comes through.

Common misconceptions about programming

A few misunderstandings beginners tend to carry about this world.

First, “programmers have memorised how to write everything”. In reality professionals look things up as they go as a matter of course, and mostly do not remember the fine details — much as a chef has not memorised every recipe. And now we live in an era where generative AI drafts the instruction sheet to a decent standard. Which is precisely why this series spends its pages on deciding what to build and how rather than on how to type it.

Second, “there is a settled answer for the strongest programming language”. Sadly — or happily — no universal language exists, and the reality is choosing by strength and by setting. You cannot rank a great Japanese restaurant against a great French one, and the language-selection article is framed as “which fits our shop”, not “which is strongest”.

Third, bracing yourself because “APIs are advanced, specialised technology”. As you have now read, the whole content of an API is “an agreement about an order window and a docket format”, and the mechanism itself is very plain. Being an acronym makes it sound harder than it is — an entirely understandable reaction — but when you see API in the main series you can relax and read it as “right, the window”.

Mapping to the terms used in the main series

How this connects to the main series

Programs and APIs are split across three categories in the main series: “Software Architecture” (the skeleton of the instruction sheets, and language choice), “Application Architecture” (the rules for writing them), and “Frontend Architecture” (the front-of-house side).

Software Architecture Overviewen.senkohome.com/arch-intro-software-overview/

Related articles

Summary

This article covered programs and APIs through recipes and ordering in.

A program is an instruction sheet with no ambiguity; a framework is a commercial kitchen with the routine work installed; and an API is the window through which shops place orders with each other. The API turns up absolutely everywhere in the main series, so if you take away nothing else, take away “ordering in from a specialist”.

The next primer covers the shop’s security: “security and authentication”.

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.