Drop Starlette

[Goldziher]

We reached a point where we can relatively easily drop Starlette as a dependency - we use only a few pieces of it's ASGI kit we can implement on our own:

1. The Response classes.

2. The ASGI LifeSpan logic

3. CORs Middleware

4. GZip Middleware

5. Allowed Hosts Middleware

6. The Test client

And the exported http statuses .

I propose we tackle these one at a time and when we are ready, drop Starlette. This can be done with almost no breaking changes and just a few adjustments to exports.

Please give your opinions on this

[provinzkraut]

I'm curious, could you elaborate the motivation behind dropping starlette? Is it currently restricting starlite development in some way?

[Goldziher]

Sure.

So first off - we don't control the Starlette code base, which means breaking changes can happen without our discretion. This happened with the switch of the test client to httpx, which while pretty cool, also posed some difficulties for us.

Secondly, we no longer need Starlette because we actually implemented the complex parts on our own - we have a completely different routing level. We have our own requests, we also use a different typing (asgiref based etc.) which is no longer compatible.

Finally, the parts of Starlette we do use, we cannot change or optimize and are bottlenecks for us. I would much rather have our own response classes and the few middleware we have from there, and have the ability to modify and extend them into our patterns.

From my PoV the only real reason to keep Starlette around is that it gives Starlite more credibility. But Starlite is more established now and we have a significant community. I think we are reaching a point were this is no longer required, and in fact it works against us- Starlite is not merely a "wrapper" around Starlette. It is in fact about 2 to 3 times larger and significantly more complex.

[provinzkraut]

Thanks for the explanation! That makes a lot of sense actually!

[v3ss0n]

I think if we are moving away from starlette , we should also look into

• AnyIO
• Async task groups

[provinzkraut]

@v3ss0n Can you elaborate?

Do you suggest we drop those or adopt them more?

[provinzkraut]

How would you go about deprecating like the CORS middleware for example? Users might rely on the starlette implementation. I assume something like implementing a version that's backwards compatible with starlette first and issuing a PendingDeprecationWarning that tells users to use starlite's middleware, and only allow backwards-incompatible changes in a future major version?

[peterschutt]

Our public interface for CORS is the CORSConfig object and our use of the starlette CORSMiddleware is really an implementation detail and isn't documented anywhere. I'd therefore argue that we don't really need to deprecate our internal use of it.

However, we've advertised a level of compatibility with that middleware pattern and that shouldn't change just because we are not using starlette internally. So users should still be able to use that implementation if they choose by passing it to middleware.

[peterschutt]

Also, ServerErrorMiddleware for debug responses.

[provinzkraut]

There's a few other things currently being used from starlette. I did a little search with the ast module, and these are all the things imported from starlette (excluding individual status codes because of verbosity)

• starlette.datastructures
  • MutableHeaders (6 imports)
  • URL (4 imports)
  • Headers (5 imports)
  • Address (2 imports)
  • URLPath (1 import)
  • ImmutableMultiDict (1 import)
  • State (1 import)
• starlette.middleware
  • Middleware (3 imports)
  • cors.CORSMiddleware (2 imports)
  • trustedhost.TrustedHostMiddleware (2 imports)
  • errors.ServerErrorMiddleware (1 import)
  • gzip.GZipMiddleware (1 import)
  • gzip.GZipResponder (1 import)
  • base.BaseHTTPMiddleware (2 imports)
  • base.RequestResponseEndpoint (1 import)
• starlette.staticfiles
  • StaticFiles (2 imports)
• starlette.responses
  • Response (7 imports)
  • RedirectResponse (3 imports)
  • FileResponse (2 imports)
  • StreamingResponse (2 imports)
  • PlainTextResponse (2 imports)
  • HTMLResponse (1 import)
  • JSONResponse (1 import)
• starlette.routing
  • Router (1 import)
  • get_name (5 imports)
• starlette.exceptions
  • HTTPException (5 imports)
• starlette.requests
  • cookie_parser (2 imports)
  • SERVER_PUSH_HEADERS_TO_COPY (1 import)
• starlette.testclient
  • TestClient (3 imports)
• starlette.background
  • BackgroundTask (1 import)
  • BackgroundTasks (1 import)
• starlette.websockets
  • WebSocketDisconnect (4 imports)

So it's largely middleware, datastructures and responses. Maybe we should open a tracking issue for this to have an overview of the progress?

[peterschutt]

Nice stuff. Tracking issue sounds good, or multiple issues and we can track them together in a project, up to you.

[provinzkraut]

Hm. Project might be too much complexity for this imho. How about we create a tracking issue for overall progress + a milestone so we can group issues / PRs concerning this together?

[peterschutt]

Perfect.

[provinzkraut]

Is there any reason in particular to define all the status codes ourselves and not use the stdlib http.HTTPStatus? It's missing the websocket codes, but that's easy enough to add.

[Goldziher]

three reasons:

1. the stdlib offers an enum where each entry is a tuple, what we need are simple constants.
2. the stdlib has different names then those used in our codebase and those used by our users, so this will be a big breaking change.
3. we want to improve typing, which is what I did - check it out, and the stdlib isn't fitting for this.

[Goldziher]

Regarding the TestClient, this is going to be the biggest hurdle for us because:

1. its a big chunk of rather complex code.
2. its quite strongly coupled to Starlette, which makes it even now problematic for us because we diverged with our websocket implementation.

My suggestion is to create a new package called starlite-test-client, which will include a version "forked" from Starlette. It wont be an actual github fork, but will include a modified version of the Starlette code. We will then move to using this package.

Thoughts?

[peterschutt]

We can make httpx and the testing client a builtin, and only move the other testing dependencies into extra by doing some isolation of methods.

As mentioned, for me it is rare not to have httpx available anyway - although that's coincidental to the fact that httpx is my preferred async http client library. For others it may not be, and we'd be shoehorning users into using httpx, or to have to choose to have two http client libraries in prod dependencies. I suppose now would be a good time for anyone who fits in that group to speak out if they are around and care enough to weigh in..

At the very least having cryptography as optional draws a line in the sand, so that any further niche testing dependencies we might want to acquire along the way are treated in the same manner.

So, my preference is still to keep the status quo with optional testing extras and to amend the docs, but I won't push back if the general consensus is to take this half-way approach.

[Goldziher]

@provinzkraut when you're back on your feet, can you update what needs to be done here vis a vis the testing client now that the session backends are released?

[provinzkraut]

@Goldziher Not a lot really. The session backends are already integrated with TestClient. We can now drop cryptography from the testing extra, since it's not really tied to testing but just the CookieBackend, and people can test sessions with other backends as well.

[Goldziher]

Ok, can you handle this as part of your session related updates or a separate issue?

[provinzkraut]

Will take care of it!

[Tobi-De]

I don't know enough about Starlite so my first reaction was: WTF, really?
But after reading the discussion, it totally makes sense, the only concern I have is: wouldn't it be too much work to add right now? you guys are doing a lot, especially you @Goldziher on several repositories at once. I hope this doesn't end in a burn out. Genuine concerne here, not trying to discourage anybody.

Edit: Nevermind, you guys already started 😆

[Goldziher]

I don't know enough about Starlite so my first reaction was: WTF, really?
But after reading the discussion, it totally makes sense, the only concern I have is: wouldn't it be too much work to add right now? you guys are doing a lot, especially you @Goldziher on several repositories at once. I hope this doesn't end in a burn out. Genuine concerne here, not trying to discourage anybody.

Edit: Nevermind, you guys already started 😆

Indeed 😁. Its not immediate - I think it will probably take a month or two to get done.

[ubernostrum]

Is the plan to retain compatibility with Starlette middlewares? I've been relying on that to write middlewares that can be reused across multiple Starlette-based projects.

[Goldziher]

we will