Overcoming Deployment Challenges with a MERN Stack application on Vercel

Introduction:
Deploying a MERN stack application, especially the server-side code, on platforms like Vercel can be a daunting task. Navigating through the myriad of configurations and dealing with unexpected issues can be overwhelming. In this article, I'll share the challenges I faced while deploying my MERN blog site's server-side code on Vercel and how I overcame them.

1. Configuring Vercel for Server-Side Code:
To ensure Vercel recognized my server-side code, I added a vercel.json configuration file at the root of my server code. This file directs Vercel on how to build and route requests for the server:

{
  "version": 2,
  "builds": [{ "src": "index.js", "use": "@vercel/node" }],
  "routes": [{ "src": "/(.*)", "dest": "/index.js" }]
}

With this configuration in place, any request made to my deployed application would be directed to index.js, where my server-side code resides.

2. Migrating from bcrypt to bcryptjs:
During the deployment phase, I encountered an issue with the bcrypt package. It wasn't compiling correctly, which can sometimes be a common issue due to platform-specific binary dependencies.

Solution:
To overcome this problem, I switched to using bcryptjs, which is a pure JavaScript implementation, eliminating the need for platform-specific binaries. The change was straightforward:

// Before:
// const bcrypt = require("bcrypt");

// After:
const bcrypt = require("bcryptjs");

By making this shift, I was able to seamlessly continue hashing passwords and verifying them without the compilation issues I faced with bcrypt.

2. Understanding Cookies and Security:
One of the most common issues developers face during deployment is handling cookies, especially when it comes to security configurations. I observed that while tokens were saved in the local testing environment, they weren't stored when connecting to the deployed server. After some debugging, I realized:

• Local vs Production: The difference between HTTP (local) and HTTPS (production) played a role in this behavior.
• SameSite Attribute: A warning about the SameSite attribute indicated that cross-site responses were being blocked.

Solution: By ensuring proper configurations for SameSite, I was able to ensure that tokens were saved properly.

res.cookie("token", token, {
      httpOnly: true, 
      secure: true,
      sameSite: "none", // Before:sameSite: "lax",
    });

3. Configuring CORS for Multiple Origins:
CORS (Cross-Origin Resource Sharing) policies can be a major pain point when deploying applications. I had to make sure my server accepted requests from various URLs:

• The automatically assigned Vercel URL
• My custom domain
• The default Vercel project URL
• Localhost, for testing purposes

Solution: I updated the allowedOrigins array in my server configuration, allowing requests from all these sources. However, it's essential to remember that for maximum security, it's best to limit the origins to only the necessary ones.

3. Route Order Importance:
In Express.js, the order of middleware and routes is critical. If not structured correctly, some routes or middleware may not function as expected.

Solution: By ensuring that specific routes and middleware were loaded in the correct sequence, I was able to maintain the desired functionality across the server.

Conclusion:
Deployment can often be a challenging phase in a project's lifecycle, but with persistence and a systematic debugging approach, one can resolve most issues. My experience with deploying the MERN stack blog site on Vercel taught me the importance of understanding deployment configurations and fine-tuning them according to the platform's requirements.

I hope my experience can assist others in their deployment journeys. Always remember, every challenge is a new learning opportunity.