Jssconnect

One place for every study resource my campus kept losing.

Problem

The information a student needs day to day was scattered across group chats, notice boards, and shared drives. It existed, but it lived in places that don't index and don't persist — a message that scrolls away is gone, and the same question gets asked every semester by the next batch.

What was missing wasn't storage. It was a canonical place, with a way for the people who had the material to put it there.

Constraints

• No team. One person doing product, frontend, backend, and ops. Outside pull requests arrived in bursts and needed reviewing, which is help with the code but not with the upkeep — anything needing a team to maintain was out before it was considered.
• Free tiers only. No budget for managed services that bill per seat or per query.
• Contributions from strangers. The value came from students uploading material, which is also the attack surface. Open contribution with no review would have filled it with junk in a week.

Approach

A conventional Express app rendering server-side, with MongoDB holding the resource graph. Students browse and contribute resources, and publish blog posts alongside them, so notes and write-ups live in the same place rather than in a separate tool.

• routes# resources, posts, auth
  • resources.js
  • posts.js
• models# Mongoose schemas
• middleware# Passport + moderation gate
• views# server-rendered pages

Sign-in is Google OAuth through Passport — no password storage, and a real identity attached to every contribution, which is most of the moderation problem solved before it starts.

Every contribution lands unpublished and is reviewed before it goes live. The read path only ever sees approved documents:

// The query the app makes most: approved resources, newest first.
const resources = await Resource
  .find({ approved: true })
  .sort({ createdAt: -1 })
  .limit(20)
  .lean();

Tradeoffs

• Server-rendered pages over a SPA. Cheaper to build alone and fast on a first visit, at the cost of a full page load on every navigation. For a tool students opened, grabbed something from, and left, that was the right side of the trade.
• Moderation queue over open publishing. It kept quality high and made me the bottleneck. A campus-sized user base made that survivable; anything larger would need trusted contributors.
• Free-tier hosting. Runnable indefinitely at zero cost, paid for in cold starts — the first request after an idle period is slow, and there is no way around that without money.

Outcome

It ran, and students used it through their degree. Two years on, people still recognise it — the guestbook on this site exists partly because of the ones who mention it.

Decisions

What was chosen against, and why:

• MongoDB over a relational database. Resources varied by type — notes, papers, links, each with different fields — and were read far more than written. Document storage matched the shape. Against it: no schema-enforced integrity, so consistency became the application's job.
• Google OAuth over email and password. Chosen to avoid owning password resets, hashing, and account recovery with nobody else on ops. Against it: anyone without a Google account can't sign in, which on a campus turned out to be nobody.
• Moderation before publish, not after. Reviewing first means nothing bad is ever visible; reviewing after means faster contribution and occasional embarrassment. For a platform carrying a college's name, visible junk was the more expensive failure.