A running API is the fastest way to see what Inversify HTTP feels like. The scaffolded API already has controllers, request validation, OpenAPI docs, and a Postgres-backed todo list, so you can try a real project before you decide how to shape your own.

You wrote a guard, two interceptors, a pipe, and a controller method. A request comes in slow, and from the outside it's one black box: HTTP GET /items, 800ms, done. Which part was slow? You don't know, so you start adding console.time() calls and hoping you remember to remove them.

You wrote the contract in a .proto file. Then the implementation turned into a function handed to server.addService(), closing over whatever it needed because a function has nowhere to put a constructor.

That function can be a class now. The container builds it. The adapter puts it on the wire.

Raise your hand if you've ever copy-pasted a JSON schema from your OpenAPI spec into a validation layer. Now keep it raised if the two drifted apart within a week.

Yeah, we've been there too.

You know what's funny? We've been building real-time features with WebSockets for years, pulling in entire libraries, managing bidirectional connections, and writing custom reconnection logic. Meanwhile, there's been a simpler solution hiding in plain sight: Server-Sent Events (SSE).

And now it's ridiculously easy to use in InversifyJS.

Remember when you started optimizing your API and realized the framework itself was the bottleneck? Yeah, us too.

Welcome to the new documentation pages! We are rebuilding our docs on top of Docusaurus to provide a better developer experience.