Forem: Gimhan Rajapaksha

How I Secure APIs — Practical Steps I Use Every Day

Gimhan Rajapaksha — Tue, 23 Sep 2025 23:32:14 +0000

When I started building APIs, I often focused only on making features work. Security? That came later.

But the hard truth is — security can’t wait. Over the years, I’ve learned that securing APIs isn’t about one big fix; it’s about layering small but critical practices.

Here’s my step-by-step approach:

1. 🔐 Always Use HTTPS

HTTP sends everything in plain text (yes, even your passwords).
HTTPS encrypts data during transit, preventing man-in-the-middle attacks.

👉 Rule I follow: Never send sensitive data over HTTP.

2. 🔑 Authentication & Authorization with OAuth + OIDC

OAuth 2.0 handles authorization.
OpenID Connect (OIDC) adds authentication.
I enforce the principle of least privilege:
- Users only get access to the exact endpoints they need.

👉 This keeps the attack surface small and manageable.

3. 🌐 Handle CORS Securely

Early on, I made the mistake of setting Access-Control-Allow-Origin: *.
Now, I explicitly whitelist trusted domains (e.g., https://myapp.com).

👉 No wildcard * in production.

4. ⏱️ Rate Limiting to Prevent Abuse

Rate limiting protects against DDoS, scraping, or accidental overload.
I apply limits per API key or per IP/user.

👉 Example: Free users = 5 requests/sec, Premium users = 15 requests/sec.

✅ My Security Checklist

Area	Technique Used	Purpose
Transport Security	HTTPS	Encrypt data in transit
Auth/Authz	OAuth 2.0 + OIDC	Secure identity & access
Access Control	Principle of Least Privilege	Minimize exposure
Cross-Origin	CORS Whitelisting	Block unauthorized access
Abuse Prevention	Rate Limiting	Maintain availability

Final Thoughts

API security isn’t optional — it’s essential.

These practices have become my personal checklist:

Encrypt everything with HTTPS
Authenticate and authorize with OAuth + OIDC
Lock down access with least privilege
Be strict with CORS
Protect performance with rate limits

If you’re just starting out, adopt these early. Trust me, it’s a lot harder to patch security holes later.

Load Balancer vs Reverse Proxy vs API Gateway — Explained Simply

Gimhan Rajapaksha — Sun, 21 Sep 2025 23:51:55 +0000

When you’re working on scalable systems, three terms often pop up: Load Balancer, Reverse Proxy, and API Gateway.

At first, they might sound interchangeable since they all sit between the client and the backend servers. But in reality, each plays a unique role in modern system architecture.

Let’s break them down with simple explanations and comparisons.

🔹 1. Load Balancer

Main Purpose: Distributes incoming traffic across multiple servers.

Why it matters: Ensures no single server gets overwhelmed, improves fault tolerance, and boosts availability.
How it works: It checks the health of servers and routes requests to the available ones.
Extra features: Can do session persistence, round-robin scheduling, and weighted distribution.

📌 Think of it like traffic police directing cars into different open lanes so that traffic flows smoothly.

🔹 2. Reverse Proxy

Main Purpose: Acts as an intermediary between clients and backend servers.

Why it matters: Hides the server’s identity and provides an extra security layer.
How it works: Accepts the request on behalf of the server, processes it (like SSL termination), and forwards it internally.
Extra features: Caching, compression, centralized logging, security filtering.

📌 Think of it as a receptionist at the front desk — you never talk directly to the people inside; the receptionist filters and forwards your request.

🔹 3. API Gateway

Main Purpose: A specialized proxy designed for microservices architectures.

Why it matters: Manages APIs and routes requests to the correct microservice.
How it works: Handles cross-cutting concerns like authentication, rate limiting, monitoring, and even API versioning.
Extra features: Request aggregation, transformations, policy enforcement.

📌 Think of it as a smart security gate that not only lets you in but also checks your ID, enforces rules, and guides you to the right department.

✅ Quick Comparison

Feature	Load Balancer	Reverse Proxy	API Gateway
Traffic distribution	✅	❌	✅ (for APIs)
SSL termination	❌	✅	✅
Caching	❌	✅	Sometimes
Authentication	❌	❌	✅
Best for	Scaling apps	Hiding servers	Microservices

🔹 How They Work Together

These tools aren’t mutually exclusive. In many modern systems, you’ll see them combined:

A Load Balancer distributes traffic to multiple nodes.
A Reverse Proxy adds security and caching in front of those nodes.
An API Gateway manages communication across microservices.

Together, they provide scalability, security, and manageability in distributed architectures.

🔹 Final Thoughts

If you’re building or maintaining scalable systems, it’s worth understanding the unique role of each:

Load Balancer = distributes traffic efficiently
Reverse Proxy = hides and protects backend servers
API Gateway = orchestrates APIs in microservices

Student vs Startup vs Big Tech: Deployments Explained

Gimhan Rajapaksha — Fri, 19 Sep 2025 02:11:15 +0000

Ever wondered how deployment practices evolve as you move from student projects → startups → big tech?

This video breaks it down in the most entertaining way possible. Here’s the technical summary:

👨‍🎓 Student: Manual Deployment

Uploads files directly to production.
No CI/CD, no rollback strategy.
Tools: scp, FTP, or manual uploads.
Risk: High.

🚀 Startup: Structured but Manual

Environments: Local → Test → Production.
Backend: Node.js + Express.js.
Hosting: AWS EC2.
Workflow: Code pushed → tested manually → deployed manually.
Better than student level, but still fragile.

💼 Big Tech: Fully Automated

CI/CD pipelines (GitHub Actions).
Every commit triggers automated build + integration tests.
Auto-deploy to test, then to production if tests pass.
Rollback if deployment fails.
Consistent, scalable, reliable.

🔑 Key Concepts

CI/CD for automation.
Environment separation (local, test, prod).
Testing & rollback for reliability.
AWS EC2 + Node.js/Express.js for hosting & backend.

🎯 Final Thoughts

The video is not only hilarious but also a practical teaching tool:

Students see why manual deployments don’t scale.
Startups learn why staging environments matter.
Developers get a glimpse of how big tech handles deployments at scale.

👉 As your project grows, automation and testing are no longer optional. They’re essential.

⚡ Vercel Edge Functions: APIs with Sub-50ms Latency

Gimhan Rajapaksha — Thu, 18 Sep 2025 01:05:10 +0000

Modern web apps live or die by performance—and Vercel Edge Functions are built for speed. Instead of routing every request to a centralized server, your API logic executes at the edge of the network, geographically close to the user.

🔑 Key Concepts

Ultra-low latency: Sub-50ms responses possible
CDN for code: Dynamic execution at the edge (not just static caching)
Edge-first deployment: Code runs near the request origin

✅ Benefits

Lower latency → faster UX
Reduced cold starts (functions kept warm at edge)
Auto-scalable across Vercel’s infra

⚠️ Limitations

Limited runtime (no heavy native modules)
Short execution time (~10s)

🎯 Best Use Cases

Lightweight APIs
Auth & routing
Real-time transformations
Caching logic / personalization

📌 Final Takeaway

Vercel Edge Functions are ideal for fast, frequently-used endpoints where user experience depends on instant feedback. If performance is your priority, building APIs at the edge is a game-changer.

💡 Curious how they compare to Cloudflare Workers or AWS Lambda@Edge? That’ll be my next deep dive 👀

serverless #edgecomputing #api #vercel #webdev

🚀 Mastering Monorepos with Lerna + Yarn Workspaces

Gimhan Rajapaksha — Wed, 17 Sep 2025 02:46:53 +0000

Managing multiple apps and libraries can be frustrating. Luckily, Lerna makes monorepos not just possible, but actually enjoyable.

🔹 Why Use Lerna?

Let’s say you have this structure:

/root
/app1
/app2
/shared-lib
package.json
lerna.json

Your package.json might look like this:

"workspaces": { "packages": ["app1", "app2", "shared-lib"] }

Now, add Lerna scripts:

"scripts": { "start": "lerna run --parallel start", "build": "lerna run build" }

Run npm run start → both app1 and app2 start together. 🎉

🔹 Monorepo vs Polyrepo

Monorepo: All apps + libs under one root

Polyrepo: Each app/lib in its own repo

With Lerna, the monorepo approach gets easier — single place to manage dependencies, build, and publish.

🔹 Bonus: Module Federation

Even though everything lives in one repo, with Webpack Module Federation, you can still load code at runtime across apps. Think: shared components between app1 and app2 without re-building everything.

🎯 Wrap-up

Lerna simplifies building, testing, and publishing packages in a monorepo.

Yarn Workspaces optimize dependency sharing.

Module Federation keeps things flexible at runtime.

Bypassing ISP Content-Based Filters Without HTTP Injectors

Gimhan Rajapaksha — Tue, 16 Sep 2025 04:08:34 +0000

Many ISPs today offer content-based internet packages — cheap bundles that let you access apps like Facebook, YouTube, or Zoom without worrying about data overages. While attractive, these packages come with a catch: traffic outside the package is filtered, blocked, or charged separately.

Traditionally, some users have turned to HTTP Injector tools to bypass these restrictions. However, injectors bring significant downsides:

Risk of malware from shady injector apps
Dependence on free SSH accounts (often unstable, insecure, and short-lived)
Limited connection speeds and reliability

My research explores an alternative approach: SSL/TLS tunneling. Instead of relying on risky injector tools, I tested using Stunnel, which creates secure tunnels to bypass ISP traffic filters.

Here’s the basic setup:

Configure a Stunnel server on a VPS with a self-signed certificate (e.g., for cdn.zoom.us).
Add the certificate as a trusted CA on the client device.
Run Stunnel client locally to accept traffic (on a port like 8080) and re-route it securely through the tunnel.

The result? Traffic looks like normal SSL/TLS encrypted sessions, making it harder for ISPs to filter or block.

While this is just a proof of concept, it shows that tunneling techniques can offer safer and more stable alternatives to HTTP injectors when dealing with restrictive ISP filtering.

Why Freelancing Can Be the Best Move for a Software Engineer

Gimhan Rajapaksha — Mon, 15 Sep 2025 01:45:36 +0000

Working as a freelancer is more than just picking projects for money. It’s about growth.

When you freelance, every new client brings a new challenge — different tech stacks, unique business problems, and sometimes very tight deadlines. You can’t sit in your comfort zone for too long. Instead, you’re forced to adapt, learn, and solve real-world problems faster than you would in a fixed role.

Another big advantage: freedom. You choose what you work on, when, and with whom. That freedom also comes with responsibility — to manage your own time, find your own clients, and constantly level up.

Most importantly, freelancing exposes you to a diverse range of projects. One week you might be fixing a Flutter app’s performance issues, the next you’re building a Next.js marketplace. That variety keeps your skills sharp and your brain engaged.

If you’re a software engineer looking to break limits and grow, freelancing isn’t just a career option. It’s a training ground for becoming better every day.

modular architecture

Gimhan Rajapaksha — Mon, 16 Jun 2025 10:55:17 +0000