A workflow that runs npm ci on every push downloads the same few hundred packages from the registry each time, even when the lockfile hasn鈥檛 changed in a week. On a project with a real dependency tree that鈥檚 a minute or two gone before the first test starts, and you pay it again on every push and every pull request. actions/cache keeps those downloads between runs and hands them back when nothing relevant has changed. ...
The test suite has been green for three weeks. Today npm test fails on an assertion that has nothing to do with what you just changed, and git log v1.4.0..HEAD shows 340 commits from four people since the last release anyone is sure worked. Reading every diff costs you a day. Checking out commits at random is faster and still not a plan. git bisect turns that into a binary search. You give it one commit you know is good and one you know is bad; it checks out the commit halfway between them and waits while you test that single commit and report back. Each answer halves the range. 340 commits resolve in at most 9 tests, since 2^9 = 512. ...
What DNS actually does on every request Every request to example.com starts with a lookup that has nothing to do with your application: something has to turn that name into an IP address before a single TCP packet leaves the machine. That translation is DNS, the Domain Name System, and it runs on every request, whether the client is a browser, curl, or a backend service calling another backend by hostname. ...
What TLS actually protects on an HTTPS connection Load a page over plain http:// on a network you don鈥檛 control, an airport or a coffee-shop router, and everything you send travels as readable text. The URL path, the cookies, the form fields, the password in a login POST: anyone on that network with a packet sniffer reads it as it goes past. TLS, Transport Layer Security, is the protocol that stops that. It sits between TCP and the application protocol, so by the time HTTP starts talking, the connection is already encrypted and tied to a verified server identity. HTTPS is HTTP run over that connection instead of a plain one. ...
A checkout endpoint that resizes a product image, sends a confirmation email, and updates a recommendation engine before returning 200 OK is only as fast as its slowest step. If any one of them times out, the whole request fails. A message queue lets the endpoint hand that work off as messages and return immediately, while separate workers pick them up on their own schedule. What a message queue actually does A message queue sits between two parts of a system that don鈥檛 need to run at the same moment. A producer publishes a message describing work to be done. The queue holds it. A consumer picks it up, processes it, and acknowledges it. The two never talk to each other directly. ...
Every cloud resource you have ever clicked into existence in a web console (a VM, a load balancer, a DNS record) can also be described in a text file and created by running one command. The file lives in git, gets reviewed in a pull request, and reproduces the same setup on a second account without anyone remembering which nine settings they changed by hand. That is what Terraform does. ...
A query that takes 200ms against your database still takes 200ms the millionth time someone runs it, and every one of those runs competes for the same connections, disk I/O, and CPU. Redis keeps the answer in memory, on a server that does nothing else, so the millionth read costs a network round trip instead of a query plan. What Redis actually does as a cache Redis is an in-memory key-value store. Values live in RAM, so reads and writes measure in sub-millisecond time instead of the tens or hundreds of milliseconds a relational query costs once you add joins, indexes under pressure, or a busy connection pool. It sits next to your database, not in place of it: your application asks Redis first and goes to the database only when Redis doesn鈥檛 have the answer. ...
What sits between a browser and your app Point a browser at example.com and the request never touches the process running your code. It hits something else first: a server that reads the request, decides which backend should answer, forwards it there, and sends the response back as if it had produced that response itself. That server is a reverse proxy. Nginx, Caddy, Traefik and HAProxy all do this job, and so does the load balancer sitting in front of a Kubernetes cluster. The arrangement never changes: clients talk to the proxy and to nothing else. The real servers stay behind it, however many there are and wherever they run. ...
You pull the latest main and Git stops with CONFLICT (content): Merge conflict in checkout.js. You resolve it, and the log now shows a commit called Merge branch 'main' into feature/checkout sitting on top of the three commits you actually wrote. Four commits, one real change. A teammate reading that history next month can鈥檛 tell which is which. git merge and git rebase both answer the same question: how do I bring my branch up to date with changes made elsewhere. They leave very different traces behind, and picking the wrong one on a shared branch causes real damage. ...
docker build && docker push from your laptop works until someone else has to ship the same image, or it has to happen on every merge without you at the keyboard. GitHub Actions runs that build on GitHub鈥檚 runners, tags the image from whatever triggered the workflow, and pushes it to a registry your deploy step can pull from. Nothing runs locally. What it takes to build and push a Docker image from CI Five pieces have to be in place before a runner can push an image: ...