Project goals and self-image

[provinzkraut]

Currently, starlite does not have clearly defined project goals or a similarly framed answer to the question of what it should be.

Having those would benefit us greatly when making decisions about whether to include a new feature, or where it should go (does it belong in the starlite project? Should it be its own thing?). It would also be helpful for onboarding new users, and helping them make a decision if starlite is the right tool for them.

The end result of this should be document included in our docs that outlines the things mentioned.

Please share your opinions, suggestions for questions we should be answering in such a document.

[provinzkraut]

Personally, I think the most important question we have to answer is "how many batteries does it include?", i.e. on a scale from bottle to django, where does starlite fit in?

[Tobi-De]

Perfect, I couldn't have phrased it better.

[Goldziher]

I would say - smack in the middle. Django has a builtin ORM, which is 50% of it. I would like to go for extensibility and plugins, but make sure the core is clean, modern and highly performant.

[provinzkraut]

I would second this. I'd say it's above Starlette and Flask, but below Django. Feature wise, we're probably aiming for something like the core extensions of the flask ecosystem, just more tightly integrated, which doesn't necessarily mean these functionalities have to be included in the core.

[Tobi-De]

Django is by far my favorite framework, but yes, the ORM is 80% of it, but they also have their "backend" concept which makes some of the Django components swappable like database management and authentication. Starlite's plugin system seems a bit more flexible from what I've seen.

[pemocarlo]

I precisely read a blog post a couple of days ago about the drawbacks in python web frameworks.
https://breadcrumbscollector.tech/the-disenchantment-of-python-web-frameworks/

It essentially mentions that either you have Django or microframeworks where you have to figure out many things on your own.
And there currently no framework with all of the following (copied verbatim from the article):

• first-citizen dependency injection container (no, not like in FastAPI – not bound to views),
• async support,
• an ORM as powerful as SQLAlchemy (or the SQLAlchemy itself) but as an option,
• testability from the ground up, starting from test client to tips on making app testable in parallel using pytest-sdist,
• basic web framework stuff such as routes, views, etc,
• GraphQL support or tips on integrating it would be nice,
• other boring stuff like configuration supporting several mechanisms etc

Which ones from the above does Starlite not tick?

[provinzkraut]

Which ones from the above does Starlite not tick?

GraphQL and pytest-sdist AFAIK.

[Goldziher]

I know pytest-xdist, not sdist... anyhow, how is that relevant to an API framework? as for graphQL, we will probably add support for strawberry at some point, unless they add support for us first.