DevBuddy

Finding someone to build a side project with, pair on interview prep or just talk code with usually means cold messages on LinkedIn or random Discord servers. DevBuddy borrows the one interaction everyone already understands - swipe right or left - and applies it to developers: browse profiles with their skills, show interest, and once both sides agree, talk in a real-time chat. The interesting part is the backend: a REST API on Express and MongoDB that owns authentication, the connection rules and the feed logic, plus a Socket.io server for chat and AWS SES for email.

• Match developers through a simple, swipeable feed of profiles with skills, age and a short bio.
• Make connections mutual: a request is only a connection once the other person accepts it.
• Never show the same profile twice - not yourself, and not anyone you have already swiped on or connected with.
• Let connected developers chat instantly, with the conversation saved so it is still there next time.
• Keep accounts secure: hashed passwords, httpOnly cookie sessions and validation on every input.

• Sign up and log in with email and password; the session is a JWT in an httpOnly cookie that lasts 8 hours.
• Profiles: name, photo, age, gender, a 200-character bio and up to 15 skills, plus a separate change-password flow.
• Developer feed: one card at a time with Interested or Ignore; the card swipes off-screen with a Framer Motion animation.
• Connection requests: a list of people interested in you, each with Accept and Reject.
• Connections: everyone you have matched with, each with a button to open a chat.
• Real-time chat with Socket.io; messages are saved in MongoDB and loaded when the chat opens.
• Email notifications through AWS SES when someone shows interest in you, and a daily 8 AM node-cron job that looks for requests still waiting for a reply.
• Premium page with Silver and Gold plans (Razorpay checkout is in progress).

On the client, Redux Toolkit holds four small slices: the signed-in user, the feed, incoming requests and connections. Pages fetch their data once, keep it in the store, and update it locally after an action (removing a swiped card or an answered request) instead of refetching. The real logic lives on the server: MongoDB is the source of truth, the connection request is a small state machine, and every rule - who can see whom, who can accept what - is enforced by the API, not the UI.

The store

// utils/appStore.js
import { configureStore } from "@reduxjs/toolkit";
import userReducer from "./userSlice";
import feedReducer from "./feedSlice";
import connectionsReducer from "./connectionsSlice";
import requestReducer from "./requestSlice";

const appStore = configureStore({
  reducer: {
    user: userReducer,          // the signed-in developer (or null)
    feed: feedReducer,          // profiles still to swipe on
    connection: connectionsReducer, // accepted matches
    request: requestReducer,    // requests waiting for my answer
  },
});

The slices

How data flows

const userAuth = async (req, res, next) => {
  try {
    const { token } = req.cookies;
    if (!token) return res.status(401).send("Please Login");

    const { _id } = jwt.verify(token, process.env.JWT_SECRET);
    const user = await User.findById(_id);
    if (!user) throw new Error("User not found");

    req.user = user; // routes use req.user, never an id from the body
    next();
  } catch (err) {
    res.status(400).send("ERROR: " + err.message);
  }
};

const allowedStatus = ["ignored", "interested"];
if (!allowedStatus.includes(status))
  return res.status(400).json({ message: "Invalid Status type " + status });

if (fromUserId.toString() === toUserId)
  return res.status(400).json({ message: "You cannot send a request to yourself" });

// One request per pair of people, whichever way round it was sent
const existing = await ConnectionRequest.findOne({
  $or: [
    { fromUserId, toUserId },
    { fromUserId: toUserId, toUserId: fromUserId },
  ],
});
if (existing) return res.status(400).json({ message: "Connection Request Already Exist!!" });

// Reviewing: only the receiver, and only a pending "interested" request
const request = await ConnectionRequest.findOne({
  _id: requestId,
  toUserId: loggedInUser._id,
  status: "interested",
});

const USER_SAFE_DATA = "firstName lastName photoUrl age gender about skills";

const requests = await ConnectionRequest.find({
  $or: [{ fromUserId: loggedInUser._id }, { toUserId: loggedInUser._id }],
}).select("fromUserId toUserId");

const hideUsersFromFeed = new Set();
requests.forEach((r) => {
  hideUsersFromFeed.add(r.fromUserId.toString());
  hideUsersFromFeed.add(r.toUserId.toString());
});

const limit = Math.min(parseInt(req.query.limit) || 10, 50);
const users = await User.find({
  $and: [
    { _id: { $nin: Array.from(hideUsersFromFeed) } },
    { _id: { $ne: loggedInUser._id } },
  ],
})
  .select(USER_SAFE_DATA)
  .skip((page - 1) * limit)
  .limit(limit);

const getSecretRoomId = (userId, targetUserId) =>
  crypto
    .createHash("sha256")
    .update([userId, targetUserId].sort().join("_"))
    .digest("hex");

io.on("connection", (socket) => {
  socket.on("joinChat", ({ userId, targetUserId }) => {
    socket.join(getSecretRoomId(userId, targetUserId));
  });

  socket.on("sendMessage", async ({ userId, targetUserId, text, ...sender }) => {
    const roomId = getSecretRoomId(userId, targetUserId);
    let chat = await Chat.findOne({ participants: { $all: [userId, targetUserId] } });
    if (!chat) chat = new Chat({ participants: [userId, targetUserId], messages: [] });

    chat.messages.push({ senderId: userId, text });
    await chat.save();
    io.to(roomId).emit("messageReceived", { ...sender, text });
  });
});

Design decisions

• Cookies, not localStorage, for the session. An httpOnly cookie cannot be read by injected scripts, and withCredentials on Axios and Socket.io sends it automatically.
• Two layers of validation. Routes check input up front (strong password, valid email, allowed statuses), and the Mongoose schema enforces it again (name length and letters only, age 18-100, URL photos, at most 15 skills), so bad data cannot reach the database another way.
• Whitelisted profile edits. PATCH /profile/edit rejects the request if it contains any field outside an allowed list, so nobody can sneak a password or _id change through the profile form. Passwords change only through their own route, which checks the current password first.
• Never leak private fields. Every query that returns other people uses one USER_SAFE_DATA projection, so emails and password hashes are never sent to another user.
• Requests cannot be duplicated or hijacked. The duplicate check covers both directions, and a review only matches a request addressed to the logged-in user that is still interested.
• A compound index on { fromUserId, toUserId } keeps request lookups fast as the collection grows.
• Deterministic, private chat rooms. Hashing the sorted pair of ids gives both people the same room without storing a room table, and without exposing raw user ids as room names.
• Optimistic UI. Swipes and request answers update the Redux store immediately after the call, instead of refetching the whole list.