DEV Community: Akshay Chauhan

MVC Architecture

Akshay Chauhan — Fri, 28 Feb 2025 12:38:55 +0000

When it comes to building robust and maintainable applications, the Model-View-Controller (MVC) architecture is one of the most widely used design patterns. It’s a blueprint that helps developers organize code in a way that separates concerns, making applications easier to manage and scale. To better understand how MVC works, let’s dive into its three core components—Model, View, and Controller—using the analogy of a restaurant. Imagine the MVC pattern as a restaurant where the Model is the kitchen staff, the View is the dining area, and the Controller is the waiter. Together, they ensure a seamless dining experience—or in the case of software, a smooth user experience.

1. The Model: The Kitchen Staff

The Model is the backbone of the application. It represents the data and the business logic—the rules that govern how data is created, stored, and manipulated. Think of the Model as the kitchen staff in a restaurant. They are responsible for preparing the meals (data) based on the orders (requests) they receive. The kitchen staff doesn’t interact directly with the customers (users), but they ensure that the food is cooked to perfection and delivered on time.

In technical terms, the Model handles database interactions, data validation, and any calculations or transformations required by the application. For example, if a user submits a form to create an account, the Model will validate the input, save the data to the database, and ensure everything is stored correctly. Importantly, the Model operates independently of the View and Controller. It doesn’t care how the data is displayed or how the user interacts with it—it just focuses on managing the data.

2. The View: The Dining Area

The View is what the user sees and interacts with. It’s the presentation layer of the application, responsible for displaying data in a user-friendly format. In our restaurant analogy, the View is the dining area where customers enjoy their meals. The customers (users) don’t see the kitchen (Model) or the behind-the-scenes work—they only see the final product (the meal) presented to them.

In software terms, the View takes data from the Model and renders it into a webpage, mobile app screen, or any other user interface. For instance, if a user requests a list of products, the View will display that list in a visually appealing way. The View doesn’t manipulate the data—it simply presents it. However, it can send user inputs (like button clicks or form submissions) back to the Controller for processing.

3. The Controller: The Waiter

The Controller acts as the intermediary between the Model and the View. It’s like the waiter in a restaurant who takes orders from the customers, communicates them to the kitchen, and then delivers the prepared meals back to the customers. Without the waiter, there would be no connection between the dining area and the kitchen.

In an application, the Controller handles user input, processes requests, and updates the Model or View accordingly. For example, if a user submits a search query, the Controller receives the request, fetches the relevant data from the Model, and then passes that data to the View for display. The Controller ensures that the Model and View remain decoupled, meaning they don’t directly interact with each other. This separation of concerns is what makes MVC such a powerful and flexible design pattern.

Why MVC Matters

The MVC architecture is more than just a way to organize code—it’s a philosophy that promotes clean, maintainable, and scalable applications. By separating the application into three distinct components, developers can work on individual parts without affecting the others. For example, you can update the user interface (View) without touching the business logic (Model), or change the data storage system (Model) without disrupting the user experience (View).

Here’s a quick summary of the key benefits of MVC:

Separation of Concerns: Each component has a specific role, making the code easier to manage and debug.
Reusability: Models and Views can often be reused across different parts of the application.
Scalability: MVC makes it easier to add new features or modify existing ones without breaking the entire system.
Collaboration: Developers, designers, and database administrators can work on different parts of the application simultaneously.

The MVC architecture is a timeless design pattern that has stood the test of time. Whether you’re building a simple website or a complex enterprise application, understanding and implementing MVC can save you countless hours of frustration. By separating your application into Models, Views, and Controllers, you create a structure that is not only easy to maintain but also adaptable to future changes.

What is CORS? : Explained

Akshay Chauhan — Mon, 17 Feb 2025 06:10:57 +0000

Understanding CORS: A Complete Guide

If you've ever built a web application that fetches data from another domain and encountered a CORS error, you're not alone! This guide will break down CORS, why it exists, how it works, and how to fix common CORS issues.

What is CORS?

CORS (Cross-Origin Resource Sharing) is a security feature implemented by web browsers to restrict how resources are requested from different origins (domains, protocols, or ports). It prevents malicious websites from making unauthorized requests to a different domain on behalf of the user.

For example, if your frontend is hosted on https://myfrontend.com and tries to fetch data from https://api.mybackend.com, the browser blocks the request unless the backend explicitly allows it.

How CORS Works

To better understand how CORS works, it's helpful to look at a diagram. Consider a web page hosted on Domain A that wants to request data from a server hosted on Domain B.

When Domain A makes an HTTP request, the browser asks the server on Domain B if it can send the request from Domain A. This confirmation request is called a Preflight request.

The server on Domain B confirms whether it accepts requests from Domain A or not through CORS Headers (e.g. Access-Control-Allow-Origin, Allow-Control-Allow-Method, etc). Once the preflight request is successful, the browser makes the request to Domain B.

Let's say in another scenario the server on Domain B didn't allow any requests from Domain A. In that case, the browser blocks the request and returns an error. Hence Domain A is unable to access the said resource from the server on Domain B. That's precisely what CORS is.

History of CORS

Before CORS, web security relied on the Same-Origin Policy (SOP), introduced in the 1990s to prevent unauthorized access between different domains. The Same-Origin Policy restricted JavaScript from making requests to a domain different from the one that loaded the script.

The restriction protected user data, but also limited functionality, making it difficult for web applications to interact with APIs from different domains.

Why Was CORS Introduced?

As web applications became more dynamic and started integrating with third-party services (like APIs, cloud storage, and payment gateways), the Same-Origin Policy became too restrictive.

To allow safe cross-origin requests while maintaining security, browsers introduced CORS (Cross-Origin Resource Sharing) in the late 2000s.

CORS provides a way for servers to explicitly allow or deny requests from other domains using HTTP headers.

Major Security Incidents Before CORS

1. Cross-Site Request Forgery (CSRF) Attacks

Before CORS, attackers exploited CSRF vulnerabilities to trick users into performing unwanted actions on other websites where they were logged in.

🔴 Example: A Banking CSRF Attack

1️⃣ A user logs into their banking website (bank.com).
2️⃣ The user visits a malicious website (evil.com) in another tab.
3️⃣ The malicious website automatically sends a request to bank.com to transfer money, using the user's active session.
4️⃣ The banking website executes the request because it thinks the request is from the user (since the browser includes session cookies automatically).
5️⃣ Money is transferred without the user's knowledge!

🚨 Impact: Millions of dollars have been stolen using CSRF attacks on banking websites before proper security measures like CORS and CSRF tokens were widely implemented.

2. Data Theft via JSON Hijacking

Many websites used JSON data formats to transfer sensitive information. Before CORS, attackers could use malicious JavaScript to steal private JSON data.

🔴 Example: A JSON Hijacking Attack on a Shopping Website

1️⃣ The victim logs into shopping.com.
2️⃣ The attacker tricks the victim into visiting evil.com.
3️⃣ evil.com runs a malicious script that fetches order history from shopping.com.
4️⃣ Since browsers automatically attach authentication cookies, the request is successful.
5️⃣ The hacker now has access to the victim's shopping history and personal details.

🚨 Impact: Before CORS, many websites leaked sensitive user data because they did not restrict who could request their JSON APIs.

How CORS Works (With a Simple Analogy)

Think of a CORS request like trying to enter a restricted area:

1️⃣ You (frontend) want to visit a restricted building (backend API).
2️⃣ Security (browser) stops you and asks if you have permission.
3️⃣ The building manager (server) checks their records and says:

✅ "You're allowed!" → You enter.
❌ "You're NOT allowed!" → You're blocked.

This "permission" is handled using CORS headers in HTTP responses.

When a browser makes a cross-origin request, the server must include special headers in its response to allow the request.

Key CORS Headers and What They Do

Header	Purpose	Example
Access-Control-Allow-Origin	Defines which domains can access the resource	Access-Control-Allow-Origin: * (Allows all)
Access-Control-Allow-Methods	Specifies allowed HTTP methods	Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers	Lists allowed custom headers	Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age	Caches preflight response (reduces requests)	Access-Control-Max-Age: 86400 (24 hours)

Understanding Preflight Requests

Some CORS requests require an extra step called a preflight request.

When is a Preflight Request Sent?

If the request uses HTTP methods other than GET or POST (like PUT, DELETE).
If custom headers (e.g., Authorization) are included.
If sending non-simple content types (e.g., application/json).

How Preflight Works (Step by Step)

1️⃣ The browser first sends an OPTIONS request to check if CORS is allowed.
2️⃣ The server responds with CORS headers (if allowed).
3️⃣ If permitted, the browser sends the actual request.

Example Preflight Request:

OPTIONS /data HTTP/1.1
Origin: https://frontend.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type

Example Server Response:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://frontend.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type

How to Fix CORS Errors

✅ Solution: Add CORS Headers to the Server

Example: Fixing CORS in a Node.js Server:

const express = require('express');
const cors = require('cors');
const app = express();

app.use(cors({
    origin: 'https://myfrontend.com',  // Allow only specific origin
    methods: ['GET', 'POST', 'PUT', 'DELETE'],
    credentials: true
}));

app.listen(3000, () => console.log('Server running on port 3000'));

Final Thoughts

CORS is not just a technical headache — it's a vital security measure that prevents hackers from misusing your web applications. While it may seem annoying when developing web apps, proper CORS implementation ensures user safety and data protection.

Tags: #webdev #security #javascript #programming #cors

Mastering GET and POST in APIs: Route Params VS Query Params

Akshay Chauhan — Fri, 14 Feb 2025 03:04:02 +0000

Understanding the differences between GET and POST methods, along with the proper use of query parameters (req.query) and route parameters (req.params), is crucial for bET vs. POST: The Core Differences

GET Method

GET requests are used to retrieve data from the server. They're like asking a question - you're not changing anything, just requesting information.

// Client Request:
fetch('https://api.example.com/users?id=123');

// Server:
app.get('/users', (req, res) => {
const { id } = req.query; // Access query params
res.send(`User data for ID: ${id}`);
});

Key characteristics:

Data is passed through the URL as query parameters
Idempotent - multiple identical requests won't change server state
Perfect for data retrieval operations

POST Method

POST requests are used when you want to send data to create or update resources on the server.

// Client Request:
fetch('https://api.example.com/users', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ name: 'John', age: 30 }),
});

// Server:
app.post('/users', (req, res) => {
const { name, age } = req.body; // Access POST body
res.send(`User ${name} created, age: ${age}`);
});

Understanding Route Parameters (req.params)

Route parameters are part of the URL path and are perfect for identifying specific resources. They're defined using colons (:) in the route definition.

// Route definition:
app.get('/user/:id', (req, res) => {
const { id } = req.params; // Extract ID from route
res.send(`User ID: ${id}`);
});

// Client Request:
fetch('https://api.example.com/user/123');

In this example, 123 becomes the id parameter - making it ideal for required resource identifiers.

Working with Query Parameters (req.query)

Query parameters come after the ? in a URL and are perfect for optional data or filtering.

// Route definition:
app.get('/users', (req, res) => {
const { rate_limit, page } = req.query; // Extract query params
res.send(`Rate Limit: ${rate_limit}, Page: ${page}`);
});

// Client Request:
fetch('https://api.example.com/users?rate_limit=50&page=2');

Combining Both Approaches

You can use both route and query parameters together for more specific requests:

// Route definition:
app.get('/user/:id', (req, res) => {
const { id } = req.params; // Route param
const { details } = req.query; // Query param
res.send(`User ID: ${id}, Details: ${details}`);
});

// Client Request:
fetch('https://api.example.com/user/123?details=full');

Quick Reference Table

Feature	Route Parameters (`req.params`)	Query Parameters (`req.query`)
Purpose	Identify specific resources	Provide additional information
Location	Defined in URL path	Appended after `?` in URL
Required?	Yes	No
Example	`/user/:id`	`/users?rate_limit=50`

Best Practices

Use route parameters (req.params) for:
Mandatory resource identifiers
User IDs
Product IDs
Essential path components
Use query parameters (req.query) for:
Optional filters
Pagination
Sorting preferences
Additional options
Always document your endpoints thoroughly
Include example requests
List all possible parameters
Explain parameter constraints

Wrapping Up

Understanding when to use route parameters versus query parameters is crucial for creating intuitive and maintainable APIs. Route parameters excel at resource identification, while query parameters offer flexibility in data retrieval. Together, they create a powerful toolkit for API design.uilding effective RESTful APIs. Let's break down these concepts with practical examples!