Regrettably, I’m going to be dropping support for BridgeNet. I might release v2.0.0- maybe I will, maybe I won’t. I know I’ll at least release the W.I.P. code I have right now the second I know it’s stable.
Here’s why I’m dropping support:
I’ve come up with a better way of reducing Roblox’s overhead.
This new way takes only 2 bytes for subsequent calls to the same bridge- but it has 7 bytes of overhead per bridge too. The thing is, I’d have to re-write ServerBridge.luau
Messy code
I’m not going to lie, BridgeNet was built upon a prototype. Just a showcase that it’s possible. There are many instances of messy, disorganized code in BridgeNet’s codebase.
Flawed API
The API that BridgeNet has right now, is extremely flawed.
Firstly, it is designed to be slow. Call times can be disturbingly high when there are lots of players- particularly with functions like :FireAllInRange(). The API also has messy interaction with the internal queue system that BridgeNet has.
Secondly, it is messy. There are tons of :Fire() methods on ServerBridge, and the way of creating the Bridge object is awful. CreateBridgeTree is a symptom of these problems- but the layer of abstraction it gives is nothing more than a thinly veiled property setter. There are tons of things I could have done better- made namespaces better, made differentiating client vs. server better, and made the overall API better.
Bad error handling
BridgeNet has awful error handling. The second something goes wrong, the output is instantly spammed to hell- this is because BridgeNet manipulates the contents of what you send. It shouldn’t do that. There are better ways of handling this.
BridgeNet doesn’t provide much, apart from bandwidth reduction
This is my biggest pet peeve. If you look at Knit, EasyNetwork, and RbxNet, they all provide something: A cleaner way of doing networking, a better way, one with rate limiting, middleware, a nice interface, and all that- BridgeNet doesn’t do that. It’s a barebones object-oriented wrapper around RemoteEvents, with a cool queueing feature built-in, and some other neat party tricks.
BridgeNet wasn’t designed to be production-ready
There are so many points of failure in BridgeNet, and so much unsafe code, I don’t think that getting to a production-ready state would be possible. Every single time I add a feature, I break a few unrelated features. While automated testing is very nice, it’s not going to help BridgeNet’s source code. It’s not going to remove the awful points of failure. (I’m definitely taking the framework @sinlernick set up in a PR though)
I can do better, and I will do better
I’ve decided to make BridgeNet2. It’s a completely rewritten version of BridgeNet, designed in a way that showcases the new method I talked about in reason 1. It’s going to be written clean from the start- not based on a prototype. Its API will be written in a way that’s both intuitive, and type-safe, and it won’t care about packet contents. This means better error handling- a better API means BridgeNet2 will provide something. It will mean BridgeNet2 can be production-ready.
Well damn… I am now beginning to regret using your library… I have created a game using your BridgeNet as it was easy to use and set up… and my progress in the game has gone too far now. I’m still hoping to get new update fixes for the bugs I have found but, either way, time to re-write now.
You won’t be re-writing much. I’ve already made quite a bit of it, and it’s looking to be pretty easy to migrate from this version to the new version- it’s mainly identifiers & the creation of bridges that are changed, alongside a few other small changes.
It should be just as easy to use and set up- if not easier.
Very excited for this. I wish more devs had the gumption to overcome the sunk cost fallacy and start anew with the lessons learned in previous projects. Bridgenet 1 was a great resource and I can’t wait to see what comes next.
Ps
One feature I’d love to see is middleware that affects all bridges. I’d like to setup naieve authentication with server authoritative rotating keys attached to each player which is sent in every bridge to make exploiting mildly more annoying
Hey man, your resource is awesome nonetheless, very excited for BridgNet 2! - I’m personally using your module for a large dinosaur game, had no issues and the results it has provided me is just insane, really able to push the boundaries of server performance with a lot of players thanks to your module.
Much love, your decision is respected and we’re all going to stick with you and BridgeNet’s journey.
Will the new module provide benefits other networking modules provide? I want BridgeNetV2 to give us all the benefits of all other good networking modules and yet be good for bandwidth usage. Is this the case already or are you going to see how much benefits you can implement from other good networking modules?
An example of this would be rate limiting and etc.
Something the other modules do good is rate limiting and I really want BridgeNet to provide this benefit as well!
Can’t wait!
Kind of bummed out that I only just looked at this even though I implemented a few things around it.
Though it is good I made a wrapper of your wrapper so converting over will be seemless for the most part. Looking forward to it, design well and code cleanly my good sir
I’ve been using BridgeNet for a few projects because it is painful to manage RemoteEvents with Rojo, had a really great time using the module so I look forward to seeing the v2.
Also, is this a feature list of things implemented right now? That would be really impressive.
Regardless, thank you for making BridgeNet.
I’ll be sure to check out the 2nd one but for now will be using this
