Greetings and encouragements

[florimondmanca]

Hi there,

Just popping over here to say I'm really digging what I'm seeing around here. :-)

Bit of background from me - In 2018-2019 I worked on Bocadillo. It was sort of a personal "learn OSS" experiment, but also a mostly serious ASGI framework. It's now retired, but my favorite part of it was working on the DI system. I don't think FastAPI was around back then, or maybe just starting. Bocadillo's DI system was inspired by pytest's fixtures, just like Xpresso's it seems. I also ended up extracting it in a library, although it had several design flaws. Xpresso seems to take a similar, but much better thought-out route. It also helps that the Python typing ecosystem has moved greatly since then — Annotated / PEP 593 looks like an actual keystone! The Dependencies introduction with that HTTPX example is a joy to read.

The overall focus on decoupling is very pleasant. This is something I always had trouble with in FastAPI. Pydantic and the DI system is tangled right into the framework, making it a bit harder to understand as well as override if needed.

For now I'd just say the verbiage in READMEs and docs might be a bit too technical. I feel like it's a usual road when resorting to DI, which comes with concepts or ideas that most Python developers might not be used to.

I might try to swap FastAPI for Xpresso in a project I'm working on, and see how it goes. For reference, I'm currently using FastAPI for the web layer + punq for DI. I do use FastAPI's DI, but only for web-level stuff, such as checking auth / permissions. For other DI, such as resolving a database dependency, I need an agnostic DI library because I use hexagonal architecture, which means the web layer is pushed to the edge of a system (inspired by DDD) that otherwise ignores it's being exposed via a web API. The fact that Xpresso uses a separate and web-agnostic di library makes me quite excited that if my architecture is right I might be able to swap FastAPI + punq for Xpress + di! Well, as an exercise and experiment, at least.

Not really expecting any answer here, but thought I'd share this with you.

Cheers!

[adriangb]

Hi great to see you around here, and thank you for all of the kind words and background! You are right that a lot of recent developments in Python have come together to make this all more possible than it used to be, it's an exciting time to be working on these things.

For now I'd just say the verbiage in READMEs and docs might be a bit too technical. I feel like it's a usual road when resorting to DI, which comes with concepts or ideas that most Python developers might not be used to.

I completely agree. Writing more user friendly docs and examples is something I'm keeping in mind, but frankly I just haven't had time to do it yet 😄

I might try to swap FastAPI for Xpresso in a project I'm working on, and see how it goes

That's very exciting! The more feedback the better. If there are broken bits or pain points, please do report them. Fortunately Xpresso is at the point where changes are still possible and welcome.

Since you mention you are using a hexagonal architecture, I will mention that one thing that has worked well for me is type my endpoints / dependencies with abstract classes / protocols and bind them in the aggregate root, which if you are willing to take control of the event loop can also be where you initialize your database connections and such, making lifespans somewhat redundant: https://xpresso-api.dev/latest/advanced/dependencies/composition-root/. If you do go this route, I'd be curious to know if you think there's a use case for initializing the di container outside of the application. While it is currently accepted as a constructor parameter to App, the container itself does not have the simple assignment syntax for dependencies (that comes from this helper that App provides).

Of course Xpresso can still support lifespans and such for more FastAPI like dependency injection (even some pretty out there use cases like binding stuff from within a lifespan, which can be used to avoid storing database connections in app.state and as an alternative to an "app" scoped dependency).

[florimondmanca]

Hi @adriangb,

I experimented with Xpresso on my project, you can see the diff of switching from FastAPI here: etalab/catalogage-donnees@master...fm/xpresso

Almost all of my test suite passed with minimal changes!

Removing FastAPI also hinted me to switch to more explicit helpers, e.g. an explicit custom JSON encoder. Which I might adopt anyway to reduce the dependency on FastAPI.

I do lose the OpenAPI security integration if I switch from FastAPI's HTTPBearer dependency to a vanilla get_bearer_token() parser function. This is expected as per Xpresso's README, but that's quite a blocker, unfortunately. Perhaps there's a way to manually register the parser function onto the OpenAPI schema?

Another blocker relates to permission test on a PUT endpoint that's now failing for me. I have something like this:

async def update_dataset(
    id: FromPath[ID], data: FromJson[DatasetUpdate]
) -> DatasetView:
    ...

routes = [
    ...,
    Path(
    "/datasets/{id}/",
    dependencies=[Depends(IsAuthenticated())],
    put=update_dataset,
]

And I test that a PUT /datasets/<id>/ without authentication credentials returns a 401.

    async def test_update_not_authenticated(self, client: httpx.AsyncClient) -> None:
        pk = id_factory()
        response = await client.put(f"/datasets/{pk}/", json={})
        assert response.status_code == 401

Previously I was able to test this without sending a full PUT json body. Now, it looks like I am required to do so. This seems to indicate that contrary to FastAPI, Xpresso reads the body to evaluate FromJson binds before running dependencies. I'm unsure whether this is intended or desirable. But I was expecting that dependencies in Path(..., dependencies=...) are evaluated before anything related to running the actual path endpoint, so that they may reject the request if it is not appropriate.

[florimondmanca]

I just pushed a commit that switches the entire project's DI from punq to di, keeping the resolve() API from punq.

I implemented it by registering dependencies on a "global" scope, which is entered upon calling bootstrap().

That way, all dependencies remain cached project-wide, as they were with punq thanks to using instance=.... The resolve() DI system remains decoupled from the web framework: Xpresso does app, connection and request, and resolve() (used in web or in scripts) refers to "global".

(This made me realize my DI system actually only does initial wiring.)

[adriangb]

Almost all of my test suite passed with minimal changes!

Awesome! That's a nice surprise, I didn't necessarily try to keep backwards compatibility with FastAPI but I guess that using the same base libraries and both being ASGI frameworks helps.

Removing FastAPI also hinted me to switch to more explicit helpers, e.g. an explicit custom JSON encoder. Which I might adopt anyway to reduce the dependency on FastAPI.

I'd love to get your thoughts on Xpresso's JSON encoder / decoder support. I tried to design it so that you can plug in your own request and response encoders/decoders without coupling those to the framework, but I think the whole response customization may need a bit of work still.

Same for a simplified API bearer token parsing security code.

Security is a huge missing piece in Xpresso. I haven't been able to figure out a good API for it yet. I want it to be both less complicated than FastAPI (e.g. with the "special" SecurityScopes dependency) but also more secure (e.g. you can't get an unvalidated token, you must provide a callback to validate the token).

The resolve() DI system remains decoupled from the web framework: Xpresso does app, connection and request, and resolve() (used in web or in scripts) refers to "global".

That's really neat! So the "global" scope is above the "app" scope and thus dependencies in any of the web framework scopes automatically use the "global" scope instance right?

contrary to FastAPI, Xpresso reads the body to evaluate FromJson binds before running dependencies

Hmm this is interesting. I see that FastAPI does have logic to evaluate path parameters before the request body (utils.py) , but it also eagerly read the entire body into memory before doing any dependency execution (routing.py).

I can think of two reasons to check query/path/header/auth parameters first:

1. Server load / slow loris attacks: although everyone should be deploying with a reverse proxy that prevents slow loris attacks, it would still put a lot more load on the server to read the request body into memory before rejecting the request for auth / other reasons.
2. Easier testing (the issue you are bringing up).

Based on the fact that FastAPI reads the entire body into memory before checking auth, I'm guessing that it was not implemented with (1) in mind and I'm guessing (emphasis on this just being my guess) that it was not design with (2) in mind either but it just happened to be implemented that way.

In Xpresso I did design things with (1) in mind, sort of: we don't eagerly read the body into memory, we defer the timing of that to the dependency injection system (we also by default consume the stream to avoid having both the python object and bytes in memory, configurable here). But beyond this it's an implementation detail of Xpresso / di / graphlib2 what gets executed first. I think we could put some logic in there to say "given a collection of leaf nodes / dependencies ready to execute, execute the non-body dependencies first". I'd have to think of some API to mark dependencies as bodies or as "expensive", but it should be possible (I think just 1 LOC to run sorted(...) here).

So my question back to you is: was your concern mainly easier testing, or were you also thinking about server load when you brought up this difference?

[florimondmanca]

using the same base libraries and both being ASGI frameworks helps

Definitely, Starlette as the same base framework helped a lot.

I'd love to get your thoughts on Xpresso's JSON encoder / decoder support. I tried to design it so that you can plug in your own request and response encoders/decoders without coupling those to the framework, but I think the whole response customization may need a bit of work still.

I haven't found anything about customizing JSON on the docs site. But actually, after more tinkering it turns out I didn't need a custom JSON encoder at all. I used to need it for an endpoint that may return one of two possible schemas. FastAPI relied on response_model for encoding the return value, but Xpresso relies on the return type annotation which is neat.

That's really neat! So the "global" scope is above the "app" scope and thus dependencies in any of the web framework scopes automatically use the "global" scope instance right?

Well hmm, I'm not actually sure how the scope system works. I was only looking for a way to have a similar resolve() helper than what punq provided me. Right now, if I try to use any of the dependencies in the views using Xpresso's type hints style, it would fail - even if I pass App(container=container) - with an error message on "global" being more narrow than "app". I'm not sure I understand why, but that's fine enough to me, as sticking to resolve() gives me a consistent DI style for my own things across both the web app and custom scripts.

So my question back to you is: was your concern mainly easier testing, or were you also thinking about server load when you brought up this difference?

The reason I tested things like that, relying on auth to be executed first, is mostly laziness to pass an entire JSON body to the PUT test call. :-) Perhaps that's a hint I should be doing it.

[adriangb]

if I try to use any of the dependencies in the views using Xpresso's type hints style, it would fail - even if I pass App(container=container) - with an error message on "global" being more narrow than "app"

I think this is something we should fix. As far as di is concerned, scopes are just identifiers. When you call Container.solve you pass in an (ordered) sequence of scopes. Currently Xpreseso does that here. What's missing is a parameter to App to define custom scopes: App(..., scopes=["global", *xpresso.Scopes]) or something like this. The reason we require scopes during solving instead of dynamically resolving them from the calls to Container.enter_scope or something is that we can catch this during solving (vs. during execution), which makes it a lot more likely for a mistake to be caught during tests, even if that endpoint is not tested. Also in the future we should be able to provide the path to the dependency which IMO is important because it can be confusing to figure out what the "bad" dependency chain is if it's very deep.

from contextlib import asynccontextmanager
from typing import AsyncIterator
from xpresso import App, Request
from xpresso.testclient import TestClient

@asynccontextmanager
async def lifespan(req: Request) -> AsyncIterator[None]:
    yield

app = App(lifespan=lifespan)

with TestClient(app):
    pass

di.exceptions.ScopeViolationError: JoinedDependant(dependant=Dependant(call=<function _wrap_lifespan_as_async_generator.<locals>.gen at 0x102c5a440>, use_cache=True), siblings=[]) cannot depend on Dependant(call=<class 'starlette.requests.Request'>, use_cache=True) because Dependant(call=<class 'starlette.requests.Request'>, use_cache=True)'s scope (connection) is narrower than JoinedDependant(dependant=Dependant(call=<function _wrap_lifespan_as_async_generator.<locals>.gen at 0x102c5a440>, use_cache=True), siblings=[])'s scope (app)

Perhaps that's a hint I should be doing it

I do think that's one way to think about it 😄 . But I'm taking away a TODO to think about how we can customize the non-concurrent executor to execute bodies last.