The Full-Stack Ecosystem

Workplace Context

As a junior full-stack developer at a new startup, you’ve been tasked with outlining the architecture for a new web application. The team has decided to use the MERN stack (MongoDB, Express, React, Node.js), with the frontend and backend managed in separate repositories. Before you begin scaffolding the project, your tech lead has asked you to prepare a document for the team that explains how the client and server will communicate, paying special attention to the security policies that might block requests and how to resolve them. This foundational knowledge is crucial for a smooth development process.

Lesson Objectives

• Define the MERN Stack and identify the role of each component.
• Explain the client-server model in the context of a Single-Page Application (SPA).
• Define the concepts of “origin” and the Same-Origin Policy (SOP).
• Explain what Cross-Origin Resource Sharing (CORS) is and why it is a necessary security feature in web development.

The MERN Stack

The MERN stack is a popular and powerful collection of technologies used to build full-stack web applications. It’s an acronym that stands for:

• MongoDB: A NoSQL, document-oriented database used for storing application data. Its flexibility makes it easy to store complex data structures.
• Express.js: A minimal and flexible Node.js web application framework that provides a robust set of features for building backend APIs.
• React: A JavaScript library for building user interfaces, typically for Single-Page Applications (SPAs) where the UI is dynamic and responsive.
• Node.js: A JavaScript runtime environment that allows you to run JavaScript code on the server side, outside of a web browser.

Together, these components provide a complete, end-to-end framework for developers to work with. Because they all use JavaScript (or a JSON-like query language in MongoDB’s case), the context switching is minimal, allowing for a smoother development process.

Client-Server Model for SPAs

In a traditional multi-page web application, the server is responsible for rendering and sending a new HTML page for every user request. In contrast, a Single-Page Application (SPA) loads a single HTML shell from the server and then dynamically updates its content using JavaScript.

This is the model used by React applications. The flow looks like this:

1. Initial Load: The user navigates to a URL. The server sends back a minimal index.html file, along with all the necessary JavaScript (the React app) and CSS.
2. Client-Side Rendering: The browser executes the React code, which renders the initial user interface.
3. API Requests: As the user interacts with the application (e.g., clicking buttons, filling forms), React makes asynchronous API requests to the Express backend to fetch or send data. The backend processes these requests, interacts with the MongoDB database, and sends back data, usually in JSON format.
4. UI Updates: React receives the JSON data from the API and updates the DOM to display the new information without a full page reload.

This separation of concerns—where the frontend (React) handles the presentation and the backend (Express/Node) handles the data and business logic—is a cornerstone of modern web development.

Understanding Origins and the Same-Origin Policy

To understand the most common challenge when connecting a separate frontend and backend, we first need to understand the concepts of “origin” and the browser’s security model.

An origin is defined by the combination of the scheme (e.g., http, https), hostname (e.g., www.example.com), and port (e.g., :80, :3000).

The Same-Origin Policy (SOP) is a critical security mechanism implemented by web browsers. It restricts how a document or script loaded from one origin can interact with a resource from another origin.

In simple terms: A web page from origin-A is only allowed to make requests to origin-A. It is forbidden from making requests to origin-B.

For example, if your React application is running on http://localhost:3000, the SOP will prevent it from fetching data directly from your Express API running on http://localhost:5000, because they have different ports and are therefore considered different origins.

This policy is essential for security. Without it, a malicious website could make requests to your online banking portal or email client on your behalf, potentially stealing sensitive information.

Introduction to CORS

The Same-Origin Policy is great for security, but it’s too restrictive for modern applications where the frontend and backend are intentionally decoupled and hosted on different origins.

This is where Cross-Origin Resource Sharing (CORS) comes in.

CORS is a mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin have permission to access selected resources from a server at a different origin. It’s a way for a server to say, “I know you’re from a different origin, but it’s okay for you to access my resources.”

How CORS Works

1. Pre-flight Request: For certain types of requests (e.g., those with methods other than GET/POST/HEAD, or with custom headers), the browser sends a “pre-flight” request using the OPTIONS HTTP method. This request is sent to the server to ask for permission to make the actual request.
2. Server Response: The server receives the pre-flight request and responds with a set of CORS headers, such as:
   • Access-Control-Allow-Origin: Specifies which origins are allowed. (e.g., http://localhost:3000 or * for public access).
   • Access-Control-Allow-Methods: Specifies which HTTP methods are allowed (e.g., GET, POST, PUT, DELETE).
   • Access-Control-Allow-Headers: Specifies which custom headers are allowed.
3. Actual Request: If the pre-flight response headers grant permission, the browser then sends the actual API request. If not, the browser blocks the request and throws a CORS error in the console.

In an Express application, this is typically handled by the cors middleware, which automatically adds the appropriate response headers.

// Example of using the cors middleware in Express
const express = require('express');
const cors = require('cors');
const app = express();
 
// Allow requests from a specific origin
const corsOptions = {
  origin: 'http://localhost:3000'
};
 
app.use(cors(corsOptions));
 
app.get('/api/products', (req, res) => {
  res.json({ message: 'This is a CORS-enabled endpoint!' });
});
 
app.listen(5000, () => console.log('Server running on port 5000'));

Activities

Activity 1: Diagramming Data Flow

• In small groups, draw a diagram that illustrates the complete MERN stack architecture.
• Trace the path of a user action (e.g., “add a to-do item”) from the React UI, through the Express API, to the MongoDB database, and back to the UI.
• Label each step with the technology responsible and the data format being used (e.g., JSON).

Activity 2: Monorepo vs. Polyrepo Discussion

As a class, discuss the following question:

“What are the pros and cons of keeping the client and server code in the same repository (a monorepo) versus separate repositories (a polyrepo)?”

Here are some of the pros and cons to consider:

• Pros of Monorepo: Simplified dependency management, atomic commits across frontend/backend, easier code sharing.
• Cons of Monorepo: Can become large and slow, couples deployment pipelines, may require more complex tooling.
• Pros of Polyrepo: Clear separation of concerns, independent team workflows, independent deployment schedules.
• Cons of Polyrepo: Difficult to share code, can lead to versioning conflicts, more complex to set up a unified development environment.

Summary

In this lesson, we established the foundational architecture of a MERN stack application. You learned how the client-server model works in the context of a React Single-Page Application, where the frontend is decoupled from the Express backend. We explored the browser’s Same-Origin Policy as a critical security feature and understood why it prevents requests between different origins (e.g., localhost:3000 and localhost:5000). Finally, you were introduced to Cross-Origin Resource Sharing (CORS) as the standard mechanism for relaxing this policy, allowing servers to explicitly grant permission to clients from different origins to access their resources.

References

• MDN Docs: Cross-Origin Resource Sharing (CORS) 
• MDN Docs: Same-Origin Policy 

Additional Resources

• Express cors middleware package
• A Guide to the MERN Stack