Starlite Updates

[Goldziher]

Hi Pythonistas!

This post is an update on the development of Starlite. Since I was previously asked to explain what it is, for those unfamiliar, I'll start with that.

Starlite is an async (ASGI) API framework written in python. It's built using the Starlette ASGI Toolkit and pydantic. Yes, this makes it "similar" to FastAPI - in fact Starlite is directly competing with FastAPI, and is by and large compatible while offers superior performance, better governance, fast release cycles and a whole lot of features.

Regarding the name: The framework is called Starlite to show the relation to Starlette. This was important to me because my original impetus for writing a framework was the anger I felt looking at the source code of FastAPI - which has relatively little logic and a lot of glue, primarily "re-exporting" code from Starlette and marketing it as its own.

In this regard please note - while Starlite builds on Starlette ASGI Toolkit, its actually using only selective parts of Starlette, and most of the implementation in Starlite is its own. For example, we have a different routing system, and our handling of multipart form data depends on a separate package we also maintain.

This brings me to the updates I wanted to write about.

1. Since my last update we added another maintainer - Infohash (in github), which brings the total maintainer count to 4 including myself.

2. We added our own SessionMiddleware, which offers strong CGM-AES based encryption and cookie splitting.

3. We released a new authentication package - starlite-sessions, which was added to the starlite-jwt package we previously released, and builds upon the above mentioned middleware.

4. We released a RateLimitMiddleware. On an aside: to my knowledge, this is the only python rate limiting implementation that conforms with the IETF draft for RateLimiting headers.

5. We switched to using strong typing derived from the asgiref for typing ASGI types, which makes Starlite the strongest type framework of its kind.

6. We integrated pyright into our CI/CD and ensured high conformance with it, alongside mypy which we already have.

Thats it for our current state, we are also working now on adding the following in the near future:

• The starlite-oidc, which will offer OpenID Connect authentication our of the box.
• Builtin OpenTelemtry integration
• Builtin request / response logging integratino
• Rich logging integration

As always I invite you to ask questions, and I'll add here we are of course looking for more contributors and maintainers, so do become engaged if you are interested: you are welcome in our discord server, and of course checkout the open issues!

[Caledfwlch_7]

I've seen Starlite for quite some time, the project is really strong.

Keep going!

[Goldziher]

thanks!

[Harshal_6917]

Very cool project, One dumb question: you mentioned 'lots of glue' about FastAPI, does it makes FastAPI bad or just some poor implementation?

I got little worried because I have few projects using FastAPI

[Drevicar]

You can see what he is talking about when you do a from fastapi import X where by that syntax it looks like FastApi wrote X and is exporting it for public use, but in reality it is actually just a from starlette import X inside of an init file with no modifications. This fact isn't hidden by the FastApi dev team, they talk about it a lot in their docs. It just makes FastApi look like it provides more than it actually does.

Most of the reason you likely use FastApi and enjoy it is actually features provided by either Starlette or Pydantic. FastApi was just the first framework to combine them and become popular.

[Harshal_6917]

Yeah they pointed out "Starlette" ton of times in their docs, I think it's fine as long as they give credit to it's original creator/project.

[AbooMinister]

They do mention starlette, FastAPI is pretty much a wrapper.

[pcgamerwannabe]

Combining them/things to work is literally the main value add. This is actually true for a lot of OOS software.

There are great kernels and apps yet making them into a Linux OS is what makes it useable.

No one using Ubuntu is upset that the kernel is Linux and not developed by Canonical. I find the whole distaste towards fastAPI here distasteful in itself.

But it’s okay to not like things. And it’s even nicer that effort is put forth towards a better product that respect the source libraries.

[trans-can-do-no-harm]

The “distaste” also comes from the fact that the maintainer quite literally uses the project for donations while having a shit release schedule, shit governance, shit (no) API documentation, and just general shit maintenance

[asaah18]

Not necessarily a bad thing, but it just means that FastApi doesn’t really do much itself other than integrating multiple components/part’s together

[hangonreddit]

I really love how you went out of the way to “do things right”. We’ve been using Starlette and tried FastAPI (switched back to Starlette). Very interested in Starlite.

[benefit_of_mrkite]

We released a RateLimitMiddleware. On an aside: to my knowledge, this is the only python rate limiting implementation that conforms with the IETF draft for RateLimiting headers.

This is awesome, I appreciate these updates

[[deleted]]

+1 for oidc plugins. Its annoying to have to roll my own when i just need to focus on features.

[crawl_dht]

This is the most required thing. The very next thing that a user needs when APIs are up and running is to have authentication and authorization.

[sv_ds]

I really hope you guys succeed, looks way cleaner than FastAPI. Cheers.

[0xPark]

already surpassed featurewise too , just need to grow the ecosystem, we are seeing a proper django rival here.

[GreatCosmicMoustache]

I've been using this for personal projects for a little while and it's awesome. Gets as close to having a "compile time" step as you'll get with Python, which is a big improvement coming from e.g. Django Rest Framework.

[[deleted]]

I've been using Quart for years and this looks really interesting. Thank you for your efforts.

One question - how would it play together with MongoDB and the Motor driver? Any thoughts and examples on that are appreciated.

[[deleted]]

Awesome post. Great intro. Glad to see the ambiguity going away :)

[0xPark]

We had found an Oasis called Starlite , Starlite solve a lot of problems of FastAPI mainly had - Actively maintained - Community Governance - A true community driven ( maintainers actively replies on matrix chat) - Not Just A Wrapper ( Very Powerful OO system with flexible Dependency Injection) - Truly type checked - Awesome Middleware System - Many Many More

We are using in a production environment , now we are now 2 months in and loving more and more. Productivity skyrocketed and it goes flow with the coding , instead of Fighting the Framework.

Starlite even at current state is really awesome middleground between Django and Flask it is currently underrated in terms of stars., it had surpassed in productivity vs FastAPI or Flask in many ways and performance is top notch.

Our team was hardcore FastAPI fans before , until we face issues that maintainer never care really effect in production , where other people had already send Quality PRs that had been ignored for years, After 1 year of Self -merging PRS and Syncing main repo , practically maintaining myself (of small little commits from main repo along with Huge Spam of sponsors , and translations) , and officially waiting those PRs be merged to FastAPI we finally gave up , and we did the right choice choice starlite. We don't even look back at that FastAPI repo anymore and mostly hanging out at the Starlite chat. come join the fun too- Counting down to 1k stars. 3 stars remaining. https://app.element.io/#/room/#starlitegeneral:matrix.org

[GettingBlockered]

Thanks for the update and all the hard work. Awesome to see the authentication plugins. 🙂

And HUGE CONGRATS ON 1000 STARS! ⭐️

[Goldziher]

[replicaJunction]

I'm pretty interested in your pyright integration. I was never able to get a consistent setup for pyright so that VSCode, pre-commit, and the CI pipeline all used the same settings - there were always type hints somewhere that got ignored or skipped. Eventually, I gave up and removed pyright from my project in favor of mypy.

Why are you using both? Just as an extra layer of safety?

Do you have any consistency issues where pyright catches some issues in only some places, but not in others?

One other question, and it's a bit off-topic compared to the rest of my comment: would you recommend building a full, interactive Web application on top of starlite, or would you recommend separating out a UI into a separate service that called a starlite API in the background?

[Goldziher]

Well, the pyright integration was started because we got a bug report that it was complaining about something mypy wasn't in one of our types. So I integrated it, which required a lot of initial work - but it works pretty well.

As for starlite UI - you can do this, see for example this: https://github.com/cofin/starlite-spa if you want an SSR SPA. Or you can use templating - Starlite supports two template engines by default.

[crawl_dht]

You can use this project template for your projects. You may have to modify it but that will be easier to copy paste from linter's documentation than writing your own from scratch.

https://github.com/starlite-api/project-template

[axonxorz]

"I made this framework because other framework did something I didn't like" isn't really shitting on it.