I published my first npm library: nestjs-socket-presence

[SaifuddinTipu]

🏷️ Discussion Type

Product Feedback

Body

After building real-time chat platforms professionally for 5+ years, I kept solving the same problem from scratch on every project: tracking which users are online.

No dedicated npm package existed for NestJS. So I built one and published it.

---

nestjs-socket-presence

npm install nestjs-socket-presence ioredis

A drop-in NestJS module that gives you real-time user presence tracking via Socket.IO and Redis — in about 5 lines of code.

What it handles automatically:
✅ Online/offline on connect & disconnect
✅ Multi-socket per user (multiple tabs, one status)
✅ Redis TTL — ghost users auto-expire after network drops
✅ Heartbeat to keep presence alive
✅ Room presence — who's online in a named room
✅ Bulk presence — O(n) parallel Redis queries
✅ Horizontal scale safe — works across multiple pods
✅ register() + registerAsync() for ConfigService

Real-world use cases:

• Chat apps (agent availability in support rooms)
• Collaborative editors (who's viewing this doc?)
• Live dashboards (who's monitoring right now?)
• Gaming lobbies (who's ready?)

Built from production experience managing 10,000+ concurrent users on an omnichannel platform.

GitHub → https://github.com/SaifuddinTipu/nestjs-socket-presence
npm → https://www.npmjs.com/package/nestjs-socket-presence

22 tests passing. Full TypeScript. MIT.

If you've ever copy-pasted presence tracking code between NestJS projects — this is for you.

[Lopesnextgen]

Hey Saifuddin,

This is a very real pain point

Presence tracking is one of those features that looks simple until you hit the production edge cases:

• one user with multiple tabs
• mobile clients dropping without a clean disconnect
• Redis TTL cleanup
• multiple Node/NestJS instances behind a load balancer
• room-level presence
• reconnect storms
• “offline” events firing too early

So I like that this is packaged as a NestJS module instead of another copied service/gateway snippet.

The Redis-backed approach makes sense, especially for horizontally scaled apps. The multi-socket-per-user handling is probably the most important part, because naïve implementations usually mark a user offline as soon as one tab disconnects.

A few things I’d want to see clearly documented

One important security note: the quick-start example uses auth: { userId }. That is fine for a demo, but in production users should not be trusted to self-identify from the socket payload.

It would be useful to document a production pattern like:

• extract user identity from JWT/session
• validate it during the Socket.IO handshake
• map the verified user ID into presence state
• avoid trusting client-supplied userId

A few other docs/examples that would make this easier to adopt:

• Redis key prefix / namespace support for multi-tenant apps
• behavior during Redis outages
• recommended TTL + heartbeat intervals
• whether bulk presence uses pipelining/batching
• cleanup behavior for room presence after ghost disconnects
• example with @nestjs/config
• example with Kubernetes / multiple pods
• example integration with an existing authenticated gateway

Nice fit for real apps

The use cases you listed are exactly where this helps:

• support chat agent availability
• collaborative document viewers
• dashboards
• gaming lobbies
• team activity indicators

Presence is rarely the core product, but when it is wrong, users notice immediately. Having a focused package for this in the NestJS ecosystem is useful.

Overall, nice work. I’d especially emphasize the production-oriented parts in the README: multi-socket users, TTL expiry, Redis-backed scaling, and authenticated identity handling. Those are the pieces that separate this from a basic “online users array” example.