Starlite: the little API framework that can.

I’m excited to announce the release of v1.0.0 of Starlite. This release includes a thorough rewrite of the core logic, boosting performance and reducing resource usage quite drastically.

Starlite is a Python ASGI API framework built on top of the Starlette ASGI toolkit and pydantic. It has some similarities to FastAPI — in both frameworks type annotations are used to automatically generate OpenAPI documentation as well as parse, validate and inject request data.

This makes Starlite compatible with most of the FastAPI ecosystem, which is very nice. It also makes migration quite straightforward. Yet, Starlite is not FastAPI — it’s quite different both in its conception and in its implementation. It’s defined by the following traits:

It’s Opinionated

Starlite enforces best practices such as type annotations and has extensive validation of its developer-facing API. The framework ensures it’s hard to make a mistake and if a mistake is made — an informative exception is raised, helping to point you in the right direction.

It’s Simple

Starlite is easy to learn and has a consistent architecture that allows it to keep complexity low even when scaling.

It’s Really Fast

Starlite is one of the fastest, if not the fastest, Python API frameworks. In fact, it is faster than both FastAPI and Starlette:

a- async, s- sync, np- no params, qp- query params, pp- path params, mp- mixed params

How is it possible given that Starlite is based on Starlette? Well, in difference to FastAPI, Starlite does not “extend” Starlette, but rather uses the Starlette ASGI toolkit selectively.

It’s not Starlette+

Starlite implements its own routing layer, as well as significant parts of the ASGI layer. Because Starlite has an opinionated architecture, it can be both simpler and more efficient. Additionally, Starlite does a lot of computation during the application bootstrap process, determining all the requirements for each individual route beforehand. This ensures that computation during the run-time is kept to a minimum, making it extremely efficient in terms of resource usage as well as very fast.

It’s Community Orientated

The goal of Starlite is to become a community-driven project with a group of maintainers and contributors, rather than having a single “owner”. This stems from the belief that a framework should not be the work of a solo maintainer. To this end, we have an open Discord server, and we invite people to contribute, and — if they wish and show dedication, become maintainers.

It Supports both Functional Programming and OOP

Starlite supports the same kind of function-based patterns that are popular in Flask, Starlette, Sanic, and FastAPI, for example:

But it also supports whats called Controllers in Starlite, or class-based Views to use another common term:

In fact, most Starlite code is based on classes and it allows for simple extension using OOP

It Borrows Good Ideas

Starlite follows the dictum of not “re-inventing the wheel”. It borrows great ideas from various places:

1. the handling of function kwargs and the use of pydantic was inspired by FastAPI
2. the dependency injection feature is is inspired by pytest, which has a very neat DI system using kwargs and namespaces.
3. the route guard feature is inspired by NestJS, which has a similarly named feature.
4. the before_request and after_request request life-cycle hooks were inspired by Flask, which has similar hooks.

It’s Extensible

Starlite is built to be extended. Most of the Starlite exports are classes that are easily modularized for extension. Furthermore, Starlite makes use of Protocols to ensure simple extensibility.

For example, Starlite supports out of the box both jinja2 and mako templates, but you can easily add another template engine by implementing the Starlite TemplateEngineProtocol class.

This is especially true of the Starlite plugin system:

Using plugins, you can have Starlite parse and validate inbound values (e.g. request-body data or parameters) as if they were pydantic models, and then deserialize the data into the desired model type, or list thereof. And vice-versa, plugins also allow you to return an instance or list of instances of a model and have it serialized correctly.

To create a plugin, you simply need to implement the Starlite PluginProtocol class and all its methods.

Starlite comes packed with an SQLAlchemyPlugin, that does exactly this — it implements the PluginProtocol and allows users to use SQL Alchemy declarative classes in this manner:

I hope the above spiked your interest!

I invite you to checkout and ⭐ our GitHub repository.

Starlite also has first class documentation, and one of our talented contributors (Damian Kress) made it a real pleasure to look at.

Finally, you are invited to join us on Discord — we are always happy to answer questions, and of course welcome contributors!

More content at plainenglish.io. Sign up for our free weekly newsletter. Get exclusive access to writing opportunities and advice in our community Discord.