vkjv
Joined 12 years ago
Joined 12 years ago
I didn't want to port APM code as well, so I kept node.js/express for routing. Very simple middleware that immediately passed the request and body buffer to Rust for handling. Rust returned a buffer back to express for sending the response.
It's easily able to hit 100k RPM on a single instance before hitting a CPU bottleneck in the Rust code (validating an RSA signature). It only needs to handle 90k RPM total.
In my opinion, one of the most important and most difficult parts of the job. Architecture and design shouldn't be limited to senior engineers--it won't be in practice, anyway. Doing so is a sure fire way to stilt the growth of your team.
But, reviewing designs is hard. It requires recapturing much of the context that the engineer gathered in a very short period of time. I also find it sometimes difficult to separate, "this is a fatal design flaw" from "this isn't how I would do it." I really like the suggestion of providing feedback via additional information.
Mistakes are a very important part of learning. I try to make sure everyone has the opportunity to make their own instead of making mine.
React uses the term "danger" to express a similar concept. You are trusting this value to already have been sanitized / escaped.
https://reactjs.org/docs/dom-elements.html#dangerouslysetinn...
¯\_(ツ)_/¯ I don't actually feel that strongly about a keyword that is used sparingly.
Aside: Thanks for everything you do for Rust and the community!
Of course, if you own the parent site you can replace the iFrame with anything you want.
* Progressively introduce Rust instead of replacing entire applications (Rust really shines in this area)
* Leverage node's strong HTTP and routing story while waiting for this to stabilize in Rust
* Leverage existing tooling for APM, config management, etc.
For example, one middleware verifies the request body with a signature from a header. Another one parses the body from a `Buffer` to JSON, transforms, and serializes as protobuf.