16 releases (stable)
1.6.0 | Feb 22, 2024 |
---|---|
1.4.0 | Dec 5, 2023 |
1.3.5 | Nov 17, 2023 |
0.5.0 | Jun 8, 2023 |
0.2.0 | Mar 10, 2023 |
#872 in Web programming
210 downloads per month
660KB
17K
SLoC
NetsBlox API
This project is an experiment exploring implementing a new version of the "NetsBlox cloud" in Rust.
Motivation
- The current API server has significant cruft as it was initially an attempt to reverse engineer the Snap server. They have rewritten theirs but we still have the legacy code from the original one..
- There are actually a decent number of security issues that should be fixed. The recent malicious user makes me a little cautious about this as it wouldn't be hard to try to cause problems...
- The current API is not easily testable. This would be nice to improve.
- There are some additional features that would be nice to have such as friends (important given the recent malicious user) and persistent collaboration invitations (less important).
- On that note, adding better support for external applications (such as pyblox) would be good to have. This could also help decouple some of the client and server code so NetsBlox can provide generic message routing capabilities.
- Using a strongly typed language would be nice to prevent bugs. There have been a number of bugs that wouldn't have happened if the language was compiled.
- Scalability. This should have a significantly smaller memory footprint and I expect it to scale better with respect to message passing. Ideally, this will be migrated to webRTC when possible but this is for the future.
- Unlike the NetsBlox services server, this server has relatively low churn and not many contributors. This gives us more flexibility for implementing it in something focusing more on performance rather than simply ease of contribution.
- Given the first few points, I had already been migrating to a new API within the NetsBlox server (see
src/server/api
). However, I realized that I might as well work on addressing all the points (and hopefully making it more scalable) and make a bigger refactor rather than these tiny refactors.
Dependencies
~67–100MB
~2M SLoC