DEV Community: Somnath Baidya

My Experience Building a Full-Stack App (Next.js + Express + MongoDB)

Somnath Baidya — Wed, 12 Nov 2025 08:04:03 +0000

I am turning to full-stack from a frontend developer. As a React.Js developer, I wanted to stick with the javascript ecosystem. So, intuitively I picked Next.Js to smoothen the transition, reused some of my react code blocks to do so & built a few simple Node.Js apps.

Problems occurred as I built the frontend in Next.js and the backend with Express+MongoDB Compass, then deployed them on Vercel and Render separately.

I ) Deployment Failure Due to Local MongoDB Setup :

The Express + MongoDB application was deployed on Render, but it was still using a local MongoDB Compass setup instead of a cloud database.

As Render (and services like Vercels) are designed to connect to hosted databases, the deployment failed immediately.

Resolve :

I learned about the issue and created a MongoDB Atlas cluster, connected it with MongoDB Compass using the atlas connection string to access and manage the database in the cloud.

II ) Incorrect Cookie Handling in Next.js :

Initially, cookies were being set and verified in Next.js rather than in the Express backend. Since both environments were completely separate, it caused conflicts.

A quick recap :

Only the backend should create and remove secure cookies (httpOnly, secure, sameSite).
The frontend should not handle sensitive cookie logic due to potential XSS attack risks.

So the ideal way is to set and clear cookies from the backend during login and logout, while the frontend simply managed routing logic.

Also I was trying to verify cookie in Next.js Middleware, which runs in an Edge Runtime environment — not Node.js.

This environment can only check if a cookie exists, not verify it.

Resolve :

Removed app/api/session.

Only conditional redirection logic (if-else checks) was kept in middleware.js.

export function middleware(req) {
  const session = req.cookies.get("session_marker")?.value;
  const path = req.nextUrl.pathname;

  if (!session && path !== "/login") {
    return NextResponse.redirect(new URL("/login", req.url));
  }

  if (session && path === "/login") {
    return NextResponse.redirect(new URL("/home", req.url));
  }

  return NextResponse.next();
}

III ) Cross-Origin Cookie Issue :

New issue appeared as I deployed them.

While testing locally, both frontend and backend shared the same origin, so cookies persisted correctly.

But, in production:

Frontend : deployed on vercel.app.
Backend : deployed on onrender.com.

In production when a user logged in, the backend generated a cookie correctly using the firebase token. The cookie was visible in the browser’s DevTools for a fraction of sec but disappeared immediately as the page reloaded.

Now the user is redirected back to the login page, as if never authenticated.

// Login (set)
res.cookie("auth_token", token, {
  httpOnly: true,
  secure: process.env.NODE_ENV === "production",  
  sameSite: process.env.NODE_ENV === "production" ? "none" : "lax",
  maxAge: 7 * 24 * 60 * 60 * 1000, // expires in 7 days
  path: "/",
});

// Logout (clear)
res.clearCookie("auth_token", {
  httpOnly: true,
  secure: process.env.NODE_ENV==="production",
  sameSite:process.env.NODE_ENV==="production"? "none" : "lax",
  path: "/",
});

Attempts to fix the issue :

Using CHIPS (Cookies Having Independent Partitioned State).

Setting domain attributes for cookies explicitly.

But that won’t work, as vercel.app & onrender.com are completely different top-level domains

=
res.cookie("auth_token", token, {
  ....
  partitioned: true, // CHIPS
  domain: "https://mern-todo-8f4w.onrender.com/",
});

Adding proxy routes in next.config.js to simulate same-origin behaviour, which worked only on development.

/** @type {import('next').NextConfig} */
const nextConfig = {
  async rewrites() {
    return [
      {
        source: "/api/:path*",
        destination: "https://mern-todo-8f4w.onrender.com/:path*", 
      },
    ];
  },
};

module.exports = nextConfig;

The Fact :

Cross-origin cookies between different deployment domains are unreliable and often blocked by browsers.

Implementing a Hybrid JWT + Session Authentication :

Here is how it works,

1. Login request :

The frontend sends a Firebase token to the backend.
The backend verifies it using firebase-admin.
A JWT is signed with verified user details.
A sessionId is generated using crypto.
Both JWT and sessionId are sent back to the frontend, and the session is stored in the database.

2. Frontend handling :

JWT is saved in localStorage.
A client-side cookie is created containing the sessionId, used only for routing logic in middleware.

3. Middleware routing :

Checks if the sessionId cookie exists.
Redirects the user to the home page if it does, otherwise to the login/signup page.

4. Authenticated requests :

Every request includes both JWT (from localStorage) and sessionId (from cookies) in the headers.

5. Authentication in backend :

The JWT is verified.
The sessionId is checked against the database.
If both are valid, the user data is attached to the request and proceed to server.

I learned that cross-origin setups rarely have a conventional fix — you often need to experiment, blending a few ideas to obtain the right fit that works for you.

Virtual DOM & what is its role in React?

Somnath Baidya — Wed, 21 May 2025 13:15:05 +0000

First, let’s understand what is DOM: DOM stands for Document Object Model. DOM is a tree-like structure that represents the HTML elements of a webpage. It’s like a blueprint for a webpage. (i) Document- It’s the file where the HTML elements are stored. (ii) Object- Each HTML element/tag is an object. (iii) Model- The model is the hierarchy/sequence of the HTML elements.

A developer accesses this DOM to modify/change the structure, style, and content to update the webpage layout using a programming language like Javascript.

Why Virtual DOM: Direct manipulation of real DOM is slow, inefficient and reduces performance. While direct manipulation, the browser recalculates the layout of the webpage and repaints it. So multiple or small frequent DOM changes may lead to frame drop, delayed interaction or freezing. Virtual DOM resolves these issues.

What is Virtual DOM: Virtual refers to something that has the characteristics of something real but not the real thing itself. So virtual DOM resembles the actual/real DOM but is not the actual DOM itself. We can define virtual DOM like this: Virtual DOM is a lightweight, in-memory representation of the actual(real) DOM.

Role of Virtual DOM in React:

1) Initial Render: When a React component renders, it creates a Virtua DOM tree that mirrors the structure of real/actual DOM.

2) State/Props change: When state or props update, React creates a new Virtual DOM tree.

3) Diffing: Now React compares this newly generated Virtual DOM with the previous Virtual DOM to identify the differences and determine the minimal set of changes needed to avoid unnecessary updates to the real DOM.

4) Reconciliation: Only the differences like updated text and added elements are applied to the actual DOM. This is called reconciliation.

This way react avoids unnecessary rerenders & updates the webpage quickly & efficiently.

CSS conflict in React

Somnath Baidya — Thu, 29 Aug 2024 04:39:57 +0000

UI is the first step before we start typing logic to complete our front end. So we write the markup followed by the essential styles required to get the desired ui. While writing the markup we have to create meaningful class names to address and access the HTML tag and add style to it. With simple UI and distinct tags we can do so more or less easily. While writing repeating and complex UI, giving meaningful and distinct names becomes a disaster as there are only a few generic names. So we create components and style sheets for individual components. As shown below.

We can see two components, GreenContainer and RedContainer are being imported to the App.js from the components folder inside src. Their respective style sheets are RedContainer.css and GreenContainer.css, which are imported from the styles folder. Let's look at both the component and their style sheets one by one.

The first component, RedContainer.jsx

The respective style sheet is - RedContainer.css

Now have a look at the second component, GreenContainer.js -

CSS file for the second component, GreenContainer.css

Both style sheets contain distinct CSS properties for their respective components. So the expected UI outcome may be a screen where there are two blocks, one is a red square with 150px arms and another one is a green square with 200px arms. Let's have a look at the rendered React app.

Why is this happening? The CSS properties from the last container have been applied to both containers. But how? The answer is just before the React app is rendered all the style sheets are compiled into a single CSS file, where there are two class selectors with the same name - ".container" and this is why CSS properties from the last ".container{}" have been applied to all the containers globally. This issue can be fixed by using CSS Modules. CSS Modules are CSS files where all class names are scoped locally by default. This helps us in the following ways

1) Localizing the styles to specific components prevents this global scope conflict.

2) Allow the use of the same class names in different modules and promote modular styling.

To use modular styling we have to replace ".css" with ".module.css" and import 'styles' from those files.

Importing the styles to their respective components. For RedContainer -

For the GreenContainer

In general, we write className as a string like this, if the className is "container" we will write className = "container". For CSS Modules we will write the class name like this className = {styles.container} in jsx files. Now let's see the react app rendered -

Now there are no issues of CSS conflict and the styles are applied to the respective components appropriately.