search

zacharygolba / via

A multi-threaded async web framework for people who appreciate simplicity.
Apache License 2.0
1 stars 0 forks source link

Maintain REST compatiblity #51

Open zacharygolba opened 3 days ago

zacharygolba commented 3 days ago

In order to remain compatible with REST APIs, we'll need to return a Result<Vec<Found>, Error> from the visit method in via-router. This will allow us to either respond with an 500 Internal Server Error or (my preference) shutting down the server if the router's memory becomes corrupt for any reason. Since there isn't necessarily a warm-up time for a Rust binary, crashing the server and starting over is likely the safest option that also results in the most requests being served successfully in the long-term. This approach would allow applications to continue to serve requests after a power surge without having to immutably replace the node in the cluster. We would still recommend using frequent restarts as metric that can be used to remove a node from a cluster or load balancer for the sake of security. In the future, we could potentially introduce a feature-flagged integrity check to the router to ensure that routes have not been deliberately replaced in memory with some arbitrary function. Until then, the same goes for Via as for any other web server framework. It's only as secure as the hardware on which it runs.

We could introduce the proposed change to via-router without making a breaking change by introducing a try_visit method with the aforementioned return value in the function signature. Otherwise, we can bump the version to 3. I'm not afraid of breaking changes as long as we follow semantic versioning.

zacharygolba commented 3 days ago

It's worth mentioning that this is particularly tricky since we recommend the multi-threaded runtime. We can likely solve this with some sort of message passing between the outer select branch and the service struct that calls the router. I'm hesitant to repurpose the watch channel used for graceful shutdown because I think we'll want the messages to flow in the opposite direction.

zacharygolba commented 3 days ago

We may also want to provide the option to opt out of crashing the server. I think we'll want to initiate a graceful shutdown regardless meaning that the inflight connection will still receive a 500 Internal Server Error regardless of whether or not the server is crashed. I'm a fan of giving users the choice so we don't impose contention on users that deploy their application in a kubernetes with complex load balancing and replacement strategies. I also want to make life easy for the person using a recycled Gateway 2000 to host important community resources in the public library in that small town in Nebraska that's running Via as a daemon with upstart or systemd (sorry if I'm forgetting to mention anyone).