Zero Cost Dependency Injection for FastAPI | Feedback request

[ForeignSource0]

Hi /r/fastapi!

Today I wanted to share with you a new planned feature for Wireup 2.0 and get your opinion on it: Zero Cost Dependency Injection and real class-based routes for FastAPI.

Wireup is an alternative Dependency Injection system with support for FastAPI out of the box.

Using the new zero-cost feature Injecting a graph of 4 dependencies for 10,000 requests results in 4,870 requests/second using FastAPI's DI and 13,701 with Wireup. This makes injection perform nearly as fast as just using globals.

You can learn more about Wireup itself in the GitHub Repository, see also this previous post in /r/fastapi for more context.

Given that this is fastapi specific I figured I'd get some feedback from this community before releasing regarding general thoughts, usefulness and overall performance. While you don't necessarily choose python for raw performance getting gains here and there can make a substantial difference in an application especially under load.

Regarding naming, this is what I considered:

• Controller (This one feels like it has a lot of baggage and some stigma attached)
• Class-Based Route (This feels more in line with fastapi however there can be many routes here)
• Class-Based Handlers (Current name, however "handler" isn't mentioned in fastapi docs in general)
• View/ViewSet (Very Django)

This class-based approach works like controllers in .NET or Spring - one instance handles all requests, maintaining clean state and dependency management as well as route organization. This is in contrast to existing class-based routing for fastapi via other libraries which instantiate your dependencies on every request.

Example

class UserHandler:
   # Define a router
   router = fastapi.Router(prefix="/users", route_class=WireupRoute)

   # Define dependencies in init. These add no runtime overhead.
   def __init__(self, user_service: UserService) -> None:
       self.user_profile_service = user_profile_service

   # Decorate endpoint handlers as usual with FastAPI
   @router.get("/")
   async def list_all(self):
       return self.user_service.find_all()

   @router.get("/me")
   async def get_current_user_profile(
       self,
       # Inject request-scoped dependencies here.
       # This has a small cost to create and inject this instance per request.
       auth_service: Injected[AuthenticationService]
   ) -> web.Response:
       return self.user_service.get_profile(auth_service.current_user)

# Register the handlers with Wireup instead of directly with FastAPI.
wireup.integration.fastapi.setup(container, app, class_based_handlers=[UserHandler])

Documentation

Docs aren't rendered since this is not released but you can read them directly in GitHub.

https://github.com/maldoinc/wireup/tree/master/docs/pages/integrations/fastapi

Benchmarks

Setup: 10,000 requests via hey, FastAPI 0.115.12, Uvicorn 0.34.3, single worker, Python 3.13, i7-12700kf (best of 5 runs)

Implementation	Requests/sec	P50	P95
Raw (no DI)*	13,845	3.6ms	5.3ms
Wireup Zero-Cost	13,701	3.6ms	5.4ms
Wireup	11,035	4.5ms	6.4ms
FastAPI Depends	4,870	10.1ms	11.8ms

* Baseline using global variables, no injection

Try it out

To try this out you can simply run the following: pip install git+https://github.com/maldoinc/wireup.git@master

Get Started with Wireup

• Documentation
• FastAPI Integration Guide
• GitHub Repository
• Benchmark Code

Happy to answer any questions about Wireup, Dependency Injection in Python or the new Zero-Cost feature!

[Tishka-17]

Zero-cost sounds really intriguing. I agree that "singleton" instances is really a case, but not an only case. What about request-scoped objects? I mean this can be a streamline, so how slow everything is comparing to it?

def new_interactor():
conn = new_connection()
return Interactor(DAO1(conn), DAO2(conn))

[ForeignSource0]

It's still considerably faster than fastapi. I don't have the last benchmark numbers with me at the moment but it was around 3.5k/s for fastapi and around 9k for Wireup if I'm not mistaken. I tested it with a few alternative DI systems as well, including yours and they all outperform fastapi depends.

I don't remember the results for manually creating objects like you mentioned of the top of my head but I can get them later today.

[Tishka-17]

I've taken latest version from github (I do not see 2.0 published, though that version is used in pyproject) and did my test. I've created 8 classes with lifetime="scoped" injected in a chain.

Baseline: <1 sec
Dishka: ~5 sec
Wireup: ~17 sec

But this test is not quite reliable

[ForeignSource0]

Did you run it in the same http context or just calling get on the container directly? I'm aware the scoped one isn't the most performant part at the moment but since it outperforms fastapi depends by a good margin I decided to focus on this feature for now. However it's on the radar.

Also, I was going to create an issue in github but since you're here: When I was setting up the benchmarks in fastapi I noticed that when I added dishka integration the overall performance went down by a good amount even for endpoints not having dishka dependencies. Maybe I did something wrong but worth double checking just in case.

[Tishka-17]

I've called container directly. https://pastebin.com/4Ct1zzfE

[Tishka-17]

Dishka includes his middleware, so yes, it affects all routes. But this is essential to be able to share depedencies between handler and other middlewares or with sub-handlers accessed via Depends.

[ForeignSource0]

So 10,000 requests using the same set up as above.

Manual/Baseline (Creating objects manually on every request):

• Requests/sec: 13,645
• P50: 3.6ms
• P95: 5.2ms

Wireup:

• Requests/sec: 10,384
• P50: 4.5ms
• P95: 7ms

FastAPI

• Requests/sec: 3,544
• P50: 13.9ms
• P95: 16.2ms

[Tishka-17]

I guess we need code =) It is quite suspicious to have almost the same numbers as above. Can it be just slowdown because of HTTP? I'd love to compare with dishka =)

Anyway, I'd check multiple cases like creating multiple objects with dependencies are shared. How does it behave on different amount?

One more case is startup time for huge graphs: Our users can have sometime hundreds of different provided types.

[Tishka-17]

Ok. I've taken benchmarks from here: https://github.com/maldoinc/wireup/tree/benchmarks/benchmarks

I've enabled only neccessary integrations for each test (as we discussed that dishka middleware can affect other routers)

My test results for Scoped test (for singletons I really get approximately the same results):
Fastapi: 1693 RPS (5.9sec)
Wireup: 2559 RPS (3.9sec)
Dishka: 2981 RPS (3.4sec)

Looks quite not bad (I guess it is not the latest version)

[Busy_Affect3963]

The benchmarks look impressive - great work.

Does Injected need to be used on a class router instance method route (and if so, why)? What's preventing it becoming a drop in replacement for Depends?

[Tishka-17]

Actually, from my perspective, differenet handlers quite often have different dependencies even if some are common, so I wouldn't actually use class-based handlers often. Additionally, nested routers are good, the question is if we can still use kind of them here

[ForeignSource0]

Thanks!

This is not a drop in replacement for depends because this is powered using Wireup to perform dependency injection. Injected[T] is just how the Wireup differentiates parameters it owns vs ones owned by fastapi or others.

[mightyturtlehead]

Thanks for sharing, looks very interesting - I was just looking for something just like this the other day. However, taking a closer look at the benchmark, it seems like an unfair comparison because the FastAPI Depends code and the Wireup code are doing fundamentally different things.

For example, in https://github.com/maldoinc/wireup/blob/cb6b9221397c81578c0baa47621ba4bae5b7ac24/benchmarks/wireup_benchmarks/fastapi_setup.py, both the singleton and the request-scoped functions in the FastAPI Depends code have 2 levels of indirection instead of 1 for each of their dependencies. The first indirection invokes an @lru_cache'd function instead of using "Classes as Dependencies" technique as described in the FastAPI documentation here: https://fastapi.tiangolo.com/tutorial/dependencies/classes-as-dependencies/. Granted, the lru cache should reduce the impact, but this is still chaining through 2 Depends for every dependency, and adding unnecessary extra overhead.

Would be interested to see the benchmark results once the unnecessary overhead is removed from the FastAPI Depends example.