Because of its open source nature, NetEye 4 combines loads of different technologies, which makes it impossible to identify “the” NetEye 4 Tech Stack. Based on RHEL/CentOS 7, most of the user-facing parts are written in, or at least proxied through, PHP, whereas there is no real common denominator for other backend services. This looks very traditional, however in the last year or so, there has been a noticeable shift in favor of two compiled, strictly typed languages.
Backend: Rust
Since the introduction of Tornado, our Complex Event Processor (CEP) we’ve fallen deeply in love with the Rust Programming Language, which incidentally was called the “Best Chance at Safe Systems Programming” by Microsoft a few days ago.
For us the main selling points of Rust that lived up to their hype in real use-case scenarios, were mainly:
- Memory Safety – Often misunderstood as “Rust Programs don’t crash”, or “Rust Programs don’t leak memory”, both of which are false. However, it does mean that because of its ingenious ownership system, a whole class of security-critical bugs can inherently not be created when using (safe) Rust. In a recent analysis of the Chromium codebase (nearly all C++), they concluded that ~70% of their security-related bugs are due to memory safety issues.
- Powerful Type System – Admittedly it’s not perfect (yet), but one of the major advantages is the possibility to shift a lot of logic onto the type system, which gives me the peace of mind that whenever it compiles, it works. Generics on the other hand reduce the repeated boilerplate to a minimum, but still allow for easy extensibility. Also, refactoring is a lot less scary.
- Performance – This is probably the easiest to explain. Parsing millions of events, and handling hundreds of thousands of checks, requires a language with a certain level of speed.
Frontend: TypeScript
Since we started implementing the GUI for Tornado, Rust got a new friend on the frontend side: TypeScript. Typescript is basically JavaScript with a (kind of optional) strict type system, and the result of the compiling process is cross-browser compatible vanilla JavaScript.
This allows not only for seamless interoperability with legacy JS-only code bases, but also for much nicer IDE support and, most importantly, additional compile-time guarantees when working with types, resulting in overall a more pleasant-to-work-with and future-proof code base.
Cue Vue.js
For the Tornado GUI and the Würth Phoenix Design System we use the Vue.js MVVM framework, allowing for a clean separation between the business logic with data and the presentation layer with presentation logic. This separation keeps the code clean and readable, minimizes side effects, and thus makes refactoring or future extensions easier.
The Result is Greater than the Sum of its Parts
Generally speaking, each technology gives us noticeable advantages when looked at in isolation. When you combine them and look at the big picture, however, there are synergies which have a positive influence.
The greatest addition for sure from my perspective is the strict typing from top to bottom and having verifiable API boundaries. We’re able to generate typed object bindings called DTOs such that in the case of a RestAPI, the exchanged request and response JSON objects can be shared and verified at compile time both on the frontend and the backend.
Obviously all of this comes with a cost, as the young ecosystem especially of async Rust lacks mature libraries. Also, the introduction of new concepts which come with each language will slow productivity down significantly for the first few weeks. This however is compensated for multiple times over by the significant amount of time saved by avoiding bugs.
For now this stack has proven itself to be a solid choice for our use cases. I’m confident that both Rust and Vue.js/TypeScript will grow in popularity, where wider usage will iron out their still quite rough edges.
Benjamin Gröber
Author
