DEV Community: Shubhajit Paul

Before REST APIs Existed: How Did Software Even Talk to Each Other?

Shubhajit Paul — Mon, 26 Jan 2026 08:29:56 +0000

Before REST APIs Existed: How Did Software Even Talk to Each Other?

Let’s rewind.

Today, if one app wants data from another, we barely think about it.
We make an HTTP request.
We get JSON back.
Life is good.

But here’s the uncomfortable question most beginners never ask:

How did software communicate before REST APIs existed?
Did engineers just… email files to each other? 😄

Surprisingly, that’s not far from the truth.

Let’s build this story from the ground up.

The original problem (before APIs were even a thing)

Imagine it’s the 1970s–1980s.

You have:

One program that stores data (say, payroll)
Another program that needs that data (say, accounting)

They don’t live on the same machine.
They might not even be written in the same language.
There’s no internet as we know it.

The real problem:

“How can one piece of software get information from another without a human in the middle?”

That single question drove everything that came next.

Phase 1: Humans were the API

Before machines talked directly, people moved data.

How it worked

Program A writes data to a file
A human copies that file (floppy disk, tape, later FTP)
Program B reads the file

Why this existed

Computers were isolated
Networks were rare and slow
Simplicity mattered more than speed

Why it sucked

Slow (hours or days)
Error-prone
Not real-time
One tiny format change could break everything

This wasn’t software communication.
It was data transportation with humans as couriers.

Phase 2: Direct database access (a terrible but tempting idea)

As networks improved, developers had a new thought:

“Why not just let Program B connect directly to Program A’s database?”

Why people loved this

Fast
No middle layer
Felt powerful

Why it was a disaster

Tight coupling (change one table, everything breaks)
Massive security risks
Zero boundaries
No control over how data was used

This was like giving strangers the keys to your house instead of answering the door.

It worked… until it didn’t.

Phase 3: Remote Procedure Calls (RPC) — “Just call my function”

Now engineers tried to think like programmers again.

“What if I could call a function on another machine like it’s local?”

That idea gave birth to RPC systems.

How it worked (conceptually)

getUserById(42)

…runs on another server, returns the result.

Why it felt amazing

Familiar (function calls!)
No file copying
Faster than human-based workflows

The hidden problems

Extremely fragile
Strong dependency on language and platform
Versioning nightmares
Network failures looked like “random bugs”

You couldn’t see the boundary anymore — and that was dangerous.

Phase 4: Enterprise monsters (CORBA, DCOM, SOAP)

As companies grew, so did ambition.

“We need a standard, enterprise-grade way for systems to talk.”

The result was heavyweight frameworks that promised:

Cross-language support
Strong typing
Security
Reliability

And they delivered… at a cost.

What went wrong

Massive complexity
XML everywhere (painful, verbose, slow)
Required specialists just to understand errors
Simple tasks needed huge setup

These systems didn’t fail technically.
They failed humanly.

Developers dreaded touching them.

Phase 5: Messaging systems (asynchronous thinking)

Some engineers stepped back and asked a better question:

“Do systems really need to talk directly?”

Enter message queues.

How this changed thinking

Program A sends a message
Program B reads it when ready
No waiting
No direct dependency

This solved:

Reliability
Scalability
Spikes in traffic

But it introduced:

Eventual consistency
Harder debugging
Mental overhead

Still, it was a huge leap forward.

So why REST felt revolutionary

REST didn’t invent communication.
It simplified expectations.

REST said:

Use the web (HTTP)
Use simple verbs (GET, POST, PUT, DELETE)
Treat data as resources, not functions
Embrace statelessness
Accept that networks are unreliable

Most importantly, REST respected boundaries.

It made the cost of crossing a boundary obvious.

That was the real breakthrough.

The big lesson (this matters more than REST)

If you remember only one thing, remember this:

APIs exist because software boundaries are real and painful.

Every “old” solution failed for the same reason:

Too much coupling
Too much magic
Not enough respect for failure

REST wasn’t perfect.
It was honest.

And that honesty made it boring, predictable, and wildly successful.

Final thought (from someone who’s been burned)

Modern developers often complain about REST:

“Too slow”
“Too verbose”
“Not flexible enough”

That’s fair.

But those complaints come from people who’ve never lived without it.

Before REST, software didn’t talk.
It argued, broke, and blamed humans.

REST didn’t make systems smart.
It made them civilized.

And that’s why it still matters.

DSA Made Easy: Master These 6 Math Essentials

Shubhajit Paul — Sun, 23 Mar 2025 19:35:48 +0000

The Most Important Math Topics for DSA: A Software Engineer’s Guide to Mastering Algorithms

Hey there, fellow coder! If you’re diving into the world of Data Structures and Algorithms (DSA), you’ve probably realized that it’s not just about writing code—it’s about thinking smart. And guess what? Math is your secret weapon. I’ve been a software engineer for years, grinding through coding interviews, debugging late into the night, and building systems that hum like a well-tuned engine. Along the way, I’ve learned that a solid grip on certain math topics can make DSA feel less like a maze and more like a treasure map.

So, let’s break it down together! In this article, I’ll walk you through the most important math topics for DSA, explain why they matter, and show you how they pop up in real coding challenges. Whether you’re prepping for a Big Tech interview or just want to level up your problem-solving skills, this guide is for you. Let’s get started!

Why Math Matters in DSA

Before we jump into the juicy stuff, let’s clear the air: you don’t need to be a math genius to ace DSA. Trust me, I’m no Pythagoras. But understanding key math concepts helps you see patterns, optimize solutions, and tackle problems with confidence. Think of it like this: math is the foundation, data structures are the tools, and algorithms are the blueprints. Nail the foundation, and the rest falls into place.

Now, here are the math topics that’ll give you an edge in DSA—explained in a way that won’t make your brain hurt.

1. Discrete Mathematics: The DSA Backbone

If there’s one math topic that screams “DSA,” it’s discrete mathematics. This isn’t the calculus you might’ve dreaded in school—it’s all about discrete (separate, countable) things like numbers, sets, and graphs. Why does it matter? Because computers deal with discrete data, and DSA is all about manipulating it efficiently.

Key Concepts:

Sets and Relations: Ever wondered how hash tables work? Sets are the idea behind them—unique elements, and fast lookups. Relations help you understand connections, like in graph algorithms.
Logic: Writing a tricky if-else condition? Logic ensures your code makes sense and avoids infinite loops.
Combinatorics: Counting possibilities—like how many ways can you arrange nodes in a tree—helps with algorithm design.

Real-World DSA Example:
Imagine you’re solving a problem like “Find all subsets of a set” (a classic recursion challenge). Combinatorics tells you there are 2ⁿ subsets for a set of size n. That’s your starting point for coding an efficient solution!

2. Number Theory: Cracking the Code

Number theory studies integers and their properties—think prime numbers, divisors, and modular arithmetic. It’s like the detective work of math, and it shows everywhere in DSA.

Key Concepts:

Prime Numbers: Used in hashing algorithms and cryptography-inspired problems.
GCD and LCM: Greatest Common Divisor and Least Common Multiple are clutch for optimizing loops and finding patterns.
Modular Arithmetic: Ever seen “return result % 1000000007” in a problem? That’s modular arithmetic keeping numbers manageable.

Real-World DSA Example:
Take the “Two Sum” problem: given an array and a target, find two numbers that add up to it. Knowing divisibility and modular properties can help you optimize your approach beyond a brute-force O(n²) solution to a slick O(n) hash map method.

3. Algebra: Solving the Puzzle

Algebra isn’t just about solving for x—it’s about manipulating equations and understanding relationships. In DSA, it’s your go-to for simplifying problems and spotting shortcuts.

Key Concepts:

Equations and Inequalities: Balance time and space complexity like an equation—trade-offs are everything.
Exponents and Logarithms: Big O notation (like O(n log n)) is rooted here. Understanding logs helps you grok why binary search is so fast.
Sequences: Arithmetic and geometric progressions pop up in array problems and dynamic programming.

Real-World DSA Example:
Ever tackled a binary search problem? The reason it’s O(log n) is because each step cuts your search space in half—pure logarithmic magic. Algebra lets you prove it and feel like a wizard.

4. Probability and Statistics: The Luck of the Draw

Okay, hear me out—probability isn’t just for gamblers. In DSA, it’s about making smart guesses and handling randomness, especially in algorithms like QuickSort or machine learning prep.

Key Concepts:

Basic Probability: What’s the chance this element is in the right spot? Useful for randomized algorithms.
Expected Value: Helps you analyze average-case performance.
Permutations and Combinations: Count ways to arrange or select items—like in graph traversals or string problems.

Real-World DSA Example:
In QuickSort, picking a pivot randomly uses probability to avoid worst-case O(n²) scenarios. Knowing this can make a shaky algorithm reliable.

5. Graph Theory: Connecting the Dots

Graphs are the rockstars of DSA—think social networks, maps, or dependency trees. Graph theory is the math behind them, and it’s a goldmine for problem-solving.

Key Concepts:

Vertices and Edges: The building blocks of graphs.
Paths and Cycles: Shortest path (Dijkstra’s) or detecting cycles (DFS) rely on these.
Trees: A special graph type that’s everywhere—binary trees, heaps, you name it.

Real-World DSA Example:
Solving “Number of Islands” (a grid-based problem) is all about graph traversal. Flood fill with DFS or BFS? Graph theory guides you to the answer.

6. Recurrence Relations: The Art of Breaking It Down

This one’s a bit sneaky but oh-so-powerful. Recurrence relations describe how problems break into smaller subproblems—like in recursion or dynamic programming (DP).

Key Concepts:

Base Cases: Where recursion stops.
Recurrence Equations: Think T(n) = T(n-1) + 1 for a simple loop, or T(n) = 2T(n/2) + n for merge sort.
Master Theorem: A cheat code to analyze time complexity of divide-and-conquer algorithms.

Real-World DSA Example:
Fibonacci with DP—without recurrence, you’re stuck with exponential time. Memoize it, and boom, it’s O(n). That’s recurrence relations saving the day.

How to Learn These Topics (Without Losing Your Mind)

I get it—math can feel overwhelming. But here’s how I tackled it, and you can too:

Start Small: Pick one topic (say, modular arithmetic) and solve 5-10 problems on it.
Code It Out: Math clicks when you see it in action. Write a program to find GCD or traverse a graph.
Use Visuals: Sketch a tree or graph. Seeing is believing.
Practice on Platforms: LeetCode, HackerRank, and Codeforces are your playgrounds. Filter by topic and grind.

Final Thoughts: Math + DSA = Your Superpower

As a software engineer, I’ve seen firsthand how these math topics turn “ugh, another problem” into “I’ve got this.” Discrete math gives you structure, number theory sharpens your tools, algebra speeds you up, probability keeps you flexible, graph theory maps the terrain, and recurrence relations tie it all together. You don’t need to master everything overnight—just build a little each day.

So, next time you’re staring down a DSA problem, remember: you’re not just coding—you’re wielding math like a pro. Got a favourite topic or a killer problem you’ve solved with these? Drop it in the comments—I’d love to geek out with you!

Happy coding,
Shubhajit Paul