Site Metrics

Jessica Brown

I have been working on a fun little project that I am looking to add as a plugin for NodeBB. This is still early stages, and a lot of code is hard coded which will change as I test and build.

I like the metrics that is in the Admin section, but it leaves a lot to build upon. Here is my current screen shots:

Currently it is pulling from NodeBB's API to gather some information, such as the user information, etc. Which I will be building more metrics on that as well.

Once I get this complete, I am hoping to be able to add it to the Admin section of the board. If not, I will have to build it with some authentication.

Anyways, let me know. What are some things that would be great to capture.

Codename: Jessica

Linux Enthusiast | Adventurer | A Unicorn!
My Site | Join the Forum

Fun Fact

Jessica Brown

OK! So I officially HATE programming for WebSockets!!!
Also it finally freaking works now...

tl;dr
Let me preface this by saying that I’m usually more on the backend and systems side of development, where things are a bit more predictable. I’m not constantly pushing or pulling data dynamically, so WebSockets haven’t been a major part of my daily grind. Most of my interactions with them have been limited to fixing something trivial like an nginx.conf issue (you know, the "why isn’t this reverse proxy working?!" moments) or tweaking configuration for an existing setup.

But then I decided to dive into actually developing a WebSocket implementation in NodeJS. Oh boy, was that an adventure. And by "adventure," I mean the kind where you’re stranded in a forest with no map, no snacks, no tent, no friends, no legs, no arms, and it’s starting to rain.

Let's take an adventure together, shall we? Here are the main pain points I’ve encountered so far:

The State Management Rabbit Hole
WebSockets are a ~~beast~~ (you know the real word I wanted to use) when it comes to managing states. You have to keep track of which clients are connected, what data they should receive, and when to clean up stale connections. It’s like maintaining a live orchestra while random musicians keep joining and leaving mid-performance.
Error Handling is a Nightmare
Oh, you thought HTTP error codes were frustrating? Wait until you try debugging a WebSocket connection that mysteriously drops, reconnects, or worse, stays open but doesn’t actually work. The lack of clear error feedback is maddening.
Concurrency, But Make It Fun... Not!
Handling multiple connections simultaneously in NodeJS isn’t terrible in theory. But in practice, juggling all these connections and ensuring they don’t block each other feels like spinning plates on fire. Forget one plate, and suddenly your server’s on the floor.
Protocol Nuances
WebSocket communication requires a careful dance of handshakes and messages. Forget one small step, and everything crumbles. I definitely spent more time than I’d like to admit chasing down handshake errors that turned out to be... drumroll... a header issue.
Testing Is a Whole Other Can of Worms
Writing tests for WebSocket functionality is challenging. Simulating client-server communication, ensuring reconnections work as intended, and validating edge cases is a slog. There’s no easy curl command for WebSockets.
Port in Use
We haven’t even started talking about port conflicts yet... Oh yeah, THAT was fun. Nothing like the good ol’ "Port 3001 in use". Wait, WHAT?! I run lsof -i :3001 to track down the culprit, and it returns... nothing. Absolutely nothing. Thanks, WebSocket! You’re really earning that love-hate badge today.

I know WebSockets are powerful, especially for real-time communication like chat apps, live notifications, or... you know... dashboards. But wow, they don’t make it easy to appreciate their elegance during development.

For now, I’ll begrudgingly admit that I’m learning a lot. But I’ll also happily admit that I’m counting down the days until this project is done.