Litestar
'[Litestar is] not aiming to be “the next Django”' and a temperature check #2257
Replies: 4 comments 6 replies
-
|
It's great to read the above and a very extensive write-up! We don't aim to be the next Django because Django is, first and foremost, an MVC framework. As you know, this is an older generation of frameworks that tried to offer a complete solution for server-side rendering websites and thus became huge. We are an API / Web framework - or as you call it, HyperMedia application framework- but we will not be an MVC framework. First, we do not follow the MVC pattern in the design, and second, we do not seek to offer the tight coupling with ORM logic that Django and some other older frameworks have. From the features you mention -
The rest of the stuff has yet to be discussed or planned. An Admin Site, for example, is excessive for us. It could be a great 3rd party package or even an extra package by our org - but not a part of the library itself. Saying that, our roadmap is in constant discussion - but we decided (following @provinzkraut's lead) that for the time being, we will slow down the expansion of new features for now and focus on polishing and fixing issues, making stability the primary concern. We want to be like Django to the degree we create something of the highest quality on which you can build and count. That is, we want Litestar to be a first-grade production framework trusted by developers and companies - like Django. |
Beta Was this translation helpful? Give feedback.
-
|
@Goldziher thanks for your consideration and kind words about what I wrote :)
Could you please explain what it is that makes Django an MVC framework, but makes Litestar not one? Litestar obviously has the M, and the V and the C I thought? My understanding is the MVC is more of an architectural pattern, so while Django certainly strongly encourages (though scaffolding, docs, etc) the MVC pattern, and FastAPI (for instance) certainly does not, that is not to say you couldn't write an MVC app in FastAPI and a data API in Django.
I want to make sure we are clear on this point because I realize a lot of people probably don't understand. When I say "Hypermedia Driven Application" I am using the same way Carson Gross (creator of HTMX) does in his various essays and his book.
When I say "Hypermedia" that can almost be taken to be synonymous with "returning HTML" (though there are some nuances). So to that end, my understanding is that returning Hypermedia (HTML) with Litestar is considered a first class citizen, unlike FastAPI and other Python microframeworks. Note that I'm not saying that I think that Litestar does not also consider data API's (returning JSON and the like) to be a first class use case as well, nor am I saying it shouldn't! To that end I would say that Litestar is a framework that is designed to facilitate the creation of Data API's (either to be used directly, or to back up an SPA), or Hypermedia API's (a MPA/HDA that uses honest to god HTML, CSS, static files, etc).
We are certainly on the same page here! |
Beta Was this translation helpful? Give feedback.
-
|
I didn't really have a coherent ask there (other than "why do you say Litestar is not an MVC framework), so let me clarify. Is the Litestar team open to contributions (largely around docs, including establishing patterns and such) and (in time) some tweaks to the way it markets itself to encourage and support the creation of HDA's with it? |
Beta Was this translation helpful? Give feedback.
-
Certainly |
Beta Was this translation helpful? Give feedback.
-
Sure, I'll give my opinion. We have DTOs - these are different from "Models" in MVC. DTOs come from the Java world (initially) and are simply objects for the serialization and deserialization (or, in general - transmission) of data. Whereas "Models" are usually a representation of structured data, such as (classically) a database table row. To follow the MVC pattern used by such frameworks as Django and Rails, the application must be tightly coupled to a database, or if we are talking in a more abstract sense - a persistent and semi-structured state. The "Controller" in MVC is a layer of control and manipulation of data akin to a repository or a "CRUD controller." We don't have that at the moment, although there is this draft PR I'm working on: #2245, which will add this for data APIs and will allow for easy integration with HTML / HTMX. As for "View" - this part we do have. Views send a representation of the result of the operation performed on data and are thus conducive to "Hypermedia Applications." You can quickly render HTML using Litestar and create a view like this, be it using a templating engine or HTMX.
I agree with you here. One commenter on a LinkedIn post of mine pointed out that I should not call Litestar an "API framework" because it is a "Web framework". I must confess that a better terminology eludes me, so perhaps "web framework" is the correct phrase. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your detailed response. Django is the "MVC" framework that I am most familiar with, though Django refers to itself as an MVT framework (model, view, template).
I'll admit that I have a very tenuous understanding of what DTO's and repositories are, so I apologize if I say something incorrect here. I believe DTO's are akin to say, Pydantic models, as they handle serialization/marshaling. Repositories are akin to "crud models" in FastAPI, and are somewhat similar to models in most ORM's.
In Django, the "View" (controller) is basically just a route (I think?). I think this is the "fat model, thin controller" thing that people talk about? I'm not exactly sure what #2245 does that you don't get from a route (not exactly sure how it relates to a repository). Going back to the comment you made above that "...we will not be an MVC framework. First, we do not follow the MVC pattern in the design, and second, we do not seek to offer the tight coupling with ORM logic that Django and some other older frameworks have" You state that Litestar "[does] not follow the MVC pattern in the design" but then you went on to write that we have the View piece, you are working on the Controller piece. That just leaves the Model piece. To my understanding Litestar has integrations with several ORMs. I do understand that the coupling between any given ORM and Litestar is not nearly to the same degree that Django has with it's ORM (I consider this to be a feature tbh 😅) Could you enumerate what types of "tight coupling" that Django provides that you feel might be required in Litestar to enable MVC apps to be written? Broadly, I am somewhat confused because it seems to me like perhaps the polish isn't there 100% at this point, but it feels like making something using Litestar with the MVC architecture would not be difficult (especially compared to something like FastAPI), but it seems like you are asserting somewhat strongly that you don't feel like that is the case (perhaps I misunderstand 😄). I'll admit I wonder if there is just a negative association with "MVC" as not being a cool way to make a web app today compared to wiring some JSON endpoints into the JS front-end de jure. Could you clarify? Another way to phrase this question: what is the suggested way/architecture of building a multi-page application with Litestar today?
I have some thoughts on this. A lot of this comes down to what things are understood to mean. Litestar is technically most accurately described as a frugenwaffle framework, that does not actually help us here because no one would know what that meant. In the same vein, I think that Litestar (currently) a great "Data API Framework" (a la FastAPI), and a decent "Hypermedia API Framework" (terms stolen from https://htmx.org/essays/hypermedia-apis-vs-data-apis/). I think that "Data API Framework" is probably well understood by our target audience, but I think that "Hypermedia API Framework" is much less well understood (though I think that is starting to change! 🙏). "Web Framework" is accurate, but also really broad and honestly I think that most people would assume that a "Web Framework" implies something that is super low level and general (like Starlette) and not something that is batteries included and specialized like Litestar is. I honestly think that the solution is to say something like "Litestar is a framework for creating Data API's, and for creating MVC/Hypermedia Web Applications." Obviously that phrasing needs some work, but you get the idea. Don't try to come up with one term to cover both because the target audience is not used to a framework that works well for both cases, especially in the Python ecosystem; we need to call this out explicitly. |
Beta Was this translation helpful? Give feedback.
-
Lol, what?
Yes, not difficult at all - and in fact some of our examples like the "fullstack" example basically do this. The point is merely that we are not going to couple the ORM to a degree that establishes this architecture from the get go.
Fair enough. In the end we are somewhere in the "fullstack" realm I think. |
Beta Was this translation helpful? Give feedback.
-
|
"frugenwaffle" was just an example of some word that sounds made up (because it is) that would do us no benefit to use in marketing, even if it was technically correct. This is part of why I think "Hypermedia Framework" may not be super useful today (though I'm thinking in the next few years that may change!). To me, "Fullstack" implies a Data API + JS SPA Front-end library, which you certainly can do with Litestar, but does not cover MVC/HDA/MPA use cases. |
Beta Was this translation helpful? Give feedback.
-
Cool. I was surprised - frugenwaffle sounds so very German, which is a language I speak, and yet it is completely meaningless 😉 |
Beta Was this translation helpful? Give feedback.
-
|
It was meaningless, now it means "the exact kind of framework that Litestar is" ;) |
Beta Was this translation helpful? Give feedback.
-
Intro and Background
Me
Hello all. I am a engineering manager and engineer that cares a lot about Python and avoiding complexity / over-engineering. To that end, have been on a crusade over the last couple years to promote hypermedia driven applications (HDAs), as I think that they solve many (self inflicted) problems that have plagued web development for the last decade or so.
PyHAT
At PyCon 2023, @tataraba and I conceived of a web stack (a la LAMP, MEAN, MERN, etc) called PyHAT: Python, HTMX (or hypermedia), ASGI, Tailwind. I have spend a lot of time looking at what the state of the art is for Hypermedia driven applications are in Python, and came to the conclusion that Django has by far the biggest community around creating HDAs.
Python Microframeworks
My experience and understanding is that Python microframeworks (FastAPI, Starlette, Flask/Quart, etc) are almost exclusively used to create JSON API's to drive SPAs, rather than HDAs. I have tried to create a HDA using FastAPI and found that:
This is a problem that I discussed with @tataraba at length. We both agree (IIRC) that Python microframeworks tend to require a lot of boilerplate / reinventing the wheel to make a HDA, but there is really only one alternative to that within the Python ecosystem, which brings us to:
Django
Django is basically built to make HDAs, but there are other problems with Django. I have my own list of issues with Django (which has only grown since writing this), as does @tataraba.
That said, I was still pretty convinced that Django was the best option for building an HDA with Python today. @tataraba and I had discussed that it would be great, and there is likely a market for, a spiritual successor to Django. What would it look like if Django was invented today?
Things that I would think would look different:
Things that I think would stay the same (more or less):
manage.py(not necessarily exactly in the same form, but an opinionated, common cli interface for common chores)My Introduction to Litestar
I became dissolutioned with FastAPI relatively early on, mostly around the project's governance but also due to it's poor support for anything other than JSON-slinging, and heard about Litestar (then Starlite) being framed as "FastAPI but without a bus factor of one". I thought this was great, but it didn't really solve the "Python microframeworks are designed and used to feed JSON to React" problem, so I didn't spend much time looking into Starlite.
That was a couple years ago. Fast forward to a few weeks ago and I got a ping to add Litestar to add it to my Awesome list. The last week or so I have been looking into Litestar, how people are using it, what features it has, etc.
And what do you know, Litestar checks.. a lot of the boxes for the things that I would have wanted from "Django designed in 2023". It is actually easier to go over the things it doesn't do:
(I am still learning what Litestar has to offer, so take the following with a grain of salt)
manage.pyequivalentThis is.. really impressive. And really exciting. So that begs the question then:
What Does '[Litestar is] not aiming to be “the next Django”' Mean?
The example given in the docs is that Litestar will not "have it's own ORM", but IMO what makes Django what it is is not that it has it's own bespoke ORM, (or templating library, or testing system 🙄) it's that it's opinionated, batteries included, has a strong community, and has a focus on HDAs. It seems to me that Litestar already has most if not all of these things!
The Missing Features / Batteries
I'm sure that none of the things listed above are novel things to be brought up, so forgive me. I'm curious what the maintainers think about including in Litestar's scope the following:
manage.pyequivalent (maybe https://docs.litestar.dev/latest/usage/cli.html already covers this?)Misc Observations
There are some other things that I think make Litestar a better, more modern alternative to Django (as opposed to "just" being an alternative to FastAPI, which I think is what the perception is):
Litestar should consider pivoting it's marketing towards HDA's / being an alternative to Django. Not saying it shouldn't also hold itself out as an alternative to just FastAPI. The first paragraph says "focused on building APIs". Am I way off base here in my thinking?
PyHAT
I have been wanting to make an example PyHAT project for some time, and had actually started with Django, but I think Litestar would be a better fit at this point.
Closing Thoughts
I'm super impressed overall. I hope that nothing above comes off as critical or negative. If you got this far thanks for your time and consideration!
Beta Was this translation helpful? Give feedback.
All reactions