DEV Community: Saleh Khatri

Streamline Your API Workflow with 2 Essential Postman Configurations

Saleh Khatri — Sun, 26 Jan 2025 11:43:02 +0000

Postman is a powerful tool for API development, but small configuration tweaks can turn it into a productivity powerhouse. Let’s explore two setups that’ll save you from repetitive tasks: auto-switching environments and hands-free token management.

1. Auto-Switch Between Dev and Prod Environments

No more manual URL changes!

The Problem

Switching between localhost (development) and your live production API endpoint? Manually updating the BASE_URL every time is error-prone and tedious.

The Solution

Add a pre-request script to your Postman collection to auto-detect the environment and set the correct BASE_URL.

Setup Steps

1. Create Environment Variables

Open Postman → Click the "Environments" tab (left sidebar).
Create a new environment (e.g., My Project).
Add two variables:
- ENV: Set value to dev or prod
- BASE_URL: Add a placeholder value like http://localhost (script will override this)

2. Add the Pre-Request Script

Go to your Collection → Go to Scripts tab → Click the "Pre-request" tab.
Paste this code:

// Get environment (default to 'dev' if not set)
const environment = pm.environment.get("ENV") || "dev";

// Set BASE_URL dynamically
if (environment === "dev") {
  pm.environment.set("BASE_URL", "http://localhost:5000");
} else if (environment === "prod") {
  pm.environment.set("BASE_URL", "https://lfsms-backend.onrender.com");
} else {
  throw new Error("Invalid environment. Set ENV to 'dev' or 'prod'.");
}

console.log(`🌐 Environment set to: ${environment}`);

How to Use BASE_URL in Your Requests

Once the BASE_URL variable is set, you can reuse it across all requests in your collection. Here’s how:

When creating a request, instead of typing the full URL (e.g., http://localhost:5000/api/login), use {{BASE_URL}} as the base.
Example: {{BASE_URL}}/api/v1/auth/login
This dynamically resolves to:
- http://localhost:5000/api/v1/auth/login in dev
- https://api.example.com/api/v1/auth/login in prod

Why This Works

The script dynamically updates BASE_URL based on your ENV variable.
Use the same request structure across environments – no more manual edits!

2. Automatically Save JWT Tokens After Login

No more manual token copying!

The Problem

After logging in, you need to manually copy the JWT token from the response and paste it into headers for authenticated requests. This repetitive work slows you down!

The Solution

Add a script to your authentication request to auto-save the token to environment variables.

Setup Steps

1. Add a Script to Your Auth Request

Open your login/sign-in request in Postman.
Go to the "Script" tab.
Paste this code in Post-response Scripts:

if (pm.response.code === 200) {
  const responseData = pm.response.json();

  // Replace 'data.token' with your API's actual token path
  pm.environment.set("TOKEN", responseData.data.token); // Token path
  console.log("🔑 Token saved automatically!");
} else {
  console.log("⚠️ Login failed: Check credentials");
}

If your API's response structure is different (e.g., responseData.access_token or responseData.token), modify the script accordingly

2. Customize for Your API

If your token isn’t in responseData.data.token:

Check your API response in Postman’s "Response" panel
Adjust the path in the script. Examples:

// If your token is directly in the root:
pm.environment.set("TOKEN", responseData.token);

// If nested under an "auth" object:
pm.environment.set("TOKEN", responseData.auth.token);

3. Use the Token in Other Requests:

In authenticated requests, reference {{TOKEN}} in headers

Why This Works

The script extracts the token/role from your login response’s JSON structure
Works for any API format – just update the JSON path to match your response
No more manual copy-pasting!

Let’s Build Better APIs Together!

I’m always curious to see how developers streamline their workflows and solve API challenges. If you tried this setup, ran into issues, or have your own Postman hacks to share, let’s chat!

📬 Find me here:
🐦 Twitter: @salehdotdev

🌐 Portfolio: salehkhatri.tech

📧 Email: salehkhatri29@gmail.com

Follow for more:
I regularly share tips on Postman automation, API development, and backend best practices. Let’s turn tedious tasks into elegant solutions!

Stuck with configurations?
If you’re wrestling with environment variables or scripting quirks, reach out! I’m happy to help troubleshoot or brainstorm ideas.

Remember: Great tools aren’t just about power – they’re about making your dev life simpler. Keep iterating, keep shipping! 🚀

Level Up Your Architecture Game with Monolithic Modular - It's Not What You Think

Saleh Khatri — Wed, 15 Jan 2025 07:16:09 +0000

Ever had that moment where your codebase feels like a teenager's room - technically organized but somehow still a mess? That was me six months ago. That's when i came across a thing called as Monolithic Modular Architecture. Despite its boring name, this approach changed everything.

You might be thinking "Oh great, another architecture article..." but I promise you this isn't about preaching the "one true way.". Instead, I want to share how this approach helped me sleep better, and actually enjoy working with our codebase again.

What's Monolithic Modular architecture?

Imagine you're building a house. Traditional monoliths are like having one giant room where everything happens (cooking, sleeping, working - chaos!). On the flip side, microservices are like having separate tiny houses for each activity.

Monolithic Modular?
It's like having one house (easier to maintain and secure) but with well-defined rooms that each serve their purpose (kitchen for cooking, bedroom for sleeping - you get the idea). Each "room" (module) has its own rules and purpose, but they're all under one roof.

In code terms, it looks like this:

The secret sauce? Each module:

Has its own clear boundary (like walls in our house)
Manages its own specific business logic
Can talk to other modules through well-defined doorways (interfaces)
Shares some common utilities (like how all rooms share the same plumbing)

But here's the best part - at the end of the day, you deploy everything together as one unit. No need to orchestrate multiple services or worry about complex network communication. It's modular where it matters (in your code) and monolithic where it helps (in deployment and operation).

Real Project Structure in Action 👀

Now that we understand the concept, let me show you how we implement this in practice with a real-world example. I'll use a typical e-commerce backend API to demonstrate.

Let me show you how this looks in an actual project. Here's a screenshot from VS Code that'll make things crystal clear:

The Key Parts Explained🎯

1. The modules Directory

Each module is a self-contained feature with its own:
controller.js (🔧 handles HTTP requests)
service.js (⚙️ business logic)
routes.js (🛣️ API endpoints)
index.js (📦 public interface)

2. Supporting Cast

middlewares/: Shared middleware like auth checks and error handlers
utils/: Common utilities (JWT handling, error classes)
prisma/: Database stuff kept neat and tidy

Why This Structure Rocks💡

Easy to Navigate: Need to fix an auth bug? Just dive into the auth module. Everything you need is right there.
New Developer Friendly: The structure tells the story. You can understand how the app works just by looking at the folder structure.
Scalable: Adding a new feature? Create a new module folder, and you're good to go. No need to touch existing code.

Common Gotchas & How to Handle Them 🚧

1. Module Boundaries

Don't Share Database Models Directly: Instead of importing Prisma models everywhere, expose specific methods through your service
Avoid Circular Dependencies: If modules A and B need each other, that's a red flag. Usually means you need to rethink your boundaries
Keep Utils Actually Useful: Don't turn your utils folder into a dumping ground. If it's specific to a module, keep it in that module

2. Dependency Management Tips

Use Module Index Files Wisely: Export only what other modules need. Not everything needs to be public
Dependency Injection is Your Friend: Pass services through constructors-makes testing easier and dependencies clear
Watch for Growing Modules: If a module is getting too big, it might need to be split. Size isn't just about lines of code - it's about responsibility

3. Practical Advice

Start with broader modules and split when needed - don't over-optimize early
Keep module names business-focused, not technical (prefer inventory over data-management)
Document module boundaries in README files - your future self will thank you
Use consistent file naming across modules - makes the codebase feel professional

Conclusion 🎯

When to Consider This Pattern

Your monolith is getting messy, but microservices feel like overkill
You want clean code organization without deployment complexity
Your team needs clear boundaries but wants to keep things simple
You're building something that might grow but don't want to over-engineer

Results After Adoption

50% faster onboarding for new team members
Easier to locate and fix bugs
Better test coverage (modules are naturally more testable)
Happier developers (seriously, no more "where does this code go?" debates)

The Journey Continues 🚀

This pattern has transformed how I think about architecture. It's not just about organizing code - it's about making development enjoyable and maintenance manageable.

I'm always excited to hear how others are structuring their applications and learn from different approaches. If you found this helpful or have your own experiences to share, let's connect!

Find me at:

🐦 Twitter: @salehdotdev

🌐 Portfolio: salehkhatri.tech

📧 Email: salehkhatri29@gmail.com

Follow me for more content about JavaScript, Node.js, and software architecture. I share regular tips and insights about building better applications!

Want to dive deeper into any aspect or need help implementing this in your project? Feel free to reach out - I'm always happy to help fellow developers level up their architecture game! 🎮

Remember: Good architecture isn't about following rules blindly - it's about making development enjoyable and maintenance manageable. Keep building awesome stuff!